4 ms·

This should be obvious. There are the same number of 32-bit integers as 32-bit floats [0], so for every float that is not an int, there exists an int that is no

This should be obvious. There are the same number of 32-bit integers as 32-bit floats [0], so for every float that is not an int, there exists an int that is not a float. Clearly most floats cannot be represented as integers, so the converse must be true as well. But I still see people building systems where implicit conversation of float to int is not allowed because "it would lose precision", but that allow int to float. [0] don't reply to me about NaNs, please

worik 1y ago
> This should be obvious Yes They are different types They are different things They are related concepts, that is all
Kranar 1y ago
Sure but at least in my experience it's rare to convert 32 bit ints to 32 bit float. Usually the conversion is 32 bit int to 64 bit float, which is always safe.
deleted 1y ago
[deleted]
nofriend 1y ago
Floats have a fixed accuracy everywhere. Ints have a variable accuracy across their range. When you convert from int to float, the number stays accurate to however many digits, say 8 digits for single precision. Ints have a fixed precision everywhere, whereas for floats it varies. A given float might be accurate to one part in 10^30. When you cast to int, you get accuracy to within 1 part in 1. So you lose far more orders of magnitude of precision converting from float to int then you lose in order of magnitude of accuracy converting from int to float.
- titzer 1y ago
  > When you convert from int to float, the number stays accurate to however many digits The point of the article is that this "however many digits" actually implies rounding many numbers that aren't that big. A single precision (i.e. 32-bit) float cannot exactly represent some 32-bit integers. For example 1_234_567_891f is actually rounded to 1_234_567_936. This is because there are only 23 bits of fraction available (https://en.wikipedia.org/wiki/Single-precision_floating-point_format https://en.wikipedia.org/wiki/Single-precision_floating-poin...).
- tomtom1337 1y ago
  You have a typo: In your last sentence you effectively wrote «from int to float» twice in contradicting ways. «To float from int than (…) from int to float».
  - nofriend 1y ago
    there was an error made when I went back to edit what I wrote...
- dmurray 1y ago
  Floats have the same accuracy everywhere when measured in relative error, ints have the same accuracy everywhere when measuring absolutely. Which of those is better? It depends on the application. All you can do is hope the person who gave you the numbers chose the more appropriate representation, the less painful way to lose fidelity in a representation of the real world. By converting to the other representation you now have lost that fidelity in both ways. Again, by a similar argument to above, something like this has to be true. You have exactly 32 bits of information either way, and both conversions lose the same amount of information - you end up with a 32-bit representation, but it only represents a domain of 2^27 (or whatever it is) distinct numbers.
  - nofriend 1y ago
    >both conversions lose the same amount of information This is exactly what's untrue. I said "orders of magnitude", but I could have said bits - they're analogous concepts. Ints with the high 9 bits set to zero lose no information when converting to single precision floating point. The rest lose progressively more information, concentrated in the low order bits, up to 8 bits. Certainly regrettable, but usually manageable. Converting from floats to ints might be representable exactly, but if the number is, say, near 1, then it will be rounded to 1, losing 23 bits of information. If the number is near 0 then it will be rounded to 0, losing 31 bits of information.
