experchange > javascript

dr.j.r.stockton (02-27-20, 02:08 PM)
I have the following script. In infinite-accuracy arithmetic, all
variables will have integer values; but 2^63, although represented
exactly in an IEEE Double, is outside the range in which all
integers can be represented exactly. Am I entitled to say that,
script using IEEE Doubles, all the variables will take the
infinite-accuracy values?

TwoToPowerOf63 = Math.pow(2, 63) // 2^63
SecsIn400Years = (400*365+100-3) * (60*60*24) // Seconds in 400 years
Quadrennia = TwoToPowerOf63 / SecsIn400Years | 0 // DIV
Remainder = TwoToPowerOf63 % SecsIn400Years // MOD

And, does currently predominantly-used JavaScript natively have
greater-precision types of numbers, such as 64-bit unsigned
integers? I do have a Pascal/Delphi vast-integer program
(IIRC, up to +- 15^99999999), but I want something simpler here).

If so, recommended URL(s)?
Julio Di Egidio (02-27-20, 04:02 PM)
On Thursday, 27 February 2020 13:08:45 UTC+1, dr.j.r...@gmail.com wrote:

> Am I entitled to say that, script using IEEE Doubles, all the variables
> will take the infinite-accuracy values?


Of course not, double is not arbitrary ("infinite") precision.

> And, does currently predominantly-used JavaScript natively have
> greater-precision types of numbers, such as 64-bit unsigned
> integers?


As far as I know, it's all double precision floating point in JS. But I
haven't checked with the spec: others may be able to be more definitive on
this (whether the runtime is allowed to leverage integers up to a certain
point, in which case it would certainly use int64 on 64 bit machines).

> If so, recommended URL(s)?


Look up javascript arbitrary precision / arbitrary integers and rationals.
I know there are few libraries around, some even well established, that
offer you that functionality. Performances are generally poor though,
as it is all coded in JS itself. Another approach and interesting search
to do would be solutions that leverage web assembler or similar. Look it
up and let us know... ;)

Julio
Michael Haufe (TNO) (02-27-20, 04:29 PM)
On Thursday, February 27, 2020 at 6:08:45 AM UTC-6, dr.j.r...@gmail.com wrote:
> [...]


> TwoToPowerOf63 = Math.pow(2, 63) // 2^63


In modern javascript:

let twoToPowerOf63 = 2**63;

> And, does currently predominantly-used JavaScript natively have
> greater-precision types of numbers, such as 64-bit unsigned
> integers?


Yes:

<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt>

and BigDecimal is in progress:

<https://twitter.com/mlhaufe/status/1185611526482354176>
Julio Di Egidio (02-27-20, 04:39 PM)
On Thursday, 27 February 2020 15:29:24 UTC+1, Michael Haufe (TNO) wrote:
> On Thursday, February 27, 2020 at 6:08:45 AM UTC-6, dr.j.r...@gmail.com wrote:
> > [...]
> > TwoToPowerOf63 = Math.pow(2, 63) // 2^63

> In modern javascript:
> let twoToPowerOf63 = 2**63;


"Modern" as in needing a transpiler?

> > And, does currently predominantly-used JavaScript natively have
> > greater-precision types of numbers, such as 64-bit unsigned
> > integers?

> Yes:
> <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt>


Look at the Compatibility table at the bottom.

I guess we have a different interpretation of "currently predominantly-used
JavaScript natively"...

Julio
Michael Haufe (TNO) (02-27-20, 05:49 PM)
On Thursday, February 27, 2020 at 8:39:37 AM UTC-6, Julio Di Egidio wrote:
> On Thursday, 27 February 2020 15:29:24 UTC+1, Michael Haufe (TNO) wrote:
> "Modern" as in needing a transpiler?


Argumentation is a skill; being argumentative is a symptom...

"Modern" as in part of a published standard, in this case ECMAScript 2016.

> Look at the Compatibility table at the bottom.
> I guess we have a different interpretation of "currently predominantly-used
> JavaScript natively"...


