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

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

Are Floating Point Numbers still a Can of Worms?

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

Contents

  Are Floating Point Numbers still a Can of Worms? Mostowski Collapse <bursejan@gmail.com> - 2022-10-14 15:52 -0700
    Re: Are Floating Point Numbers still a Can of Worms? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-15 01:52 +0100
    Re: Are Floating Point Numbers still a Can of Worms? "R.Wieser" <address@not.available> - 2022-10-15 09:33 +0200
      Re: Are Floating Point Numbers still a Can of Worms? "R.Wieser" <address@not.available> - 2022-10-15 10:00 +0200
      Re: Are Floating Point Numbers still a Can of Worms? John Harris <niam@jghnorth.org.uk.invalid> - 2022-10-15 11:13 +0100
        Re: Are Floating Point Numbers still a Can of Worms? "R.Wieser" <address@not.available> - 2022-10-15 13:43 +0200
          Re: Are Floating Point Numbers still a Can of Worms? John Harris <niam@jghnorth.org.uk.invalid> - 2022-10-15 15:56 +0100
            Re: Are Floating Point Numbers still a Can of Worms? "R.Wieser" <address@not.available> - 2022-10-15 17:44 +0200
    Re: Are Floating Point Numbers still a Can of Worms? Mostowski Collapse <janburse@fastmail.fm> - 2022-10-15 14:25 +0200
      Re: Are Floating Point Numbers still a Can of Worms? "R.Wieser" <address@not.available> - 2022-10-15 16:31 +0200
        Re: Are Floating Point Numbers still a Can of Worms? John Harris <niam@jghnorth.org.uk.invalid> - 2022-10-15 16:22 +0100
          Re: Are Floating Point Numbers still a Can of Worms? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-15 17:04 +0100
            Re: Are Floating Point Numbers still a Can of Worms? Mostowski Collapse <bursejan@gmail.com> - 2022-10-15 09:47 -0700
              Re: Are Floating Point Numbers still a Can of Worms? Mostowski Collapse <janburse@fastmail.fm> - 2022-10-15 18:51 +0200
                Re: Are Floating Point Numbers still a Can of Worms? Mostowski Collapse <bursejan@gmail.com> - 2022-10-22 14:35 -0700
                  Re: Are Floating Point Numbers still a Can of Worms? Mostowski Collapse <bursejan@gmail.com> - 2022-11-21 09:02 -0800
    Re: Are Floating Point Numbers still a Can of Worms? Julio Di Egidio <julio@diegidio.name> - 2022-10-17 02:00 -0700
      Re: Are Floating Point Numbers still a Can of Worms? Mostowski Collapse <bursejan@gmail.com> - 2022-10-18 07:40 -0700

#41097 — Are Floating Point Numbers still a Can of Worms?

Welcome to Node.js v18.9.0.

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

[toc] | [next] | [standalone]

#41098

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.

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

#41099

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

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

#41100

> 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

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

#41101

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

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

#41102

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

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

#41105

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

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

#41107

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

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

#41103

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
> 

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

#41104

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

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

#41106

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

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

#41108

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.

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

#41109

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.

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

#41110

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.

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

#41117

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.

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

#41125

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

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

#41112

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

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

#41115

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

[toc] | [prev] | [standalone]

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

csiph-web