4 ms·

This feels like a bad idea. Treating +0 and -0 as unequal because they have different bit patterns is no more correct than treating two NaNs as equal because th

This feels like a bad idea. Treating +0 and -0 as unequal because they have different bit patterns is no more correct than treating two NaNs as equal because they have the same bit pattern. Zero is zero.

jbverschoor 4y ago
Unless you’re approaching the limit of 0 from one side But yeah, you’re right
andrewmcwatters 4y ago
Zero is zero, but signs are a direction. There are multiple parts to numbers. Stand in place and turn around: how far did you go from where you started? Nonetheless, I agree. It's a bad idea.
- quietbritishjim 4y ago
  By that logic there should be e.g. +4.0 and +4.0- (for when you go 4m forwards vs when you go 4m forwards but also turn around at the end).
  - andrewmcwatters 4y ago
    In vector maths, this would just be +4.0.
    - Dylan16807 4y ago
      And the same is true of zero. Especially when you consider a two-dimensional vector. How would you encode/interpret facing in a complex zero?
mananaysiempre 4y ago
IEEE 754’s idea was that if you got a zero in a floating-point calculation (which, at the time, meant one with physical quantities), it’s probably underflow, not a legitimate result, so the FPU might as well try to give you at least a sign even if it can’t give you any significant digits. Though 754 says comparison must treat positive and negative zero as equal nevertheless, you have to deliberately choose to look at the sign (with e.g. C99’s copysign) to see the difference.
alerighi 4y ago
In case of floating points, since they are an approximation, zero is not zero. Zero is a quantity approaching to zero. In fact dividing by zero with floats is entirely possible! (it leads to infinite, positive or negative depending on the sign). For example, the quantity (try it in Python): 0.1 ** 100 / 1000**100 evaluates to 0.0 while the quantity 0.1 ** 100 / (-1000**100) evaluates to -0.0 It's clear that neither the two quantities are 0 (no division can produce a result that is exactly zero!) but they approach the zero. But one quantity is slightly less than zero, the other slightly more than zero. Of course for integers -0 doesn't make sense (that is the reason why we invented 2 complement, to not have 2 "zeros")
- ghayes 4y ago
  > no division can produce a result that is exactly zero Except 0 / n
  - phoe-krk 4y ago
    Or -0.0 / n, for what it's worth, at which point these zeroes will not be equal to one another.
    - recursive 4y ago
      Or 1e-100 / 1e300
      - Dylan16807 4y ago
        Please refer back to "It's clear that neither the two quantities are 0 (no division can produce a result that is exactly zero!) but they approach the zero." because you just gave an example of how that rule is correct, not an exception.
  - alerighi 4y ago
    Ok, I should have specified unless the numerator is not exactly zero!
- 4y ago
SoftTalker 4y ago
What Every Programmer Should Know About Floating-Point Arithmetic https://floating-point-gui.de/ https://floating-point-gui.de/

jbverschoor 4y ago

Unless you’re approaching the limit of 0 from one side But yeah, you’re right

andrewmcwatters 4y ago

Zero is zero, but signs are a direction. There are multiple parts to numbers. Stand in place and turn around: how far did you go from where you started? Nonetheless, I agree. It's a bad idea.

quietbritishjim 4y ago
By that logic there should be e.g. +4.0 and +4.0- (for when you go 4m forwards vs when you go 4m forwards but also turn around at the end).
- andrewmcwatters 4y ago
  In vector maths, this would just be +4.0.
  - Dylan16807 4y ago
    And the same is true of zero. Especially when you consider a two-dimensional vector. How would you encode/interpret facing in a complex zero?

mananaysiempre 4y ago

IEEE 754’s idea was that if you got a zero in a floating-point calculation (which, at the time, meant one with physical quantities), it’s probably underflow, not a legitimate result, so the FPU might as well try to give you at least a sign even if it can’t give you any significant digits. Though 754 says comparison must treat positive and negative zero as equal nevertheless, you have to deliberately choose to look at the sign (with e.g. C99’s copysign) to see the difference.

alerighi 4y ago

In case of floating points, since they are an approximation, zero is not zero. Zero is a quantity approaching to zero. In fact dividing by zero with floats is entirely possible! (it leads to infinite, positive or negative depending on the sign). For example, the quantity (try it in Python): 0.1 ** 100 / 1000**100 evaluates to 0.0 while the quantity 0.1 ** 100 / (-1000**100) evaluates to -0.0 It's clear that neither the two quantities are 0 (no division can produce a result that is exactly zero!) but they approach the zero. But one quantity is slightly less than zero, the other slightly more than zero. Of course for integers -0 doesn't make sense (that is the reason why we invented 2 complement, to not have 2 "zeros")

ghayes 4y ago
> no division can produce a result that is exactly zero Except 0 / n
- phoe-krk 4y ago
  Or -0.0 / n, for what it's worth, at which point these zeroes will not be equal to one another.
  - recursive 4y ago
    Or 1e-100 / 1e300
    - Dylan16807 4y ago
      Please refer back to "It's clear that neither the two quantities are 0 (no division can produce a result that is exactly zero!) but they approach the zero." because you just gave an example of how that rule is correct, not an exception.
- alerighi 4y ago
  Ok, I should have specified unless the numerator is not exactly zero!
4y ago

SoftTalker 4y ago

What Every Programmer Should Know About Floating-Point Arithmetic https://floating-point-gui.de/ https://floating-point-gui.de/