bee_rider 1y ago
It is shocking to think about it, but a lot of programmers don’t think about bits at all, and just think of floats as reals. Or maybe if you prod them enough, they’ll treat the floats as sometimes inaccurate reals.
- haiku2077 1y ago
  I cringe whenever I hear floats described as "decimals" :(
  - bee_rider 1y ago
    I try not to be too picky about this sort of stuff, but “decimals” is really bad, haha! It is like wrong in a way that is specific, which somehow makes it even more wrong than just saying “approximately reals.” IEEE actually has a decimal float format defined. I don’t know if any system uses it, though (my suspicion is it must be pretty niche).
- adastra22 1y ago
  Because int -> float is well defined. If you cast an int to a float, you’re getting a value that represents the first six significant figures of the original integer. Always. The precision of casting float to int, on the other hand, depends on the input.
mamcx 1y ago
> but that allow int to float. And not think what happened when people do `i64 as usize` and friends (This is one are where the pascal have it right, including the fact you should do loops like `for I in low(nuts)..high(nuts)`) p.d: 'nuts' was the autocorrect choice that somehow is topical here so I keep it.
Aardwolf 1y ago
> [0] don't reply to me about NaNs, please The question is why they added so many NaNs to the spec, instead of just one. Probably for a signal, but who actually uses that? For IEEE float16 the amount of lacking values due to an entire exponent value being needlessly taken up by NaNs is actually quite blatant.
- spc476 1y ago
  You could store the address of the offending instruction/code sequence that generated the NaN (think software-only implementation).

worik 1y ago

> This should be obvious Yes They are different types They are different things They are related concepts, that is all

Kranar 1y ago

Sure but at least in my experience it's rare to convert 32 bit ints to 32 bit float. Usually the conversion is 32 bit int to 64 bit float, which is always safe.

deleted 1y ago

[deleted]

nofriend 1y ago

Floats have a fixed accuracy everywhere. Ints have a variable accuracy across their range. When you convert from int to float, the number stays accurate to however many digits, say 8 digits for single precision. Ints have a fixed precision everywhere, whereas for floats it varies. A given float might be accurate to one part in 10^30. When you cast to int, you get accuracy to within 1 part in 1. So you lose far more orders of magnitude of precision converting from float to int then you lose in order of magnitude of accuracy converting from int to float.

titzer 1y ago
> When you convert from int to float, the number stays accurate to however many digits The point of the article is that this "however many digits" actually implies rounding many numbers that aren't that big. A single precision (i.e. 32-bit) float cannot exactly represent some 32-bit integers. For example 1_234_567_891f is actually rounded to 1_234_567_936. This is because there are only 23 bits of fraction available (https://en.wikipedia.org/wiki/Single-precision_floating-point_format https://en.wikipedia.org/wiki/Single-precision_floating-poin...).
tomtom1337 1y ago
You have a typo: In your last sentence you effectively wrote «from int to float» twice in contradicting ways. «To float from int than (…) from int to float».
- nofriend 1y ago
  there was an error made when I went back to edit what I wrote...
dmurray 1y ago
Floats have the same accuracy everywhere when measured in relative error, ints have the same accuracy everywhere when measuring absolutely. Which of those is better? It depends on the application. All you can do is hope the person who gave you the numbers chose the more appropriate representation, the less painful way to lose fidelity in a representation of the real world. By converting to the other representation you now have lost that fidelity in both ways. Again, by a similar argument to above, something like this has to be true. You have exactly 32 bits of information either way, and both conversions lose the same amount of information - you end up with a 32-bit representation, but it only represents a domain of 2^27 (or whatever it is) distinct numbers.
- nofriend 1y ago
  >both conversions lose the same amount of information This is exactly what's untrue. I said "orders of magnitude", but I could have said bits - they're analogous concepts. Ints with the high 9 bits set to zero lose no information when converting to single precision floating point. The rest lose progressively more information, concentrated in the low order bits, up to 8 bits. Certainly regrettable, but usually manageable. Converting from floats to ints might be representable exactly, but if the number is, say, near 1, then it will be rounded to 1, losing 23 bits of information. If the number is near 0 then it will be rounded to 0, losing 31 bits of information.

bee_rider 1y ago

It is shocking to think about it, but a lot of programmers don’t think about bits at all, and just think of floats as reals. Or maybe if you prod them enough, they’ll treat the floats as sometimes inaccurate reals.

haiku2077 1y ago
I cringe whenever I hear floats described as "decimals" :(
- bee_rider 1y ago
  I try not to be too picky about this sort of stuff, but “decimals” is really bad, haha! It is like wrong in a way that is specific, which somehow makes it even more wrong than just saying “approximately reals.” IEEE actually has a decimal float format defined. I don’t know if any system uses it, though (my suspicion is it must be pretty niche).
adastra22 1y ago
Because int -> float is well defined. If you cast an int to a float, you’re getting a value that represents the first six significant figures of the original integer. Always. The precision of casting float to int, on the other hand, depends on the input.

mamcx 1y ago

> but that allow int to float. And not think what happened when people do `i64 as usize` and friends (This is one are where the pascal have it right, including the fact you should do loops like `for I in low(nuts)..high(nuts)`) p.d: 'nuts' was the autocorrect choice that somehow is topical here so I keep it.

Aardwolf 1y ago

> [0] don't reply to me about NaNs, please The question is why they added so many NaNs to the spec, instead of just one. Probably for a signal, but who actually uses that? For IEEE float16 the amount of lacking values due to an entire exponent value being needlessly taken up by NaNs is actually quite blatant.

spc476 1y ago
You could store the address of the offending instruction/code sequence that generated the NaN (think software-only implementation).