<p>Sometimes, we want to implement floating-point operations on systems which use <a href="https://en.wikipedia.org/wiki/IEEE_754" rel="nofollow noreferrer">IEEE 754</a> representations of values, but don't necessarily support IEEE 754 semantics. For example, we may be using the <code>-ffast-math</code> compiler flag, or working with GPUs, DSPs, or other coprocessors. Additionally, suppose we lack <a href="https://en.wikipedia.org/wiki/NaN" rel="nofollow noreferrer">NaNs</a> or otherwise choose not to represent them.</p>
<p>Even with <a href="https://en.wikipedia.org/wiki/Subnormal_number" rel="nofollow noreferrer">denorms</a>, zero is somewhat fuzzy, in the sense that (positive) zero represents both itself and also extremely small (positive) numbers. Similarly, infinity is somewhat fuzzy, in the sense that all overflowing computations round up to infinity.</p>
<p>This suggests a fun answer to the question of division by zero. Define division of X and Y as multiplication of X and Y's multiplicative inverse, and define zero and infinity as multiplicative inverses. Then, division by zero is multiplication by infinity.</p>
<p>Immediately, 0 / 0 = 0 × ∞ = 1, which might not be desirable; what else breaks or is counterintuitive?</p>

<error-handling><floating-point>
What goes wrong when division-by-zero is defined as multiplication-by-infinity?
CC BY-SA 4.0
2023-12-02T13:56:19.437Z
Feel free to close as duplicate, although I couldn't find this question asked elsewhere. I've been able to implement 2D and 3D raytracing with this setup, so I'm not really concerned that it makes numerical methods impossible; but maybe it complicates some common numerical assumptions.
Corbin
CC BY-SA 4.0
2023-12-02T15:09:39.260Z
What does $1^\infty$ become, then? That's `NaN` in JavaScript. Or to answer more broadly about lacking NaN in general, what does $\ln -1$ or $\sqrt{-1}$ become?
Bbrk24
CC BY-SA 4.0
2023-12-02T20:33:20.203Z
@Bbrk24: Well, there's many possibilities. It could raise an exception. `sqrt` could be defined to return a `Maybe`, an `Error`, or an `Either`. It could return *i*. It could return the pair *(+i, -i)*.
Jörg W Mittag
CC BY-SA 4.0
2023-12-02T23:38:34.457Z
This is really a mathematics question. What goes wrong is that certain mathematical properties (e.g. distributivity of multiplication over addition) cease to hold. I don't think programming language design expertise is relevant to answering.
kaya3
CC BY-SA 4.0
2023-12-03T00:18:59.450Z
I don't understand how you conclude that "0 × ∞ = 1".
Lazar Ljubenović
CC BY-SA 4.0
2023-12-03T03:42:36.090Z
As it stands, this question is more mathematically worded than programming language design worded. However, I believe that there is a legitimate PL question here about the implications of a non-standard language design choice, and what benefits it could bring. Answers could draw from existing languages with non-erroring division by 0 behaviour to demonstrate the impacts such a design decision could have. Therefore I believe this question is on-topic for this site, with the potential for edits to emphasise the language design part.
lyxal
CC BY-SA 4.0
2023-12-03T17:26:43.697Z
@Bbrk24: If anybody (including you!) asks me for it, I'm happy to ask and answer the related question, "What goes wrong when a floating-point library omits NaNs?" In one of my languages, [Cammy](https://esolangs.org/wiki/Cammy), I make NaN completely inaccessible, and this indeed comes with several tradeoffs which I'm happy to document.
Corbin
CC BY-SA 4.0
2023-12-03T17:29:03.747Z
@LazarLjubenović: Multiplicative inverses should always multiply to approximately 1. For example, 0.5 × 2 = 1 in typical floating-point implementations.
Corbin
CC BY-SA 4.0
2023-12-03T18:35:55.130Z
But ∞ is not a number and it's not a multiplicative inverse of 0. I mean, you _can_ define it like that in your own nomenclature, but then you have to deal with consequences of other common terms not making sense anymore. It's impossible to redefine just one mathematical concept and expect that everything else will just work out on its own.
Lazar Ljubenović
CC BY-SA 4.0
2023-12-03T20:32:02.160Z
Oh, I see! @LazarLjubenović, I've added an introductory paragraph. This question is specifically about implementing FP for languages, not about new systems of maths. IEEE 754 includes two infinities among its numbers. I agree that we can't arbitrarily redefine the real numbers, but we certainly can design FP systems, and we can also patch IEEE 754's partial operations to cover wider ranges of inputs. Thanks for your feedback!
Corbin
CC BY-SA 4.0
2023-12-04T08:02:49.900Z
@Corbin The question title seems to differ from the question body. When does replacing division by zero with multiplication by infinity in an IEEE-754 compatible environment return a different result (not exception flags)? It seems to me there is no such case, and this transformation is valid under "as-if" semantics. The question body however asks what would happen if NaN support is removed (so no longer IEEE-754 compatible), which is a different issue.
njuffa
CC BY-SA 4.0
2023-12-04T08:10:21.430Z
@njuffa: Yeah, I think I agree with your logic. Give me a few minutes; I need to non-awkwardly express that I'm considering a system with IEEE 754 storage but not adhering to IEEE 754 semantics. Think of a compiler with `-ffast-math` or a GPU/DSP environment. I'll expand the first paragraph.
Corbin
CC BY-SA 4.0
2023-12-04T08:15:10.960Z
@Corbin I am very familiar with the GPU environment (NVIDIA GPUs) as I was part of the team that created CUDA. The floating-point arithmetic is not IEEE-754 compliant (no exception flags, no dynamic rounding mode), but is IEEE-754 compatible; in other words, those mechanisms of IEEE-754 that are supported do work as specified by IEEE-754.
njuffa
CC BY-SA 4.0
2023-12-05T03:31:06.147Z
cuda is not 'the' GPU environment, and it's probably the cushiest out of all of them :).  (That said, supporting nans is probably not a lot of gates, and probably doesn't make much sense to leave out?  Is there any notable hardware that elides them?  I think the software is, as per usual, probably the main thing to worry about.)
Moonchild
CC BY-SA 4.0
2023-12-07T15:37:26.030Z
I feel that this question is off topic and better suited for Software Engineering SE.
FireTheLost
CC BY-SA 4.0
2023-12-08T01:17:53.590Z
@FireTheLost: This question is about the design and implementation of programming languages. I am currently re-examining choices I made in the design of [Monte](https://github.com/monte-language/monte/) and [Cammy](https://esolangs.org/wiki/Cammy); in both, 0 and ∞ are reciprocals, and in Cammy, division is  currently implemented as multiplication.
Corbin
CC BY-SA 4.0
2023-12-08T12:40:33.997Z
@Corbin The edit clears this up for me :)
FireTheLost
<p>The main problem with <em>implementing</em> division as multiplication by the reciprocal is loss of accuaracy due to double rounding -- if both the reciprocal and mulitply give the closest answer that can be represented, the result of both may result in something that is off by 1ulp.  This can be avoided by using a special representation for the intermediate value (the reciprocal result) with an extra bit of precision, or by using a dedicated division.  Both are about as expensive, hardware-wise.</p>
<p>This is completely orthogonal to the question of infinity.  If your number system implementation can represent infinity, then it probably makes sense to support some kind of NaN as well, and then it makes sense to define 0/0 == 0 × ∞ == NaN.  If your number system does not support either, then division by 0 is just a problem needing some sort of error indication outside of the number system.  Supporting ∞ and not NaN would still need some sort of error result for both 0/0 and 0 × ∞</p>

