Implement IEEE P754 Divide By Zero Rules & $*DBZ-Suppress Option

[librasteve]

IEEE754_2008 states

7.3 Division by zero 7.3.0
The divideByZero exception shall be signaled if and only if an exact infinite result is defined for an
operation on finite operands. The default result of divideByZero shall be an ∞ correctly signed according to
the operation:
― For division, when the divisor is zero and the dividend is a finite non-zero number, the sign of the
infinity is the exclusive OR of the operands’ signs (see 6.3).

Current Behaviour

my $res;
try {
    $res = 42e0/0e0
}
say $!;                    #Attempt to divide 42 by zero using /
say $!.^name;        #X::Numeric::DivideByZero
say $res;                #(Any)

Proposed Behaviour (Num, Int and Rat)

Default behaviour is unchanged.

For the operations that can trigger a DBZ ( /, %)....

$*DBZ-Suppress = True;
say  42e0/0e0;  #Inf
say -1e0/0e0; #-Inf
say  1e0/-0e0;  #-Inf
say -1e0/-0e0;  #Inf
say 0e0/0e0;  #NaN   \   regardless of dividend or divisor sign
say Inf/Inf;      #NaN    /

---

Furthermore, this model is adopted by Rat (and FatRat);

$*DBZ-Suppress = True;
#Rat & FatRat
say  <42/0>;        #Inf
say <-1/0>;          #-Inf
say  <1/-0> ;        #-Inf
say <-1/-0>;        #Inf
say <0/0>;           #NaN   \   regardless of dividend or divisor sign
say <Inf/Inf>;      #NaN    /

Notes:

1. Regardless of dividend magnitude
2. <42/0>.nude already correctly gives (1,0) retain this
3. In the case of Rat & FatRat, the DBZ is only thrown when the value is used (eg. stringified for output)
4. In the case of Int eg 1/0 makes a Rat

There is also some valuable insight in this other problem-solving issue.

There has been a previous proposal to do this by Zoffix (includes a pointer to Larry Wall @TimToady comment)
old-design-docs

[raiph]

To save time for other readers, here's Zoffix's proposal to Larry, and Larry's response:

IOninja: TimToady: what's your take on 1e0/0e0 exploding (for natives we even get a "can't unbox failure" exception). With Rat.Num we follow IEEE semantics, yet with two Nums we explode; feels weird. Should we make Num/* and */Num follow IEEE and return NaN for 0/0 and +/-Inf for rest of */0?

TimToady I think following IEEE is good for checkoff boxes if it doesn't impact performance too badly

IOninja: Will give it a go and see how it works out.

IOninja: it prolly be better for performance in some cases, since we can get rid of our check for zero denominator

TimToady this is also a case where we really don't want to blow up the rocket's vector division just because a sensor or two were offline

[raiph]

@librasteve

There has been a previous proposal to do this by Zoffix

Some questions based on my current understanding of things:

1. Zoffix's rationale for the change was that (they claimed) the (then) current non-float behavior was already IEEE but the (then) current float behavior was not IEEE, and this inconsistency "feels weird". If your rationale is different in any way, what would you describe it as?

2. The introduction of $*RAT-OVERFLOW makes the already striking deliberate decision by Larry to have very different DBZ behavior for rationals all the more important (because now you can ensure that if you want a division to take advantage of rational DBZ behavior instead of non-rational DBZ behavior you can). Do you have anything to say about how that impacts your proposal?

3. Zoffix's proposal was to only change what happens when one of the operands was a float (Num or num). Is your proposal different from this? Zoffix proposed to change the default behavior in the float DBZ scenario, whereas you're proposing that changes only happen if the $*DBZ... variable says so. Is that right?

4. Presumably Zoffix later changed their mind about this proposal (presuming the current Rakudo does not do what Zoffix proposed). If they did later change anything about DBZ behavior, what was their rationale for the change and its difference from their original proposal?

[librasteve]

@raiph - I have no insight into Zoffix prior proposal, what became of it or the state of these features back then. That said.

1. Current Num is not IEEE (always throws DBZ, should return Inf). Current Rat is kinda IEEE (until you stringify it - and does not handle sign of Inf). Current Int always throws DBZ.
2. The introduction of $*RAT-OVERFLOW makes it more important that there is a consistent approach for Num, Rat, FatRat.
3. I have not set out mixed type ops - my starter is that infectiousness will prevail first and then this proposal will apply.
4. Dunno.

There is probably a case for (i) making the non-Int behaviour as proposed here be the default (with revision gate) and (ii) having the option for Int to conform to the IEEE mode, but keep default as DBZ (current behaviour). IEEE says nothing about Int afaik. Maybe call it $*INT-DBZ-SUPPRESS

[raiph]

