5 ms·

But in software, integers are _not_ a subset of floats. There are numbers that can be represented using an n-bit integer that cannot be represented using an n-b

But in software, integers are _not_ a subset of floats. There are numbers that can be represented using an n-bit integer that cannot be represented using an n-bit float, and vice versa. Converting between the two automatically can lose information.

throwawaymaths 4y ago
That's a bad argument because almost every floating point operation loses information of some sort of another. Should we ban all floating point operations on those grounds? Moreover in many cases int * float is an intrinsic, so on the hardware level there is no conversion operation interposed into the operator.
- aw1621107 4y ago
  > Moreover in many cases int * float is an intrinsic, so on the hardware level there is no conversion operation interposed into the operator. Out of curiosity, what instructions support mixed integer/floating-point operands? I can think of integer-/floating-point-only instructions off the top of my head, and I know I've seen conversion instructions, but not mixed ones. I'm hardly an assembly expert, though, so I wouldn't be surprised if I just wasn't aware of such a thing.
  - throwawaymaths 4y ago
    FIMUL
    - aw1621107 4y ago
      Huh, first time I've seen that instruction. Thanks! Does seem that it converts its arguments first, though? > The FIMUL instructions convert an integer source operand to double extended-precision floating-point format before performing the multiplication. (Via https://www.felixcloutier.com/x86/fmul:fmulp:fimul https://www.felixcloutier.com/x86/fmul:fmulp:fimul) In addition, I thought compilers tended to avoid the x87 FPU registers nowadays?
BenjiWiebe 4y ago
But in the case of multiplying by a float, you will have to lose information by either appending a .0 to your number to floatify it, or lose information by letting the compiler do it. At the end of the day you still need the float multiplied.
- Volundr 4y ago
  Or I can realize "shit I've got a float and I'm dealing with currency, let me make that an integer of cents instead". Or "wait all of these should be a ratio type". The ways of resolving this situation is endless. Float is far from the only option.
- RHSeeger 4y ago
  Adding the .0 expresses your intent that it is a float. Expressing intent in the code is a form of documentation and makes the code easier to maintain; someone coming later can tell you meant it to be one way, vs it accidentally being that way. It's no different than adding parens around elements in a math formula when they're not needed; if the formula is complex enough, adding some parens to group things can make it clearer to the person reading it, even if it doesn't actually change the behavior.
BenFrantzDale 4y ago
IIRc, 23-bit ints are a subset of float32, and up to 50-something-bit ints are a subset of float64s, so on most architectures, int (32) is a subset of double (64).
- estebank 4y ago
  This is the reason that i32/u32/i16/u16/i8/u8 can be infallibly converted to f64 using the From/Into traits[1]. [1]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=68793853e823d2dc31f648d3f6b9c4d5 https://play.rust-lang.org/?version=stable&mode=debug&editio...

throwawaymaths 4y ago

That's a bad argument because almost every floating point operation loses information of some sort of another. Should we ban all floating point operations on those grounds? Moreover in many cases int * float is an intrinsic, so on the hardware level there is no conversion operation interposed into the operator.

aw1621107 4y ago
> Moreover in many cases int * float is an intrinsic, so on the hardware level there is no conversion operation interposed into the operator. Out of curiosity, what instructions support mixed integer/floating-point operands? I can think of integer-/floating-point-only instructions off the top of my head, and I know I've seen conversion instructions, but not mixed ones. I'm hardly an assembly expert, though, so I wouldn't be surprised if I just wasn't aware of such a thing.
- throwawaymaths 4y ago
  FIMUL
  - aw1621107 4y ago
    Huh, first time I've seen that instruction. Thanks! Does seem that it converts its arguments first, though? > The FIMUL instructions convert an integer source operand to double extended-precision floating-point format before performing the multiplication. (Via https://www.felixcloutier.com/x86/fmul:fmulp:fimul https://www.felixcloutier.com/x86/fmul:fmulp:fimul) In addition, I thought compilers tended to avoid the x87 FPU registers nowadays?

BenjiWiebe 4y ago

But in the case of multiplying by a float, you will have to lose information by either appending a .0 to your number to floatify it, or lose information by letting the compiler do it. At the end of the day you still need the float multiplied.

Volundr 4y ago
Or I can realize "shit I've got a float and I'm dealing with currency, let me make that an integer of cents instead". Or "wait all of these should be a ratio type". The ways of resolving this situation is endless. Float is far from the only option.
RHSeeger 4y ago
Adding the .0 expresses your intent that it is a float. Expressing intent in the code is a form of documentation and makes the code easier to maintain; someone coming later can tell you meant it to be one way, vs it accidentally being that way. It's no different than adding parens around elements in a math formula when they're not needed; if the formula is complex enough, adding some parens to group things can make it clearer to the person reading it, even if it doesn't actually change the behavior.

BenFrantzDale 4y ago

IIRc, 23-bit ints are a subset of float32, and up to 50-something-bit ints are a subset of float64s, so on most architectures, int (32) is a subset of double (64).

estebank 4y ago
This is the reason that i32/u32/i16/u16/i8/u8 can be infallibly converted to f64 using the From/Into traits[1]. [1]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=68793853e823d2dc31f648d3f6b9c4d5 https://play.rust-lang.org/?version=stable&mode=debug&editio...