CC BY-SA 4.0
2023-12-04T01:02:48.727Z
2023-12-04T01:09:46.710Z
2023-12-04T01:09:46.710Z
Chris Dodd
CC BY-SA 4.0
2023-12-04T08:04:56.573Z
I'm not downvoting this, although I don't feel like it's on the path to being accepted either. My main thought is that, well, I *have implemented* this as part of three raytracers in two languages, both having dedicated FP reciprocal operations and one language avoiding NaNs entirely. Replacing division by multiplication is a standard numerical-methods tactic, although it has the downsides you've correctly mentioned.
Corbin
CC BY-SA 4.0
2023-12-04T18:12:39.420Z
*" Supporting ∞ and not NaN would still need some sort of error result for both 0/0 and 0 × ∞"* ─ the question asks why they can't just be defined as 1. Why is an error result needed instead?
kaya3
CC BY-SA 4.0
2023-12-04T19:36:26.000Z
@kaya: While you could do that, it is akin to defining 2 + 2 = 5 -- pretty much nonsense.  "What would go wrong" is any calculation involving 0/0 or 0 × ∞
Chris Dodd
CC BY-SA 4.0
2023-12-04T19:52:46.057Z
Of course I agree, but "if you do that then people on Langdev SE will call it nonsense" isn't a very satisfactory answer to "what goes wrong".
kaya3
<p>One thing that breaks is compatibility between floating-point arithmetic and integer arithmetic.</p>
<p>Most languages have a <code>float</code> and an <code>int</code> type, and the <code>float</code> type has <code>nan</code> and <code>inf</code> and <code>-inf</code> values, but the <code>int</code> type doesn't. Does this mean that all three of <code>1.0 / 0.0</code>, <code>1 / 0.0</code> and <code>1.0 / 0</code> would return <code>inf</code>, but <code>1 / 0</code> would raise a &quot;division by zero&quot; error because <code>int</code> has no infinity?</p>
<p>Moreover, extending a system of arithmetic to define the result of <code>1 / 0</code> to be <code>∞</code> makes sense in a small number of contexts, but doesn't make sense in most contexts; it's probably better to warn the programmer of a potential error by raising a &quot;division by zero&quot; error in all contexts, and let the programmer handle the special case <code>if (divisor == 0) { something that makes sense in this particular context }</code>.</p>
<p>For instance, the mean of a list is <code>sum(list) / length(list)</code>. With your fix, programs that compute the mean of a list would unhelpfully return an infinite mean in the case of empty lists, instead of warning the programmer that they forgot to handle a special case.</p>

