Welcome to Node.js v18.9.0.

> 1889**29
1.0250068783051206e+95
> Number(BigInt(1889)**BigInt(29))
1.0250068783051207e+95

Mostowski Collapse <bursejan@gmail.com> writes:

> Welcome to Node.js v18.9.0.
>
>> 1889**29
> 1.0250068783051206e+95
>> Number(BigInt(1889)**BigInt(29))
> 1.0250068783051207e+95

You question (in the subject) was "Are Floating Point Numbers still a
Can of Worms?" If you once considered them a can of worms, why might
you not consider them so now? And what has your example got to do with
the question?

--
Ben.

Mostowski,

>> 1889**29
> 1.0250068783051206e+95
>> Number(BigInt(1889)**BigInt(29))
> 1.0250068783051207e+95

You're looking at the lowest significant digit of a 64-bit IEE float - which
might not have all of its bits defined and thus being zero - against a
"BigFloat" digit which, for that digit, has all its bits defined.

IOW, you could be looking at a 01xxb (with "x" being zero) for the 64-bit
float against a 0110b for the BigInt float.

Bottom line : the lowest significant digit of a float is most always
incomplete, and as such might not accuratily represent the number it was
created from.

Regards,
Rudy Wieser

> IOW, you could be looking at a 01xxb (with "x" being zero) for the 64-bit
> float against a 0110b for the BigInt float.

My bad, I should have been :

> IOW, you could be looking at a 011xb (with "x" being zero) for the 64-bit
> float against a 0111b for the BigInt float.

Regards,
Rudy Wieser

On 15/10/2022 08:33, R.Wieser wrote:
> Mostowski,
>
>>> 1889**29
>> 1.0250068783051206e+95
>>> Number(BigInt(1889)**BigInt(29))
>> 1.0250068783051207e+95
>
> You're looking at the lowest significant digit of a 64-bit IEE float - which
> might not have all of its bits defined and thus being zero - against a
> "BigFloat" digit which, for that digit, has all its bits defined.
>
> IOW, you could be looking at a 01xxb (with "x" being zero) for the 64-bit
> float against a 0110b for the BigInt float.
>
> Bottom line : the lowest significant digit of a float is most always
> incomplete, and as such might not accuratily represent the number it was
> created from.
>
> Regards,
> Rudy Wieser

There's also the translation from binary to decimal to consider.

Anyway, floating point numbers are accurate enough to indicate the
relativity effect of someone going past you on a bicycle so I don't
think there's a problem.

John

John,

> There's also the translation from binary to decimal to consider.

That sounds as if you know of a problem with it. What might that be ?

> Anyway, floating point numbers are accurate enough to indicate the
> relativity effect of someone going past you on a bicycle so I don't think
> there's a problem.

:-) The fact that that BigInt float exists (or even a 80-bit float) does
seem to indicate that there are people out there that disagree with you.

And if being able to do a certain (rather random) task is the yardstick than
I declare that an 8-bit "minifloat" is "big enough for anybody" :-p

.... but its not about if you think there is a/no problem, but about
explaining why the OP sees what he does.

Regards,
Rudy Wieser

I stepped over the example originally via Java and
not JavaScript. I find the following discrepancy between
JDK 19 and JDK 1.8, using Math.pow(), on Windows:

/* JDK 1.8 Windows Nok */
?- X is 1889**29.
X = 1.0250068783051206E95.

/* JDK 19 Windows Ok */
?- X is 1889**29.
X = 1.0250068783051207E95.

?- X is 1.0250068783051207E95-1.0250068783051206E95.
X = 1.4821387422376473E79.

Then I went on and tested nodeJS a little bit. You
can compare with Python as well. I get the following
result, namely the more accurate result, what the

HALF_EVEN rounding of the exact pow() gives:

/* Python 3.11.0rc1 Windows Ok */
>>> 1889**29.0
1.0250068783051207e+95