You're free to give your interpretation. I suspect our interpretations are irrelevant for the O.P. anyway.
Julio Di Egidio (02-27-20, 06:00 PM)
On Thursday, 27 February 2020 16:49:06 UTC+1, Michael Haufe (TNO) wrote:
> On Thursday, February 27, 2020 at 8:39:37 AM UTC-6, Julio Di Egidio wrote:
> Argumentation is a skill; being argumentative is a symptom...
> "Modern" as in part of a published standard, in this case ECMAScript 2016.
> You're free to give your interpretation. I suspect our interpretations are
> irrelevant for the O.P. anyway.


Then I'll be more explicit: your suggestions aren't just misrepresented,
they are technically misguided and inappropriate. That you get it or not.

Just my opinion, of course. (EOD.)

Julio
Michael Haufe (TNO) (02-27-20, 06:20 PM)
On Thursday, February 27, 2020 at 10:00:12 AM UTC-6, Julio Di Egidio wrote:
> Then I'll be more explicit: your suggestions aren't just misrepresented,
> they are technically misguided and inappropriate. That you get it or not.
> Just my opinion, of course. (EOD.)


Full of shit as always. At least you learned something.
Thomas 'PointedEars' Lahn (02-27-20, 11:54 PM)
Julio Di Egidio wrote:

> On Thursday, 27 February 2020 15:29:24 UTC+1, Michael Haufe (TNO) wrote:
> "Modern" as in needing a transpiler?


No.

> Look at the Compatibility table at the bottom.
> I guess we have a different interpretation of "currently
> predominantly-used JavaScript natively"...


You have no clue:

<https://gs.statcounter.com/browser-market-share#monthly-200901-202001>
Arno Welzel (02-28-20, 10:20 AM)
Julio Di Egidio:

> On Thursday, 27 February 2020 15:29:24 UTC+1, Michael Haufe (TNO) wrote:
> "Modern" as in needing a transpiler?
> Look at the Compatibility table at the bottom.


These are outdated. Also see here: <https://caniuse.com/#search=bigint>
Arno Welzel (02-28-20, 10:24 AM)
Thomas 'PointedEars' Lahn:

> Julio Di Egidio wrote:
> You have no clue:
> <https://gs.statcounter.com/browser-market-share#monthly-200901-202001>


JFTR:

Eventhough Chrome looks like the de-facto standard nowadays, Safari has
a market share of 17.1% and its share is increasing - and this browser
does not support BigInt.
John G Harris (02-28-20, 10:32 AM)
On Thu, 27 Feb 2020 22:54 +0100, Thomas 'PointedEars' Lahn
<PointedEars> wrote:

>Julio Di Egidio wrote:
>No.
>You have no clue:
><https://gs.statcounter.com/browser-market-share#monthly-200901-202001>


Shouldn't you be asking what John Stockton uses before pontificating?

John
Evertjan. (02-28-20, 12:06 PM)
Arno Welzel <usenet> wrote on 28 Feb 2020 in
comp.lang.javascript:

> These are outdated. Also see here: <https://caniuse.com/#search=bigint>


So the [google Chrome-] answer to John is: BigInt()

<https://v8.dev/features/bigint>

const max = BigInt(Number.MAX_SAFE_INTEGER);
const two = 2n;
const result = max + two;
console.log(result); // 9007199254740993n
Michael Haufe (TNO) (02-28-20, 04:48 PM)
On Friday, February 28, 2020 at 2:24:44 AM UTC-6, Arno Welzel wrote:
> Thomas 'PointedEars' Lahn:
> [...]
> JFTR:
> Eventhough Chrome looks like the de-facto standard nowadays, Safari has
> a market share of 17.1% and its share is increasing - and this browser
> does not support BigInt.


The next release will I suspect:

<https://webkit.org/blog/8555/release-notes-for-safari-technology-preview-73/>

But my guess is that John Stockton doesn't care about mobile devices based on previous discussions here. If so, then Polyfills do exist:

<https://www.npmjs.com/package/big-integer>
Similar Threads