CC BY-SA 4.0
2023-12-08T19:08:57.157Z
2023-12-08T19:08:57.157Z
Stef
<p>You assume that there is no NaN. Without NaN there is no reasonable result for 0.0 / 0.0 whatsoever. There is also no reasonable result for 0 x infinity.</p>

CC BY-SA 4.0
2023-12-03T18:23:47.843Z
2023-12-03T18:23:47.843Z
gnasher729
CC BY-SA 4.0
2023-12-03T20:48:54.387Z
The question proposes that the result would be 1, and asks what goes wrong. It may very well be that 1 is not a "reasonable" result, but simply saying so doesn't answer the question.
kaya3
<blockquote>
<p>What goes wrong when division-by-zero is defined as multiplication-by-infinity?</p>
</blockquote>
<p>Nothing. Division by zero already always has the exact same result as multiplication by infinity. For any non-zero <code>a</code>, you have <code>a / 0 = ∞</code> already, so redefining it as <code>a * ∞</code> doesn't change the result because that's already <code>∞</code>. For zero, <code>0 / 0</code> is normally <code>NaN</code>, and applying your definition again doesn't change anything because <code>0 * ∞</code> is also <code>NaN</code> already.</p>
<p>The problems start when you (A) remove <code>NaN</code> from the equation, and with the attempt to solve it by defining two additional things: (B) division of X and Y as multiplication of X and Y's multiplicative inverse, and (C) define zero and infinity as multiplicative inverses.</p>
<blockquote>
<p>What else breaks or is counterintuitive?</p>
</blockquote>
<p>Furthermore, <code>∞ - ∞</code> would normally return <code>NaN</code>, but that value's banned, so we need to come up with a solution for that as well. Following your line of thought, we define (D) the difference of X and Y as a sum of X and Y's additive inverse, and (E) define positive and negative infinity as additive inverses. Then, subtracting a positive infinity is adding a negative infinity. Immediately, <code>∞ - ∞ = ∞ + (-∞) = 0</code>. Just like <code>0 × ∞ = 1</code>, this is undesirable.</p>
<p>The problem with doing things like this is that now you also have to accept things like <code>0 = 0 * 1 = 0 * (0 / 0) = (0 * 0) / 0 = 0 / 0 = 1</code>, breaking associative and distributive laws. Granted, these laws don't fully hold in IEEE-754 due to rounding errors, but the margin of error is never <code>1</code>.</p>
<p>You could say you're fine with margin of error being 1. After all, what's a single 1 compared to the infinite ∞? Well, actually... <code>∞ = ∞ * 1 = ∞ * (∞ / ∞) = (∞ * ∞) / ∞ = ∞ / ∞ = 1</code>.</p>
<p>So we end up with <code>0 = 1 = ∞</code> all being the same -- these are the exact things we've tried to mess with by tweaking definitions.</p>
<p>Interestingly, they actually <em>ALL</em> mean <code>NaN</code> now, i.e. a value whose value we cannot rely on to conclude anything meaningful -- if the result of an operation is either of these three, we must discard it as it has possibly gone through some of the nonsensical transformations like above. Our attempt to remedy removal of <code>NaN</code> has led us to losing three pretty important values that would otherwise be useful and sensible.</p>
<p>In a sense, both <code>∞</code> and <code>NaN</code> are kind of &quot;not a number&quot;s, but we can attach a meaningful distinction between different kind of &quot;not a number&quot;s, hence we normally <em>want</em> both <code>∞</code> and <code>NaN</code>.</p>
<hr />
<p>Let's tweak your starting reasoning a bit: instead of immediately focusing on the concepts of &quot;infinity&quot; and &quot;zero&quot;, let's take a step back: why does infinity even exist? One of the most obvious reasons is because we've introduced division -- you need a way to represent <code>a / 0</code>. So one way to simplify IEEE-754 is to disallow division completely. Now you have no <code>NaN</code> and no <code>∞</code>. Yay!</p>
<p>If you still want division, you must somehow handle <code>a / 0</code> (assuming you want a zero as a valid value). One way is to define that as (mostly) <code>∞</code>, but you can just cut your losses here and declare <em>that</em> a <code>NaN</code> instead. Division by zero, including <code>0 / 0</code> is simply <code>NaN</code> in this case. You still have to define how comparing with <code>NaN</code> works, etc. But hey, no <code>∞</code>.</p>
<p>...Except even that is a great simplification. Now the compiler needs to reject the <code>99e9999</code> literal, because that would normally be represented as <code>∞</code>. The runtime would also need to do something when you try to multiply the largest representable number by two. You can argue that it can just return the largest number back, but then you're basically just avoiding using the <em>word</em> infinity, as your largest number is now actually <code>∞</code>.</p>
<hr />
<p>That said, I don't think the idea of getting rid of <code>NaN</code> is bad in a <em>programming language</em> that uses IEEE-754 under the hood. You can hide <code>NaN</code> behind a first-class exception system, or a <code>Maybe</code>/<code>Option</code> system, or re-use the <code>null</code> if you have it, or give it a special type so the author is forced to handle the <code>NaN</code> case explicitly. <code>NaN</code> exists in IEEE-754 because it must <em>somehow</em> represent every possible combination of operands and operations. A format cannot throw an exception -- but your language can. Now if <em>that</em> is a good idea is a whole other can of worms.</p>