Would it be possible to upgrade nodeJS somehow?
Maybe I should post in a nodeJS forum. But the error
happens also in Browsers JavaScript, like in Chrome:

/* Chrome Windows Nok */
?- X is 1889**29.
X = 1.0250068783051206E95.

So I guess nodeJS might have imported the error from
Chrome V8 or something. It doesn't happen in FireFox:

/* FireFox Windows Ok */
?- X is 1889**29.
X = 1.0250068783051207E95.

Mostowski Collapse schrieb:
> Welcome to Node.js v18.9.0.
>
>> 1889**29
> 1.0250068783051206e+95
>> Number(BigInt(1889)**BigInt(29))
> 1.0250068783051207e+95
>

Mostowski,

>I stepped over the example originally via Java and
> not JavaScript. I find the following discrepancy between
> JDK 19 and JDK 1.8, using Math.pow(), on Windows:
>
> /* JDK 1.8 Windows Nok */
> ?- X is 1889**29.
> X = 1.0250068783051206E95.
>
> /* JDK 19 Windows Ok */
> ?- X is 1889**29.
> X = 1.0250068783051207E95.
>
> ?- X is 1.0250068783051207E95-1.0250068783051206E95.
> X = 1.4821387422376473E79.

And what do you think you've proven there ?

may I also point out to you that the difference between E95 and E79 is about
exactly the precision of a 64-bit float (~16 digits). IOW, you are again
trying to work with the least-significant bit in a 64-bit float. And that
that most always causes problems. For instance, I would not at all be
surprised when that last number is a simple power of two ...

I think Ben Bacarisse asked you a good question : what is the problem (that
you seem to think you are seeing), and what has it to do with your
subjectline ?

Regards,
Rudy Wieser

P.s.
I've got some numbers for you :

-- 1889*1889*1889*1889*1889* etc. calculated thru the FPU
53A891D176398773 - 1.0250068783051204e+095

The first part is the hexadecimal representation of the resulting 64-bit
float, the latter part is how its represented when displayed for human
consumption (thru fprint "%1.16f"). You might notice it ends on a 4
instead of a 6. This is likely because I didn't bother with any kind of
"fixing up". Adding 1 to the hexadecimal number gives your 6 result.

-- These below two are what I get when my program parses, and than displays
the same two floats you gave in your current post. It looks that my
programming language (parsing the value and storing it in its binary form)
does the same fixing-up JS does.

Notice that the hexadecimal representation shows a single point difference,
just as the displayed human consumption numbers next to them.

53A891D176398774 - 1.0250068783051206e+095
53A891D176398775 - 1.0250068783051207e+095

Notice that both of the numbers you gave can be stored into the binary
representation of a 64-bit float, and my suggestion that it might be a
64-bit vs BigInt float doesn't seem to be the cause of the difference you're
seeing.

Another possibility is that the rounding method (after calculation /
parsing) between the two JDK versions has changed. That /should/ be
mentioned in the "whats changed" section.

-- This is the result of the subtraction of the above first from the second.
As expected the hexadecimal representation shows the fractional part (the
lower 22 bits) as all Zero. Only the exponent part (bits 22 thru 30)
contain some bits set to One.

5060000000000000 - 1.4821387422376473e+079

Bottom line :
1) The rounding method between two JDK versions seem to have changed.
2) The subtraction showing a large, seemingly "random" number is quite
normal. (an effect similar to how decimal fractions cannot always be stored
in a binary representation, but now the other way around).

On 15/10/2022 12:43, R.Wieser wrote:

<snip>
>> Anyway, floating point numbers are accurate enough to indicate the
>> relativity effect of someone going past you on a bicycle so I don't think
>> there's a problem.
>
> :-) The fact that that BigInt float exists (or even a 80-bit float) does
> seem to indicate that there are people out there that disagree with you.
<Snip>

I was indicating that it's not a "can of worms".

John

