4 ms·
Floating-point numbers, existing on finite computers, are just erroneous approximations of real numbers, so the same operation on floating-point and on ints mea
by ArchD 4y ago
Floating-point numbers, existing on finite computers, are just erroneous approximations of real numbers, so the same operation on floating-point and on ints means different things, yielding different results. Thus, allowing the programmer to magically unconsciously convert between floating-point and ints is a recipe for disaster arising from hidden/misunderstood floating-point error.
The safe way is to require the programmer intend about the type to use to be clear in the code and to force the programmer to be mindful about whether or not he is using floating-point. This is just what some languages do, including Rust.
In the first example, the author is essentially complaining that he has to type '2.0' instead of '2'. I don't think that's a lot of extra typing.
Perhaps it is good and convenient to have automatic int-to-float conversion, but such conversion involves error if the int values are large. Conversion in the opposite direction is similarly lossy/erroneous, even if the floating-point type can represent every real number perfectly, since not every floating-point value is an int value. Even with a perfect floating-point type, supporting automatic conversion only in one direction is weird/confusing from a user-interface POV, so the normal thing to do is to just not do automatic conversion.
To drive the point about floating-point error, perhaps some people complaining about lack of automatic conversion may be surprised by how the following round-trip conversion between int64 and float64 accumulates error, as demonstrated in a Python interpreter:
>>> int(float(0xffffffffffffff)) - 0xffffffffffffff
1
If you drop one digit, there is no error. A language forcing you to do the conversion explicitly forces you to be mindful of the potential for floating-point error. A language that does automatic conversion promotes blissful thinking and eventually big surprise.
- move-on-by 4y agoI’ve certainly spent way too much time tracking down and fixing these automatic conversations to bat an eye at any extra verbosity required to make the intent clear.
- e_i_pi_2 4y agoMy best story of this is JS integer parsing - we were passing IDs to the frontend through C# as ints, parsed by JS on the frontend from the JSON HTTP response. We spent at least a day trying to figure out why our links weren't working and it was because our numbers were too big for JS In a browser console it drops off after 16 digits and right-pads with zeros > 11111111111111111111 > 11111111111111110000 Our solution was to pass all IDs as strings because they aren't ever going to be manipulated like a number will
- throwawaymaths 4y agoWhile implicitly converting floats to ints is bad, performing a float operation (especially multiplication or division) with an int is meaningful and should not be banned. I can only have discrete buckets of things. These things have a floating point weight. What is the total weight? Forcing explicit conversion of your int to a float to do the multiplication is semantically wrong. I could live with banning int + float or int - float. It's almost as bad as go requiring you to convert a number to a time to figure out the integer multiple of a time interval.
- HWR_14 4y agoFloat divided by int or int divided by float is also an issue. Does 4.25 / 2 equal 2.125 or 2? Does 16 / 3.25 equal 4 or 5 or some floating point number in between?
- throwawaymaths 4y agoYou do what FIMUL does. The other options are silly.
- HWR_14 4y agoI don't understand. You want to convert everything to floats all the time? Then just start and stay in float-land and never use ints.
- ArchD 4y agoInt-to-float conversion is lossy, as my Python example demonstrates, and thus should not be automatic. Performing a float op with an int, which you said should be allowed, entails automatic int-to-float conversion before the op, does it not?
- throwawaymaths 4y agoLossy doesn't make sense as a criterion with floats. Float to float addition can be lossy. Whether there is a conversion is architecture dependent. I believe x86 has an opcode for direct multiplication.