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. Teledyne Confidential; Commercially Sensitive Business Data -----Original Message----- From: Pieter van Oostrum <piete...@vanoostrum.org> Sent: Sunday, October 23, 2022 10:25 AM To: python-list@python.org Subject: Re: Are Floating Point Numbers still a Can of Worms? Mostowski Collapse <burse...@gmail.com> writes: > I also get: > > Python 3.11.0rc1 (main, Aug 8 2022, 11:30:54) >>>> 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. > That's probably the accuracy of the underlying C implementation of the exp function. In [25]: exp(0.8618974796837966) Out[25]: 2.367649 But even your answer can be improved: Maxima: (%i1) fpprec:30$ (%i2) bfloat(2.718281828459045b0)^bfloat(.8618974796837966b0); (%o2) 2.36764899999999983187397393143b0 but: (%i7) bfloat(%e)^bfloat(.8618974796837966b0); (%o7) 2.3676490000000000085638369695b0 surprisingly closer to Python's answer. but 2.718281828459045 isn't e. Close but no cigar. (%i10) bfloat(2.718281828459045b0) - bfloat(%e); (%o10) - 2.35360287471352802147785151603b-16 Fricas: (1) -> 2.718281828459045^0.8618974796837966 (1) 2.3676489999_999998319 (2) -> exp(0.8618974796837966) (2) 2.3676490000_000000086 -- Pieter van Oostrum <pie...@vanoostrum.org> www: http://pieter.vanoostrum.org/ PGP key: [8DAE142BE17999C4] -- https://mail.python.org/mailman/listinfo/python-list
