This isn't just J - this is the IEEE-754 floating point standard. It would be really nice if computers could deal with infinities, instantly, at no cost. Sadly, though, that's not going to happen.
FYI, -- Raul On Wed, Sep 20, 2017 at 5:21 AM, Erling Hellenäs <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
