


I have the following script. In infiniteaccuracy 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 infiniteaccuracy values? TwoToPowerOf63 = Math.pow(2, 63) // 2^63 SecsIn400Years = (400*365+1003) * (60*60*24) // Seconds in 400 years Quadrennia = TwoToPowerOf63 / SecsIn400Years  0 // DIV Remainder = TwoToPowerOf63 % SecsIn400Years // MOD And, does currently predominantlyused JavaScript natively have greaterprecision types of numbers, such as 64bit unsigned integers? I do have a Pascal/Delphi vastinteger program (IIRC, up to + 15^99999999), but I want something simpler here). If so, recommended URL(s)? 


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 infiniteaccuracy values? Of course not, double is not arbitrary ("infinite") precision. > And, does currently predominantlyused JavaScript natively have > greaterprecision types of numbers, such as 64bit 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 


On Thursday, February 27, 2020 at 6:08:45 AM UTC6, dr.j.r...@gmail.com wrote:
> [...] > TwoToPowerOf63 = Math.pow(2, 63) // 2^63 In modern javascript: let twoToPowerOf63 = 2**63; > And, does currently predominantlyused JavaScript natively have > greaterprecision types of numbers, such as 64bit unsigned > integers? Yes: <https://developer.mozilla.org/enUS/docs/Web/JavaScript/Reference/Global_Objects/BigInt> and BigDecimal is in progress: <https://twitter.com/mlhaufe/status/1185611526482354176> 


On Thursday, 27 February 2020 15:29:24 UTC+1, Michael Haufe (TNO) wrote:
> On Thursday, February 27, 2020 at 6:08:45 AM UTC6, 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 predominantlyused JavaScript natively have > > greaterprecision types of numbers, such as 64bit unsigned > > integers? > Yes: > <https://developer.mozilla.org/enUS/docs/Web/JavaScript/Reference/Global_Objects/BigInt> Look at the Compatibility table at the bottom. I guess we have a different interpretation of "currently predominantlyused JavaScript natively"... Julio 


On Thursday, February 27, 2020 at 8:39:37 AM UTC6, 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 predominantlyused > JavaScript natively"... You're free to give your interpretation. I suspect our interpretations are irrelevant for the O.P. anyway. 


On Thursday, 27 February 2020 16:49:06 UTC+1, Michael Haufe (TNO) wrote:
> On Thursday, February 27, 2020 at 8:39:37 AM UTC6, 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 


On Thursday, February 27, 2020 at 10:00:12 AM UTC6, 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. 


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 > predominantlyused JavaScript natively"... You have no clue: <https://gs.statcounter.com/browsermarketshare#monthly200901202001> 


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> 


Thomas 'PointedEars' Lahn:
> Julio Di Egidio wrote: > You have no clue: > <https://gs.statcounter.com/browsermarketshare#monthly200901202001> JFTR: Eventhough Chrome looks like the defacto standard nowadays, Safari has a market share of 17.1% and its share is increasing  and this browser does not support BigInt. 


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/browsermarketshare#monthly200901202001> Shouldn't you be asking what John Stockton uses before pontificating? John 


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 


On Friday, February 28, 2020 at 2:24:44 AM UTC6, Arno Welzel wrote:
> Thomas 'PointedEars' Lahn: > [...] > JFTR: > Eventhough Chrome looks like the defacto 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/releasenotesforsafaritechnologypreview73/> 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/biginteger> 