On 15/10/2022 15:31, R.Wieser wrote:

<snip>
> P.s.
> I've got some numbers for you :
>
> -- 1889*1889*1889*1889*1889* etc. calculated thru the FPU
> 53A891D176398773 - 1.0250068783051204e+095
<snip>

For what it's worth, the correct value of 1889**29 is :

102500687830512064253064716070601123218909116358654017979384519544555980744900395407329380298209

so the ...206 value is most accurate and ...207 is only slightly less
accurate. The ...204 value illustrates why you want to cut down the
number of floating point operations to get an answer. Even so, it is
still good enough for many purposes

John

John,

>> :-) The fact that that BigInt float exists (or even a 80-bit float) does
>> seem to indicate that there are people out there that disagree with you.
> <Snip>
>
> I was indicating that it's not a "can of worms".

Ah thataway. Well, in that case I don't fully agree with you there. You
have to know what you're dealing with not to stumble into a floats pitfalls.

.... as you've eloquently shown in your next message :

> For what it's worth, the correct value of 1889**29 is :
>
> 102500687830512064253064716070601123218909116358654017979384519544555980744900395407329380298209
>
> so the ...206 value is most accurate and ...207 is only slightly less
> accurate. The ...204 value illustrates why you want to cut down the number
> of floating point operations to get an answer.

Although I was aware that multiple divisions (creating small fractional
results) could easily lead to precision problems, I fully overlooked that
those same problems could creep up on you when doing integer multiplications
resulting in big numbers. :-\

Regards,
Rudy Wieser

John Harris <niam@jghnorth.org.uk.invalid> writes:

> On 15/10/2022 15:31, R.Wieser wrote:
>
> <snip>
>> P.s.
>> I've got some numbers for you :
>> -- 1889*1889*1889*1889*1889* etc. calculated thru the FPU
>> 53A891D176398773 - 1.0250068783051204e+095
> <snip>
>
> For what it's worth, the correct value of 1889**29 is :
>
> 102500687830512064253064716070601123218909116358654017979384519544555980744900395407329380298209
>
> so the ...206 value is most accurate and ...207 is only slightly less
> accurate.

True. But neither 1.0250068783051206e95 nor 1.0250068783051207e95 can
be represented in binary floating point. The two representable
numbers closest to 1889**29 are

1025006878305120[5]6620692472528153354473784341513556365963141787204703693721957646169653433597952

and

1025006878305120[7]1442079894904626368690870422625608571181699824406695890772528399182534027509760

So the larger of the two is, in fact, the more accurate. There are two
kinds of accuracy at this level: (1) what binary floating point number
is the closest and, (2) what decimal is the closest representation to
/that/ binary number?

--
Ben.

I wonder whether FireFox always yields the more
accurate values, or whether this is just one example.

Here are some more failures of Chrome,
accuracy of B**E:

B = 1889, E = 29;
B = 1470, E = 56;
B = -1976, E = -49;
B = 3240, E = -18;
B = 2154, E = -6;
B = -182, E = -32;
B = 852, E = 43;
B = 3316, E = -37;
B = 2830, E = 25;
B = 4075, E = -29;
B = -2128, E = 64;

On the other hand Firefox fails here, BTW Python
fails also here, JDK 19 gives a different result:

B = 396, E = -1;

LoL

Ben Bacarisse schrieb am Samstag, 15. Oktober 2022 um 18:04:24 UTC+2:
> John Harris <ni...@jghnorth.org.uk.invalid> writes:
>
> > On 15/10/2022 15:31, R.Wieser wrote:
> >
> > <snip>
> >> P.s.
> >> I've got some numbers for you :
> >> -- 1889*1889*1889*1889*1889* etc. calculated thru the FPU
> >> 53A891D176398773 - 1.0250068783051204e+095
> > <snip>
> >
> > For what it's worth, the correct value of 1889**29 is :
> >
> > 102500687830512064253064716070601123218909116358654017979384519544555980744900395407329380298209
> >
> > so the ...206 value is most accurate and ...207 is only slightly less
> > accurate.
> True. But neither 1.0250068783051206e95 nor 1.0250068783051207e95 can
> be represented in binary floating point. The two representable
> numbers closest to 1889**29 are
>
> 1025006878305120[5]6620692472528153354473784341513556365963141787204703693721957646169653433597952
>
> and
>
> 1025006878305120[7]1442079894904626368690870422625608571181699824406695890772528399182534027509760
>
> So the larger of the two is, in fact, the more accurate. There are two
> kinds of accuracy at this level: (1) what binary floating point number
> is the closest and, (2) what decimal is the closest representation to
> /that/ binary number?
>
> --
> Ben.

Versions used, both 64-bit on Windows 10:

Chrome 106.0.5249.119
Firefox 105.0.3

Mostowski Collapse schrieb:
> I wonder whether FireFox always yields the more
> accurate values, or whether this is just one example.
>
> Here are some more failures of Chrome,
> accuracy of B**E:
>
> B = 1889, E = 29;
> B = 1470, E = 56;
> B = -1976, E = -49;
> B = 3240, E = -18;
> B = 2154, E = -6;
> B = -182, E = -32;
> B = 852, E = 43;
> B = 3316, E = -37;
> B = 2830, E = 25;
> B = 4075, E = -29;
> B = -2128, E = 64;
>
> On the other hand Firefox fails here, BTW Python
> fails also here, JDK 19 gives a different result:
>
> B = 396, E = -1;
>
> LoL
>
> Ben Bacarisse schrieb am Samstag, 15. Oktober 2022 um 18:04:24 UTC+2:
>> John Harris <ni...@jghnorth.org.uk.invalid> writes:
>>
>>> On 15/10/2022 15:31, R.Wieser wrote:
>>>
>>> <snip>
>>>> P.s.
>>>> I've got some numbers for you :
>>>> -- 1889*1889*1889*1889*1889* etc. calculated thru the FPU
>>>> 53A891D176398773 - 1.0250068783051204e+095
>>> <snip>
>>>
>>> For what it's worth, the correct value of 1889**29 is :
>>>
>>> 102500687830512064253064716070601123218909116358654017979384519544555980744900395407329380298209
>>>
>>> so the ...206 value is most accurate and ...207 is only slightly less
>>> accurate.
>> True. But neither 1.0250068783051206e95 nor 1.0250068783051207e95 can
>> be represented in binary floating point. The two representable
>> numbers closest to 1889**29 are
>>
>> 1025006878305120[5]6620692472528153354473784341513556365963141787204703693721957646169653433597952
>>
>> and
>>
>> 1025006878305120[7]1442079894904626368690870422625608571181699824406695890772528399182534027509760
>>
>> So the larger of the two is, in fact, the more accurate. There are two
>> kinds of accuracy at this level: (1) what binary floating point number
>> is the closest and, (2) what decimal is the closest representation to
>> /that/ binary number?
>>
>> --
>> Ben.

On Saturday, 15 October 2022 at 00:52:31 UTC+2, Mostowski Collapse wrote:
> Welcome to Node.js v18.9.0.
>
> > 1889**29
> 1.0250068783051206e+95
> > Number(BigInt(1889)**BigInt(29))
> 1.0250068783051207e+95

Numerics: another thing you have never known shit
about and still manage to write bullshit across all
groups ad nauseam.

You really don't understand the damage you are doing,
here as elsewhere, do you, you piece of retarded shit,
or you too just working for the nazi monster??

*Troll-spammer-crank alert*

Julio

Nazi Monster. Do you mean Putin?

LoL

