4 ms·

Division by zero is an error and it should be treated as such. "Infinity" is an error indication from overflow and division by zero, nothing more.

ForceBru 1y ago
The article's point 3 says that this is a myth. Indeed, the _limit_ of `1/x` as `x` approaches zero from the right is positive infinity. What's more, division by _negative zero_ (which, perhaps surprisingly, is a thing) yields negative infinity, which is also the value of the corresponding limit. If you divide a finite float by infinity, you get zero, because `lim_{x\to\infty} c/x=0`. In many cases you can treat division by zero or infinity as the appropriate limit.
- pklausler 1y ago
  I am allowed to disagree with the article.
  - ForceBru 1y ago
    Sure, but it makes sense, doesn't it? Even `inf-inf == NaN` and `inf/inf == NaN`, which is true in calculus: limits like these are undefined, unless you use l'Hôpital's rule or something. (I know NaN isn't equal to itself, it's just for illustration purposes) But then again, you usually don't want these popping up in your code.
    - pklausler 1y ago
      In practice, though, I can't recall any HPC codes that want to use IEEE-754 infinities as valid data.
      - afiori 1y ago
        A significant chunk of floating point bitspace is dedicated to NaNs to represent explicitly invalid data (mostly I suppose to reduce the need for branches and tests in HPC) and NaNs even break the reflexivity of equality in many languages compared to them negative 0 and positive/negative infinity are perfectly valid
  - deleted 1y ago
    [deleted]
sfpotter 1y ago
This is totally false mathematically. Please look up the extended real number system for an example. Many branches of mathematics affix infinity to some existing number system, extending its operations consistently, and do all kinds of useful things with this setup. Being able to work with infinity in exactly the same way in IEEE754 is crucial for being able to cleanly map algorithms from these domains onto a computer. If dividing by zero were an error in floating point arithmetic, I would be unable to do my job developing numerical methods.

ForceBru 1y ago

The article's point 3 says that this is a myth. Indeed, the _limit_ of `1/x` as `x` approaches zero from the right is positive infinity. What's more, division by _negative zero_ (which, perhaps surprisingly, is a thing) yields negative infinity, which is also the value of the corresponding limit. If you divide a finite float by infinity, you get zero, because `lim_{x\to\infty} c/x=0`. In many cases you can treat division by zero or infinity as the appropriate limit.

pklausler 1y ago
I am allowed to disagree with the article.
- ForceBru 1y ago
  Sure, but it makes sense, doesn't it? Even `inf-inf == NaN` and `inf/inf == NaN`, which is true in calculus: limits like these are undefined, unless you use l'Hôpital's rule or something. (I know NaN isn't equal to itself, it's just for illustration purposes) But then again, you usually don't want these popping up in your code.
  - pklausler 1y ago
    In practice, though, I can't recall any HPC codes that want to use IEEE-754 infinities as valid data.
    - afiori 1y ago
      A significant chunk of floating point bitspace is dedicated to NaNs to represent explicitly invalid data (mostly I suppose to reduce the need for branches and tests in HPC) and NaNs even break the reflexivity of equality in many languages compared to them negative 0 and positive/negative infinity are perfectly valid
- deleted 1y ago
  [deleted]

sfpotter 1y ago

This is totally false mathematically. Please look up the extended real number system for an example. Many branches of mathematics affix infinity to some existing number system, extending its operations consistently, and do all kinds of useful things with this setup. Being able to work with infinity in exactly the same way in IEEE754 is crucial for being able to cleanly map algorithms from these domains onto a computer. If dividing by zero were an error in floating point arithmetic, I would be unable to do my job developing numerical methods.