Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #38213 > unrolled thread

Arithmetic Accuracy Question

Back to article view | Back to comp.lang.javascript

Contents

  Arithmetic Accuracy Question dr.j.r.stockton@gmail.com - 2020-02-27 04:08 -0800
    Re: Arithmetic Accuracy Question Julio Di Egidio <julio@diegidio.name> - 2020-02-27 06:02 -0800
    Re: Arithmetic Accuracy Question "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2020-02-27 06:29 -0800
      Re: Arithmetic Accuracy Question Julio Di Egidio <julio@diegidio.name> - 2020-02-27 06:39 -0800
        Re: Arithmetic Accuracy Question "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2020-02-27 07:49 -0800
          Re: Arithmetic Accuracy Question Julio Di Egidio <julio@diegidio.name> - 2020-02-27 08:00 -0800
            Re: Arithmetic Accuracy Question "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2020-02-27 08:20 -0800
        Re: Arithmetic Accuracy Question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2020-02-27 22:54 +0100
          Re: Arithmetic Accuracy Question Arno Welzel <usenet@arnowelzel.de> - 2020-02-28 09:24 +0100
            Re: Arithmetic Accuracy Question "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2020-02-28 06:48 -0800
          Re: Arithmetic Accuracy Question John G Harris <niam@jghnorth.org.uk.invalid> - 2020-02-28 08:32 +0000
        Re: Arithmetic Accuracy Question Arno Welzel <usenet@arnowelzel.de> - 2020-02-28 09:20 +0100
          Re: Arithmetic Accuracy Question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-02-28 11:06 +0100
      Re: Arithmetic Accuracy Question dr.j.r.stockton@gmail.com - 2020-03-26 12:04 -0700
        Re: Arithmetic Accuracy Question "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2020-03-26 13:17 -0700
    Re: Arithmetic Accuracy Question dr.j.r.stockton@gmail.com - 2020-03-26 11:24 -0700

#38213 — Arithmetic Accuracy Question

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)?


-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [next] | [standalone]

#38214

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

[toc] | [prev] | [next] | [standalone]

#38215

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>

[toc] | [prev] | [next] | [standalone]

#38216

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

[toc] | [prev] | [next] | [standalone]

#38217

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:
> > 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?

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

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

> > > 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"...

You're free to give your interpretation. I suspect our interpretations are irrelevant for the O.P. anyway.

[toc] | [prev] | [next] | [standalone]

#38218

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:
> > 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?
> 
> Argumentation is a skill; being argumentative is a symptom...
> 
> "Modern" as in part of a published standard, in this case ECMAScript 2016.
> 
> > > > 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"...
> 
> 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

[toc] | [prev] | [next] | [standalone]

#38219

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.

[toc] | [prev] | [next] | [standalone]

#38220

Julio Di Egidio wrote:

> 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?

No.

>> > 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"...

You have no clue:

<https://gs.statcounter.com/browser-market-share#monthly-200901-202001>

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#38222

Thomas 'PointedEars' Lahn:

> Julio Di Egidio wrote:
> 
>> On Thursday, 27 February 2020 15:29:24 UTC+1, Michael Haufe (TNO)  wrote:
[...]
>>> <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"...
> 
> 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.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#38225

On Friday, February 28, 2020 at 2:24:44 AM UTC-6, Arno Welzel wrote:
> Thomas 'PointedEars' Lahn:
> 
> > Julio Di Egidio wrote:
> > 
> >> On Thursday, 27 February 2020 15:29:24 UTC+1, Michael Haufe (TNO)  wrote:
> [...]
> >>> <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"...
> > 
> > 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.

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>

[toc] | [prev] | [next] | [standalone]

#38223

On Thu, 27 Feb 2020 22:54 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Julio Di Egidio wrote:
>
>> 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?
>
>No.
>
>>> > 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"...
>
>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

[toc] | [prev] | [next] | [standalone]

#38221

Julio Di Egidio:

> 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.

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



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#38224

Arno Welzel <usenet@arnowelzel.de> 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

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#38334

On Thursday, 27 February 2020 14:29:24 UTC, 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;

I fear that to be too modern for at least one current browser, probably MS IE 11 :-( .


> > 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>

Good.

<G> - but how about other bases?  Two decades ago, I would have already been able to calculate, in Base 7 (or other in 2..16) integer arithmetic, the date of this year's Easter Sunday :-

prompt>longcalc 2020 dup 7 bas wrt #ge  wrt wrt
+5,614 +4 +15
</G>

-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

#38335

On Thursday, March 26, 2020 at 2:05:23 PM UTC-5, dr.j.r...@gmail.com wrote:
> On Thursday, 27 February 2020 14:29:24 UTC, 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;
> 
> I fear that to be too modern for at least one current browser, probably MS IE 11 :-( .

According to Thomas's link from earlier IE usage globally is 1.63%:

<https://gs.statcounter.com/browser-market-share>


> > > 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>
> 
> Good.
> 
> <G> - but how about other bases?  Two decades ago, I would have already been able to calculate, in Base 7 (or other in 2..16) integer arithmetic, the date of this year's Easter Sunday :-
> 
> prompt>longcalc 2020 dup 7 bas wrt #ge  wrt wrt
> +5,614 +4 +15
> </G>

You're limited to parseInt on smaller values for now:

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

A proposal is in the works for larger values:

<https://github.com/tc39/proposal-number-fromstring>

[toc] | [prev] | [next] | [standalone]

#38332

On Thursday, 27 February 2020 12:08:45 UTC, dr.j.r...@gmail.com  wrote:
> 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).

Oops - I looked again at the instruction list for my (RPN) vast-integer program, and found an instruction #uf (written two decades ago in simpler RPN instructions) to do EXACTLY what I wanted - so that, on my PCs, the command line
                 longcalc 2 64 dec pow #uf

does exactly the required calculation (and on this newish PC, effectively instantaneously).  I do not now need something simpler.

Real Life than intervened, rather annoyingly, and has kept me busy since.

Sorry for the delay.

-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web