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
