For the stalkers information, maybe the more correct word is not
precision, but accuracy. The below result has the expected
precision, i.e. the pow() function produces 53 bits mantissa of
the floating point value, the decimal representation might not
show that, but I guess a C double precision floating point
functions computes 53 bits of some mantiassa, and the
Python floats we see below are the same as the
C double precision floating point values:
Python 3.11.0rc1 (main, Aug 8 2022, 11:30:54)
2.718281828459045**0.8618974796837966
2.367649
Unfortunately its not accurate up to 0.5 ULP. Lets compute the
error in terms of ULP via microsoft calculator. What errors do we
have for the two floating point numbers?
0.0000000000000002827223584919617 /
2.3676489999999998318739739314273 * 2^52 =
0.53777747814549647686988825277067
0.000000000000000161366851358101 /
2.3676489999999998318739739314273 * 2^52 =
0.30694232618360826777706134718012
So the second floating point value, not the number
returned by Python, has a relative error less than 0.5 ULP,
and the first floating point value has a relative error
above 0.5 ULP. If the error is more than 0.5 ULP its not
anymore correctly rounded only nearly rounded.
Mostowski Collapse schrieb am Dienstag, 25. Oktober 2022 um 13:30:52 UTC+2:
Is this the same Schachner, Joseph that posted:
Subject: ANN: Dogelog Runtime, Prolog to the Moon (2021)
Message-ID: <BN8PR14MB28516E1052...@BN8PR14MB2851.namprd14.prod.outlook.com>
Opinion: Anyone who is counting on Python for truly fast
compute speed is probably using Python for the wrong purpose.
Here, we use Python to control Test Equipment, to set up the
equipment and ask for a measurement, get it, and proceed to
the next measurement; and at the end produce a nice formatted
report. If we wrote the test script in C or Rust or whatever it could
not run substantially faster because it is communicating with
the test equipment, setting it up and waiting for responses, and
that is where the vast majority of the time goes. Especially
if the measurement result requires averaging it can take a while.
In my opinion this is an ideal use for Python, not just because
the speed of Python is not important, but also because we can
easily find people who know Python, who like coding in Python,
and will join the company to program in Python ... and stay with us.
--- Joseph S.
Congratulations you already communicated in 2021 that speed is not necessecary. So whats your opinion now in 2022, precision is not necessary? Well, well, you are surely an expert in lowering the bar.
LMAO!
Schachner, Joseph (US) schrieb am Montag, 24. Oktober 2022 um 16:54:04 UTC+2:
Floating point will always be a can of worms, as long as
people expect it to represent real numbers with more precision
that float has. Usually this is not an issue, but sometimes it is.
And, although this example does not exhibit subtractive cancellation,
that is the surest way to have less precision that the two values
you subtracted. And if you try to add up lots of values, if your sum
grows large enough, tiny values will not change it anymore, even
if there are many of them - there are simple algorithms to avoid
this effect. But all of this is because float has limited precision.
--- Joseph S.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)