1889**291.0250068783051206e+95
Number(BigInt(1889)**BigInt(29))1.0250068783051207e+95
Welcome to Node.js v18.9.0.
1889**291.0250068783051206e+95
Number(BigInt(1889)**BigInt(29))1.0250068783051207e+95
1889**291.0250068783051206e+95
Number(BigInt(1889)**BigInt(29))1.0250068783051207e+95
IOW, you could be looking at a 01xxb (with "x" being zero) for the 64-bit float against a 0110b for the BigInt float.
IOW, you could be looking at a 011xb (with "x" being zero) for the 64-bit float against a 0111b for the BigInt float.
Mostowski,
1889**291.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.
1.0250068783051207e+951889**29.0
Welcome to Node.js v18.9.0.
1889**291.0250068783051206e+95
Number(BigInt(1889)**BigInt(29))1.0250068783051207e+95
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.
<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.
P.s.<snip>
I've got some numbers for you :
-- 1889*1889*1889*1889*1889* etc. calculated thru the FPU
53A891D176398773 - 1.0250068783051204e+095
:-) The fact that that BigInt float exists (or even a 80-bit float) does<Snip>
seem to indicate that there are people out there that disagree with you.
I was indicating that it's not a "can of worms".
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.
On 15/10/2022 15:31, R.Wieser wrote:
<snip>
P.s.<snip>
I've got some numbers for you :
-- 1889*1889*1889*1889*1889* etc. calculated thru the FPU
53A891D176398773 - 1.0250068783051204e+095
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.
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:True. But neither 1.0250068783051206e95 nor 1.0250068783051207e95 can
<snip>
P.s.<snip>
I've got some numbers for you :
-- 1889*1889*1889*1889*1889* etc. calculated thru the FPU
53A891D176398773 - 1.0250068783051204e+095
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.
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.
John Harris <ni...@jghnorth.org.uk.invalid> writes:
On 15/10/2022 15:31, R.Wieser wrote:
<snip>
P.s.<snip>
I've got some numbers for you :
-- 1889*1889*1889*1889*1889* etc. calculated thru the FPU
53A891D176398773 - 1.0250068783051204e+095
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.
Welcome to Node.js v18.9.0.
1889**291.0250068783051206e+95
Number(BigInt(1889)**BigInt(29))1.0250068783051207e+95
On Saturday, 15 October 2022 at 00:52:31 UTC+2, Mostowski Collapse wrote:
Welcome to Node.js v18.9.0.
Numerics: another thing you have never known shit1889**291.0250068783051206e+95
Number(BigInt(1889)**BigInt(29))1.0250068783051207e+95
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
2.718281828459045**0.86189747968379662.367649
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:True. But neither 1.0250068783051206e95 nor 1.0250068783051207e95 can
<snip>
P.s.<snip>
I've got some numbers for you :
-- 1889*1889*1889*1889*1889* etc. calculated thru the FPU
53A891D176398773 - 1.0250068783051204e+095
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.
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.
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
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 248 |
Nodes: | 16 (2 / 14) |
Uptime: | 47:22:58 |
Calls: | 5,498 |
Calls today: | 6 |
Files: | 11,665 |
Messages: | 5,044,792 |
Posted today: | 3 |