[Jprogramming] Overflow, underflow, floats

[Erling Hellenäs]

Hi all !

"A NaN may carry a payload that is intended for diagnostic information 
indicating the source of the NaN"

https://en.wikipedia.org/wiki/IEEE_754#Alternate_exception_handling

Maybe this is a way to represent missing data?

Cheers,

Erling


Den 2017-09-20 kl. 11:21, skrev Erling Hellenäs:
> Hi all!
>
> This is how J handles overflow and underflow. This is exacly how the 
> platform handles it. JWithATwist gives exactly the same results. As we 
> can see overflow results in infinity, underflow results in a zero result.
>
>    0.1234567891234567e_15 * 0.1234567891234567e_307
> 0
>    0.1234567891234567e_14 * 0.1234567891234567e_307
> 1.4822e_323
>    0.123456789 * 0.123456789
> 0.0152416
>    0.1234567891234567e3 * 0.1234567891234567e307
> 1.52416e308
>    0.1234567891234567e4 * 0.1234567891234567e307
> _
>
> We can see that overflow and underflow are treated differently.
>
> Before we get a zero result in the underflow case the fraction bits 
> are moved to the right and we lose precision.
>
> As we can understand this is a problematic behavior. Zero is no fault 
> indication. It is a number with zero precision. If we multiply it with 
> some big number and then add or subtract something we get a non-zero, 
> but totally random result. Lost precision is also a problem. In 
> engineering we rely on the precision of the result.
>
> It would be preferable to get a NaN or optionally an underflow error 
> in this case? Instead of even losing precision?
>
> The overflow case seems less of a problem. As far as I understand 
> further calculation with the infinity value will never result in a 
> seemingly legitimate value. The positive infinity, negative infinity 
> or NaN that will be the result of the calculations can be used as 
> fault indications.
>
> As I see it we would like to optionally get an overflow error in this 
> case.
>
> A big number is not infinity, and as I see it we would prefer a NaN 
> result to an infinity result. We can get infinity when we should, for 
> example when we divide by exactly 0?
>
> We would like the positive and negative infinity to have their 
> mathematical meaning?
>
> We have signed zero. +0 has a different representation from -0. That's 
> peculiar. However in comparisons they happily are considered equal.
>
> I can't find any way to make these different representations cause any 
> trouble.
>
> However, in J 0 % 0 is now considered to be 0. The mathematically 
> correct result in undefined. Windows gives NaN.
>
> J:
>
>    3!:0 (0 + 0.5 - 0.5)
> 8
>    (0 + 0.5 - 0.5) % (0 + 0.5 - 0.5)
> 0
>
> JWithATwist, Windows default:
>
>
> { ( 0 + 0.5 - 0.5 ) % ( 0 + 0.5 - 0.5 ) }
>  NaN
>
>
> I think this should be changed. We should get NaN. Optionally we 
> should get a NaN error.
>
>
> Infinity divided with negative zero gives positive infinity as default 
> on the Windows platform and in J. This seems reasonable as there is no 
> means to have the +0 and -0 represent function results approaching but 
> not reaching zero from both sides anyway. Otherwise, this might have 
> been meaningful functionality. This would require THREE different zero 
> representations!
>
>
> It would probably be good to be able to represent missing data. R is 
> an example of a language which represents missing data.
>
>
> We can still lose precision by addition and subtraction of large 
> positive or negative numbers.
>
>
> I did not investigate how much of my proposed modifications the 
> standards would allow.
>
>
> Cheers,
>
> Erling
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm