On Tue, Jul 9, 2024 at 10:47 AM Tim Düsterhus <t...@bastelstu.be> wrote:
> Hi > > On 7/8/24 11:36, Jordan LeDoux wrote: > > I suspected the same thing when I was doing my arbitrary precision > library, > > but I actually have yet to find a test case in all my unit tests where > this > > happens when converting to a string. You can see this here: > > > > https://3v4l.org/Ud8Cn > > PHP emits the shortest possible representation that roundtrips, so the > precision loss indeed does not happen when converting from float, but > rather when converting to float / when the implicit rounding happens > during the calculation. > > Nevertheless the inherent rounding error of floats and an arbitrary > precision maths library do not mix: Users should not be encouraged to > mindlessly pass a float, but rather work with strings all the time or > explicitly perform the necessary conversion as appropriate for their use > case - which of course is easier with strict_types enabled because then > the conversion would need to be made explicit with a cast. > > Best regards > Tim Düsterhus > Yes, absolutely agree that arbitrary precision math should not be done with floats, and developers should not be encouraged to use floats. However for the specific case of type-coercion into the argument of a `bcadd` or similar call, the detailed string conversion issues do not happen, which is all I was saying. Integers ALSO have a maximum precision, detailed by the `PHP_INT_MAX` constant, which varies by system and install (mainly on whether 64-bit integers are available). My point was not that floats or integers are sufficient, but that the entry point into an arbitrary precision calculation often comes from numbers that are stored as ints and floats. If we accept ints, and don't ask the developer to explicitly cast to string, I think we should do the same for floats. Both or neither. I can see the argument against accepting either, I can see the argument for accepting either. I do not understand the argument for accepting one but not the other. Jordan