ju...@diegidio.name schrieb am Montag, 17. Oktober 2022 um 11:00:24 UTC+2:
> On Saturday, 15 October 2022 at 00:52:31 UTC+2, Mostowski Collapse wrote:
> > Welcome to Node.js v18.9.0.
> >
> > > 1889**29
> > 1.0250068783051206e+95
> > > Number(BigInt(1889)**BigInt(29))
> > 1.0250068783051207e+95
> Numerics: another thing you have never known shit
> about and still manage to write bullshit across all
> groups ad nauseam.
>
> You really don't understand the damage you are doing,
> here as elsewhere, do you, you piece of retarded shit,
> or you too just working for the nazi monster??
>
> *Troll-spammer-crank alert*
>
> Julio

I also get, on Windows:

Welcome to Node.js v18.9.0.
> 2.718281828459045**0.8618974796837966
2.367649

Nice try, but isn't this one the more correct?

?- X is 2.718281828459045**0.8618974796837966.
X = 2.3676489999999997.

Mostowski Collapse schrieb am Samstag, 15. Oktober 2022 um 18:52:04 UTC+2:
> Versions used, both 64-bit on Windows 10:
>
> Chrome 106.0.5249.119
> Firefox 105.0.3
>
> Mostowski Collapse schrieb:
> > I wonder whether FireFox always yields the more
> > accurate values, or whether this is just one example.
> >
> > Here are some more failures of Chrome,
> > accuracy of B**E:
> >
> > B = 1889, E = 29;
> > B = 1470, E = 56;
> > B = -1976, E = -49;
> > B = 3240, E = -18;
> > B = 2154, E = -6;
> > B = -182, E = -32;
> > B = 852, E = 43;
> > B = 3316, E = -37;
> > B = 2830, E = 25;
> > B = 4075, E = -29;
> > B = -2128, E = 64;
> >
> > On the other hand Firefox fails here, BTW Python
> > fails also here, JDK 19 gives a different result:
> >
> > B = 396, E = -1;
> >
> > LoL
> >
> > Ben Bacarisse schrieb am Samstag, 15. Oktober 2022 um 18:04:24 UTC+2:
> >> John Harris <ni...@jghnorth.org.uk.invalid> writes:
> >>
> >>> On 15/10/2022 15:31, R.Wieser wrote:
> >>>
> >>> <snip>
> >>>> P.s.
> >>>> I've got some numbers for you :
> >>>> -- 1889*1889*1889*1889*1889* etc. calculated thru the FPU
> >>>> 53A891D176398773 - 1.0250068783051204e+095
> >>> <snip>
> >>>
> >>> For what it's worth, the correct value of 1889**29 is :
> >>>
> >>> 102500687830512064253064716070601123218909116358654017979384519544555980744900395407329380298209
> >>>
> >>> so the ...206 value is most accurate and ...207 is only slightly less
> >>> accurate.
> >> True. But neither 1.0250068783051206e95 nor 1.0250068783051207e95 can
> >> be represented in binary floating point. The two representable
> >> numbers closest to 1889**29 are
> >>
> >> 1025006878305120[5]6620692472528153354473784341513556365963141787204703693721957646169653433597952
> >>
> >> and
> >>
> >> 1025006878305120[7]1442079894904626368690870422625608571181699824406695890772528399182534027509760
> >>
> >> So the larger of the two is, in fact, the more accurate. There are two
> >> kinds of accuracy at this level: (1) what binary floating point number
> >> is the closest and, (2) what decimal is the closest representation to
> >> /that/ binary number?
> >>
> >> --
> >> Ben.

Ha Ha, these Machin like formulas are
undershooting and overshooting:

Welcome to Node.js v19.1.0.
> 28*Math.atan(1/9)+4*Math.atan(4765/441284)
3.1415926535897927
> 20*Math.atan(1/7)+8*Math.atan(3/79)
3.141592653589793
> 48*Math.atan(1/16)+4*Math.atan(14818029403841/407217467325761)
3.1415926535897936

Credits: Machin's Merit
https://www.mathpages.com/home/kmath373/kmath373.htm