One can argue that more information is better than less; or one can argue that implementation detail should be kept private. I prefer the latter. Maybe it's a matter of taste.
I can't see the reason for a distinction between the following two errors: _ - _ |NaN error 1 o. _ |limit error except that the first is a _. that the hardware generates, while the second _. is detected in software. They're both domain errors because the proper result is _. . When you introduce 'NaN error', aren't you giving yourself the additional burden of having to decide which errors it most precisely describes? Just nosing around, what about this: 10 | _ 0 shouldn't this be a NaN error? _ | __ __ shouldn't this be a NaN error? At the least, shouldn't the result be positive? Henry Rich > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Roger Hui > Sent: Monday, February 25, 2008 1:04 AM > To: Beta forum > Subject: Re: [Jbeta] Use of the name 'NaN' deprecated > > > Do change 'NaN error' to either 'domain error' (preferred) > or '_. error' . > > It is advantageous to have a message for "NaN error" > distinct from "domain error", so that when you get > one of them you don't have to puzzle over what kind > of domain error it was. In a sense they are all domain > errors, but it is helpful to have "rank error", "index error", etc. > and now "NaN error". > > As for the exact spelling of the message, you can change > it to whatever you like via 9!:9 . > > > > ----- Original Message ----- > From: Henry Rich <[EMAIL PROTECTED]> > Date: Sunday, February 24, 2008 9:40 > Subject: RE: [Jbeta] Use of the name 'NaN' deprecated > To: 'Beta forum' <[email protected]> > > > I think you are replying to a different argument than the > > one I was trying to make. > > > > I wasn't suggesting that _. be 'above that' in the sense of > > following certain J-defined rules independent of the > > IEEE spec. That would be OK but if it's too hard, > > let it go. > > > > I am happy with all the implementation decisions you have made. > > I am particularly happy with raising error when _. would > > be created. > > > > My only objection is to using the name 'NaN'. Maybe you use > > a NaN for _., but I see no reason to pollute the documentation > > with that term. I AM suggesting that the language spec be > > 'above that', because NaN is a new and unnecessary concept > > within J numbers. > > > > And _. IS a number. qbeta tells me so: > > > > 9!:14'' > > j602/beta/2008-02-22/22:30 > > 3!:0 (_.) > > 8 > > > > Don't change a line of code. Do change the doc of 128!:5 > > to say > > it checks for the presence of _. rather than of NaN. Do change > > 'NaN error' to either 'domain error' (preferred) or '_. error' . > > > > The only appearance of NaN in the docs should be the one in _., > > which is > > > > The indeterminate _. is provided to aid in dealing with > > NaN (not a number) in data from external sources... > > > > This makes clear that NaN is IEEE, not J. Occam's razor. > > > > Henry Rich > ---------------------------------------------------------------------- > For information about J forums see > http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