CC BY-SA 4.0
2023-12-04T23:50:14.457Z
2023-12-07T15:16:18.360Z
2023-12-07T15:16:18.360Z
Lazar Ljubenović
CC BY-SA 4.0
2023-12-05T16:39:38.667Z
As you say, some of your intermediate derivations are unsupported by typical floating-point lack of associativity. The derivation of `∞ - ∞ = 0` is valid, though, and certainly has to be accepted as part of what goes wrong.
Corbin
CC BY-SA 4.0
2023-12-05T16:41:34.263Z
Note that, due to how overflow works already, ∞ is the margin of error for reassociating or distributing multiplication. This is part of why Kahan encourages not being "mindless" about roundoff error when optimizing a numerical expression; roundoff is not easily distinguishable from overflow.
Corbin
CC BY-SA 4.0
2023-12-07T19:46:09.703Z
This kind of reminds me of the principle in pure mathematics that assuming that 0/0=1 leads to the zero ring—which is neither desirable not useful.
Someone
# What goes wrong when division-by-zero is defined as multiplication-by-infinity?
Posted by: username_0 on 2023-12-02
Sometimes, we want to implement floating-point operations on systems which use [IEEE 754](https://en.wikipedia.org/wiki/IEEE_754) representations of values, but don't necessarily support IEEE 754 semantics. For example, we may be using the `-ffast-math` compiler flag, or working with GPUs, DSPs, or other coprocessors. Additionally, suppose we lack [NaNs](https://en.wikipedia.org/wiki/NaN) or otherwise choose not to represent them.

Even with [denorms](https://en.wikipedia.org/wiki/Subnormal_number), zero is somewhat fuzzy, in the sense that (positive) zero represents both itself and also extremely small (positive) numbers. Similarly, infinity is somewhat fuzzy, in the sense that all overflowing computations round up to infinity.

This suggests a fun answer to the question of division by zero. Define division of X and Y as multiplication of X and Y's multiplicative inverse, and define zero and infinity as multiplicative inverses. Then, division by zero is multiplication by infinity.

Immediately, 0 / 0 = 0 × ∞ = 1, which might not be desirable; what else breaks or is counterintuitive?
**Tags:** error-handling floating-point
> **Comments:**
> **username_0**: Feel free to close as duplicate, although I couldn't find this question asked elsewhere. I've been able to implement 2D and 3D raytracing with this setup, so I'm not really concerned that it makes numerical methods impossible; but maybe it complicates some common numerical assumptions.  
> **username_1**: What does $1^\infty$ become, then? That's `NaN` in JavaScript. Or to answer more broadly about lacking NaN in general, what does $\ln -1$ or $\sqrt{-1}$ become?  
> **username_2**: @Bbrk24: Well, there's many possibilities. It could raise an exception. `sqrt` could be defined to return a `Maybe`, an `Error`, or an `Either`. It could return *i*. It could return the pair *(+i, -i)*.  
> **username_3**: This is really a mathematics question. What goes wrong is that certain mathematical properties (e.g. distributivity of multiplication over addition) cease to hold. I don't think programming language design expertise is relevant to answering.  
> **username_4**: I don't understand how you conclude that "0 × ∞ = 1".  
> **username_5**: As it stands, this question is more mathematically worded than programming language design worded. However, I believe that there is a legitimate PL question here about the implications of a non-standard language design choice, and what benefits it could bring. Answers could draw from existing languages with non-erroring division by 0 behaviour to demonstrate the impacts such a design decision could have. Therefore I believe this question is on-topic for this site, with the potential for edits to emphasise the language design part.  
> **username_0**: @Bbrk24: If anybody (including you!) asks me for it, I'm happy to ask and answer the related question, "What goes wrong when a floating-point library omits NaNs?" In one of my languages, [Cammy](https://esolangs.org/wiki/Cammy), I make NaN completely inaccessible, and this indeed comes with several tradeoffs which I'm happy to document.  
> **username_0**: @LazarLjubenović: Multiplicative inverses should always multiply to approximately 1. For example, 0.5 × 2 = 1 in typical floating-point implementations.  
> **username_4**: But ∞ is not a number and it's not a multiplicative inverse of 0. I mean, you _can_ define it like that in your own nomenclature, but then you have to deal with consequences of other common terms not making sense anymore. It's impossible to redefine just one mathematical concept and expect that everything else will just work out on its own.  
> **username_0**: Oh, I see! @LazarLjubenović, I've added an introductory paragraph. This question is specifically about implementing FP for languages, not about new systems of maths. IEEE 754 includes two infinities among its numbers. I agree that we can't arbitrarily redefine the real numbers, but we certainly can design FP systems, and we can also patch IEEE 754's partial operations to cover wider ranges of inputs. Thanks for your feedback!  
> **username_6**: @Corbin The question title seems to differ from the question body. When does replacing division by zero with multiplication by infinity in an IEEE-754 compatible environment return a different result (not exception flags)? It seems to me there is no such case, and this transformation is valid under "as-if" semantics. The question body however asks what would happen if NaN support is removed (so no longer IEEE-754 compatible), which is a different issue.  
> **username_0**: @njuffa: Yeah, I think I agree with your logic. Give me a few minutes; I need to non-awkwardly express that I'm considering a system with IEEE 754 storage but not adhering to IEEE 754 semantics. Think of a compiler with `-ffast-math` or a GPU/DSP environment. I'll expand the first paragraph.  
> **username_6**: @Corbin I am very familiar with the GPU environment (NVIDIA GPUs) as I was part of the team that created CUDA. The floating-point arithmetic is not IEEE-754 compliant (no exception flags, no dynamic rounding mode), but is IEEE-754 compatible; in other words, those mechanisms of IEEE-754 that are supported do work as specified by IEEE-754.  
> **username_7**: cuda is not 'the' GPU environment, and it's probably the cushiest out of all of them :).  (That said, supporting nans is probably not a lot of gates, and probably doesn't make much sense to leave out?  Is there any notable hardware that elides them?  I think the software is, as per usual, probably the main thing to worry about.)  
> **username_8**: I feel that this question is off topic and better suited for Software Engineering SE.  
> **username_0**: @FireTheLost: This question is about the design and implementation of programming languages. I am currently re-examining choices I made in the design of [Monte](https://github.com/monte-language/monte/) and [Cammy](https://esolangs.org/wiki/Cammy); in both, 0 and ∞ are reciprocals, and in Cammy, division is  currently implemented as multiplication.  
> **username_8**: @Corbin The edit clears this up for me :)  
---
## 4 answers
### Answer by username_4 on 2023-12-04. Score: 10
> What goes wrong when division-by-zero is defined as multiplication-by-infinity?

Nothing. Division by zero already always has the exact same result as multiplication by infinity. For any non-zero `a`, you have `a / 0 = ∞` already, so redefining it as `a * ∞` doesn't change the result because that's already `∞`. For zero, `0 / 0` is normally `NaN`, and applying your definition again doesn't change anything because `0 * ∞` is also `NaN` already.

The problems start when you (A) remove `NaN` from the equation, and with the attempt to solve it by defining two additional things: (B) division of X and Y as multiplication of X and Y's multiplicative inverse, and (C) define zero and infinity as multiplicative inverses.

> What else breaks or is counterintuitive?

Furthermore, `∞ - ∞` would normally return `NaN`, but that value's banned, so we need to come up with a solution for that as well. Following your line of thought, we define (D) the difference of X and Y as a sum of X and Y's additive inverse, and (E) define positive and negative infinity as additive inverses. Then, subtracting a positive infinity is adding a negative infinity. Immediately, `∞ - ∞ = ∞ + (-∞) = 0`. Just like `0 × ∞ = 1`, this is undesirable.

The problem with doing things like this is that now you also have to accept things like `0 = 0 * 1 = 0 * (0 / 0) = (0 * 0) / 0 = 0 / 0 = 1`, breaking associative and distributive laws. Granted, these laws don't fully hold in IEEE-754 due to rounding errors, but the margin of error is never `1`.

You could say you're fine with margin of error being 1. After all, what's a single 1 compared to the infinite ∞? Well, actually... `∞ = ∞ * 1 = ∞ * (∞ / ∞) = (∞ * ∞) / ∞ = ∞ / ∞ = 1`.

So we end up with `0 = 1 = ∞` all being the same -- these are the exact things we've tried to mess with by tweaking definitions.

Interestingly, they actually *ALL* mean `NaN` now, i.e. a value whose value we cannot rely on to conclude anything meaningful -- if the result of an operation is either of these three, we must discard it as it has possibly gone through some of the nonsensical transformations like above. Our attempt to remedy removal of `NaN` has led us to losing three pretty important values that would otherwise be useful and sensible.

In a sense, both `∞` and `NaN` are kind of "not a number"s, but we can attach a meaningful distinction between different kind of "not a number"s, hence we normally *want* both `∞` and `NaN`.

---

Let's tweak your starting reasoning a bit: instead of immediately focusing on the concepts of "infinity" and "zero", let's take a step back: why does infinity even exist? One of the most obvious reasons is because we've introduced division -- you need a way to represent `a / 0`. So one way to simplify IEEE-754 is to disallow division completely. Now you have no `NaN` and no `∞`. Yay!

If you still want division, you must somehow handle `a / 0` (assuming you want a zero as a valid value). One way is to define that as (mostly) `∞`, but you can just cut your losses here and declare *that* a `NaN` instead. Division by zero, including `0 / 0` is simply `NaN` in this case. You still have to define how comparing with `NaN` works, etc. But hey, no `∞`.

...Except even that is a great simplification. Now the compiler needs to reject the `99e9999` literal, because that would normally be represented as `∞`. The runtime would also need to do something when you try to multiply the largest representable number by two. You can argue that it can just return the largest number back, but then you're basically just avoiding using the *word* infinity, as your largest number is now actually `∞`.

---

That said, I don't think the idea of getting rid of `NaN` is bad in a *programming language* that uses IEEE-754 under the hood. You can hide `NaN` behind a first-class exception system, or a `Maybe`/`Option` system, or re-use the `null` if you have it, or give it a special type so the author is forced to handle the `NaN` case explicitly. `NaN` exists in IEEE-754 because it must *somehow* represent every possible combination of operands and operations. A format cannot throw an exception -- but your language can. Now if *that* is a good idea is a whole other can of worms.
> **Comments:**
> **username_0** (2023-12-05): As you say, some of your intermediate derivations are unsupported by typical floating-point lack of associativity. The derivation of `∞ - ∞ = 0` is valid, though, and certainly has to be accepted as part of what goes wrong.  
> **username_0** (2023-12-05): Note that, due to how overflow works already, ∞ is the margin of error for reassociating or distributing multiplication. This is part of why Kahan encourages not being "mindless" about roundoff error when optimizing a numerical expression; roundoff is not easily distinguishable from overflow.  
> **username_12** (2023-12-07): This kind of reminds me of the principle in pure mathematics that assuming that 0/0=1 leads to the zero ring—which is neither desirable not useful.  
---
### Answer by username_9 on 2023-12-04. Score: 2
The main problem with *implementing* division as multiplication by the reciprocal is loss of accuaracy due to double rounding -- if both the reciprocal and mulitply give the closest answer that can be represented, the result of both may result in something that is off by 1ulp. This can be avoided by using a special representation for the intermediate value (the reciprocal result) with an extra bit of precision, or by using a dedicated division. Both are about as expensive, hardware-wise.

This is completely orthogonal to the question of infinity. If your number system implementation can represent infinity, then it probably makes sense to support some kind of NaN as well, and then it makes sense to define 0/0 == 0 × ∞ == NaN. If your number system does not support either, then division by 0 is just a problem needing some sort of error indication outside of the number system. Supporting ∞ and not NaN would still need some sort of error result for both 0/0 and 0 × ∞
> **Comments:**
> **username_0** (2023-12-04): I'm not downvoting this, although I don't feel like it's on the path to being accepted either. My main thought is that, well, I *have implemented* this as part of three raytracers in two languages, both having dedicated FP reciprocal operations and one language avoiding NaNs entirely. Replacing division by multiplication is a standard numerical-methods tactic, although it has the downsides you've correctly mentioned.  
> **username_3** (2023-12-04): *" Supporting ∞ and not NaN would still need some sort of error result for both 0/0 and 0 × ∞"* ─ the question asks why they can't just be defined as 1. Why is an error result needed instead?  
> **username_9** (2023-12-04): @kaya: While you could do that, it is akin to defining 2 + 2 = 5 -- pretty much nonsense.  "What would go wrong" is any calculation involving 0/0 or 0 × ∞  
> **username_3** (2023-12-04): Of course I agree, but "if you do that then people on Langdev SE will call it nonsense" isn't a very satisfactory answer to "what goes wrong".  
---
### Answer by username_10 on 2023-12-08. Score: 1
One thing that breaks is compatibility between floating-point arithmetic and integer arithmetic.

Most languages have a `float` and an `int` type, and the `float` type has `nan` and `inf` and `-inf` values, but the `int` type doesn't. Does this mean that all three of `1.0 / 0.0`, `1 / 0.0` and `1.0 / 0` would return `inf`, but `1 / 0` would raise a "division by zero" error because `int` has no infinity?

Moreover, extending a system of arithmetic to define the result of `1 / 0` to be `∞` makes sense in a small number of contexts, but doesn't make sense in most contexts; it's probably better to warn the programmer of a potential error by raising a "division by zero" error in all contexts, and let the programmer handle the special case `if (divisor == 0) { something that makes sense in this particular context }`.

For instance, the mean of a list is `sum(list) / length(list)`. With your fix, programs that compute the mean of a list would unhelpfully return an infinite mean in the case of empty lists, instead of warning the programmer that they forgot to handle a special case.
---
### Answer by username_11 on 2023-12-03. Score: -3
You assume that there is no NaN. Without NaN there is no reasonable result for 0.0 / 0.0 whatsoever. There is also no reasonable result for 0 x infinity.
> **Comments:**
> **username_3** (2023-12-03): The question proposes that the result would be 1, and asks what goes wrong. It may very well be that 1 is not a "reasonable" result, but simply saying so doesn't answer the question.  
---