@librasteve

Given that rationals deliberately have such a huge difference in DBZ behavior, perhaps having two variables would help, say $*RAT-DBZ and $*NUM-DBZ. In analogy with $*RAT-OVERFLOW they could be assigned values that direct behavior.

Perhaps:

• $*NUM-DBZ = Exception means the current behavior for a float DBZ.

• $*NUM-DBZ = IEEE means your $DBZ-Suppress = True option for a float DBZ.

• $*NUM-DBZ = Failure means returning a wrapped X::Numeric::DivideByZero::IEEE, a subclass of the existing DBZ exception with an additional IEEE attribute that stores the IEEE default DBZ value, i.e. the value that your $DBZ-Suppress = True option would make the return value instead of a failure. Failure handling code could then extract the IEEE value and/or do as it sees fit.

• $*RAT-DBZ = ZDR (ZDR = Zeron Denominator Rational, the term Zoffix coined) means the current behavior for a rational DBZ.

• $*RAT-DBZ = Num means a rational DBZ is handled as if it were a Num DBZ.

[librasteve]

@raiph, no I don't like having so many options - we the language designers ought to help shape a consistent coding space

[raiph]

@librasteve

Current Num is not IEEE (always throws DBZ, should return Inf).

Right, it's a mystery why Raku(do) hasn't yet taken the natural path of returning the default value that IEEE specifies for a float DBZ exception, especially given that Raku(do) have long supported the needed values (Inf, -Inf, and NaN).

I'd definitely love to know why Zoffix didn't land that change.

Current Rat does not handle sign of Inf

I thought it already handled it for all Inf scenarios but one DIHWIDT case -- writing -0 as a denominator?

(Other than that, afaik, rationals always store their denominators as an unsigned int and their numerators as a signed int; on evaluating a rational with a negative denominator, the sign is removed, and the numerator's sign is reversed.)

Current Int always throws DBZ.

What do you mean by Int in the context of DBZ?

Are you calling something like 42 / 21 an Int?

say (42/0).nude doesn't throw.

(Presumably we could make gist of a rational check if it's a ZDR, and, if so, gist it, via .nude or somesuch.)

IEEE says nothing about Int afaik.

I presume IEEE says nothing about rationals either. It's about floats, not rationals or ints.

But more basically, what do you mean by Int in the context of DBZ?

[librasteve]

I thought it already handled it for all Inf scenarios but one DIHWIDT case -- writing -0 as a denominator?

My case is that this is not DIHWIDT see #516 and the benefit of having Rat and Num follow the same pattern.

say (42/0).nude doesn't throw.

I stand corrected - thanks ;-)

But more basically, what do you mean by Int in the context of DBZ?

Ah - so I guess that 1/0 makes a Rat, and so the DBZ is on stringification. So no such thing as DBZ for Int.

[EDIT OP]

[raiph]

@librasteve

My case is that this is not DIHWIDT

As a general point, nothing is black and white.

When I use the term DIHWIDT I mean to distill something like an official position for a WONTFIX situation where it's arguably reasonable both to fix or not fix something.

Consider, for example, someone saying or thinking "It hurt when I passed my hand through a stream of red hot molten metal". A doctor might reply "Don't do that." But some people would point to this (a fun 10 second short), argue that "don't do that" is the wrong response, given that the video is genuine -- the Leidenfrost Effect is indeed a 100% reliable physical phenomenon -- and they'd be entirely right. Nevertheless, sometimes an official position of something being a DIHWIDT can still be reasonable.

If we can figure out a slick and simple solution to the technical language sub-problem of having a literal -0 mean negative zero, and then solve the other related problems, I will be at least neutral about it all, and indeed can imagine myself being delighted at the prospect of Raku introducing support for the metaphoric equivalent of passing one's hand through a stream of molten metal. If nothing else, it'd be cute! (But then again, the 42.WHY easter egg was eventually removed. I was sad about that but understood why some felt it had to go.)

Ah - so I guess that 1/0 makes a Rat, and so the DBZ is on stringification.

Yes.

FWIW I'm currently thinking that ZDR's could and maybe should have much less explosivity by default. What about the general principle that ZDR's turn into Inf or -Inf rather than throwing exceptions? That would mean they work in various scenarios, including stringification and the example you mentioned in another issue (mixed type operations like <-1/0> - 1e0/0).

I still think there may be merit to having separate dynamics for controlling behavior of Int, Num, Rat, and Complex numbers in various exceptional circumstances, with the idea of being able to modify behavior, within a dynamic scope, of one or more types of numbers, including things like converting from one type into another, throwing exceptions, returning failures, and so on.

That said, I can hear aintie YAGNI's droll joke in one ear and jnthn hating on $*RAT-OVERFLOW in the other...