Remove NaR

[9e3779b9]

Almost any calculation involves more than one operation, which means that the rounding problem will turn the entire chain of calculations into meaningless NaRs and thus give the programmer a headache, because the system simulation will no longer be in a measurable state, and its data will be corrupted by NaRs.

I propose a different behavior of indeterminate forms:

1. If the argument `x` of some function does not allow the range `(-oo; a)` and is in this range, then `x` is equal to `a`
2. If the argument `x` of some function does not allow the range `(b; +oo)` and is in this range, then `x` is equal to `b`
3. If the argument `x` of some function does not allow the range `(c; d)` and is in this range, then `x` is equal to `c` if `x < (c + d) / 2` otherwise `d`

As a result, calculations are not able to create NaR. NaR becomes sort of null. If at least 1 argument of some function is null, then the result is null.

Also division by zero will equal the maximum value. And this is good, since how exactly was this zero obtained? Thanks to a chain of rounded calculations that yielded something near zero. And it does not matter which particular number from this near zero came to the division operation, it is important that the set of such numbers is within certain expectations. Getting into a small range of indeterminate forms is an error of rounded calculations. Getting into a large range of indeterminate forms the programmer will not allow. NaR is not needed.

[John Gustafson]

It is not the function of a number system to protect the programmer from programming errors. The first line of defense against all the situations described in your message is to finish debugging the program and get it right… if the programmer wants to handle exceptions as you describe, then they need to put those conditional statements in the code.

If the programmer has difficulty doing that, then the language standards like POSIX will announce errors and label what caused them. It should never fall to the arithmetic hardware, which would be a waste of logic gates.

NaR propagates perfectly if the Posit Standard (2022) is followed. This is not true for IEEE floats, which have several ways a NaR can turn into a normal float and not appear in the output. This is of the utmost importance, since posits do not use processor flags… not that processor flags in IEEE 754 were ever supported by languages. I see little need to distinguish between –∞, ∞, and NaR at the hardware level. The output simply needs to communicate "ERROR" to the programmer, who must then take steps that a program compute real-valued output. (I don't think we need computers to compute the value of –∞ or ∞).

John

--
You received this message because you are subscribed to the Google Groups "Unum Computing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unum-computin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/unum-computing/515266da-456f-45c7-96ea-86bb507741edn%40googlegroups.com.