3 ms·

I'm not convinced by this argument, and would favour x/0 to return 'undefined' rather than an infinity.

hvdijk 5y ago
You wrote: > Additionally, being able to represent positive and negative infinity is convenient and makes closing the operations easier without having to resort too much to the catch-all nan/undefined value. Which operations were you thinking about if not x/0?
- nightcracker 5y ago
  Mainly for detecting overflow in an exception-free manner. Perhaps for consistency there should also be two infinitesimal constants for detecting underflow: 1001 -> -111 -> -inf 1010 -> -110 -> -4 1011 -> -101 -> -2 1100 -> -100 -> -1 1101 -> -011 -> -1/2 1110 -> -010 -> -1/4 1111 -> -001 -> -1/inf 1000 -> -000 -> undefined 0000 -> +000 -> 0 0001 -> +001 -> 1/inf 0010 -> +010 -> 1/4 0011 -> +011 -> 1/2 0100 -> +100 -> 1 0101 -> +101 -> 2 0110 -> +110 -> 4 0111 -> +111 -> inf Then 1/0 would still remain undefined but 1/(1/inf) would be inf. In particular the operations would be (in case of ambiguity first rule applies, s is a sign variable, x, y are arbitrary variables, i, j are infinity or infinitesimal variables): undef + x = undef undef * x = undef undef / x = undef x / undef = undef x / 0 = undef inf + -inf = undef 1/inf + -1/inf = undef s*inf + x = s*inf s*1/inf + x = x i*i = i i*j = undef i*x = i i/j = undef i/x = i x/(s*inf) = s*1/inf x/(s*1/inf) = s*inf Then finally the infinities would get introduced by overflow, and infinitesimals by underflow.
  - hvdijk 5y ago
    Ah, right, thanks for the reminder, it always trips me up that overflow can round to infinity even in the mode that is called "round to nearest".
    - nightcracker 5y ago
      Maybe `inf` and `1/inf` are bad names for the concept the value represents. Perhaps 'overflow' and 'underflow' are better - they are error conditions that propagate (when they would affect the result, e.g. `x + underflow` would have been `x` anyway, thus it is not propagated), so you can diagnose when your computation has suffered from irrecoverable precision loss.

You wrote: > Additionally, being able to represent positive and negative infinity is convenient and makes closing the operations easier without having to resort too much to the catch-all nan/undefined value. Which operations were you thinking about if not x/0?

nightcracker 5y ago
Mainly for detecting overflow in an exception-free manner. Perhaps for consistency there should also be two infinitesimal constants for detecting underflow: 1001 -> -111 -> -inf 1010 -> -110 -> -4 1011 -> -101 -> -2 1100 -> -100 -> -1 1101 -> -011 -> -1/2 1110 -> -010 -> -1/4 1111 -> -001 -> -1/inf 1000 -> -000 -> undefined 0000 -> +000 -> 0 0001 -> +001 -> 1/inf 0010 -> +010 -> 1/4 0011 -> +011 -> 1/2 0100 -> +100 -> 1 0101 -> +101 -> 2 0110 -> +110 -> 4 0111 -> +111 -> inf Then 1/0 would still remain undefined but 1/(1/inf) would be inf. In particular the operations would be (in case of ambiguity first rule applies, s is a sign variable, x, y are arbitrary variables, i, j are infinity or infinitesimal variables): undef + x = undef undef * x = undef undef / x = undef x / undef = undef x / 0 = undef inf + -inf = undef 1/inf + -1/inf = undef s*inf + x = s*inf s*1/inf + x = x i*i = i i*j = undef i*x = i i/j = undef i/x = i x/(s*inf) = s*1/inf x/(s*1/inf) = s*inf Then finally the infinities would get introduced by overflow, and infinitesimals by underflow.
- hvdijk 5y ago
  Ah, right, thanks for the reminder, it always trips me up that overflow can round to infinity even in the mode that is called "round to nearest".
  - nightcracker 5y ago
    Maybe `inf` and `1/inf` are bad names for the concept the value represents. Perhaps 'overflow' and 'underflow' are better - they are error conditions that propagate (when they would affect the result, e.g. `x + underflow` would have been `x` anyway, thus it is not propagated), so you can diagnose when your computation has suffered from irrecoverable precision loss.