It was bad because _. as a data value is bad. _. does not conform to any specification. On some machines/compilers it does one thing, on others it does another. The interpreter could conceivably enforce some rules, but that's a waste of computer and developer time that nobody thinks is a good idea.
Since you can't count on the _. in your nouns behaving predictably, the interpreter should make sure that it doesn't generate them. Ergo, the NaN error. If you ask for an operation that would have produced a _., you have made a mistake and you were going to come to grief for it; the NaN error just makes you fail a little earlier, at the source of the problem, so you can fix it. The external NaN remains an unavoidable possibility, but just as with any other possible source of bad data, you need to remove the NaN before you start working on the data. I have been making a lot of noise but, to repeat myself, I think this change is a big improvement. I only quibble that I think the NaN error is misnamed and incompletely applied. Henry Rich > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Oleg Kobchenko > Sent: Monday, February 25, 2008 9:08 PM > To: Beta forum > Subject: Re: [Jbeta] Use of the name 'NaN' deprecated > > Can somebody summarise how the old treatment of NaN was bad: > _%_ > _. > and why it is better now, with NaN error, when there is still a chance > of external NaNs. > > > On Feb 25, 2008, at 18:08, "Eric Iverson" > <[EMAIL PROTECTED]> wrote: > > Can more angels dance on _. than a NaN? > > I think of domain as about arguments, not results. > > The choice to have NaN error has been made. Arguments against > are interesting but not compelling. The release is in the > pipeline and can't be stopped. I for one am thankful for this > as it has been a long haul! > > ----- Original Message ----- From: "Henry Rich" <[EMAIL PROTECTED]> > To: "'Beta forum'" <[email protected]> > Sent: Monday, February 25, 2008 5:38 PM > Subject: RE: RE: [Jbeta] Use of the name 'NaN' deprecated > > > 1 o. 1e9 is quite different from 1 o. _ , I think. > If you wanted to, you could calculate > > 1 o. 1000000000x > > to any desired precision. You choose not to support > some values, and that's properly a limit error. But > > 1 o. _ > > cannot be calculated, even in principle. It should > produce _. for exactly the same reason _-_ does. > > My point is, that by introducing 'NaN error' you have > shouldered an implied responsibility to report domain > errors as NaN errors when the error comes from the mathematical > necessities of the user's request rather from implementation > decisions. I just think you should forget the distinction > and call them all domain errors. > > Henry Rich > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Roger Hui > Sent: Monday, February 25, 2008 11:48 AM > To: Beta forum > Subject: Re: RE: [Jbeta] Use of the name 'NaN' deprecated > > 1 o. y and other similar periodic functions signal > limit error when y exceeds a certain theta. Thus: > > 1 o. 1e9 > |limit error > | 1 o.1000000000 > > 1 o. _ is more of the same. > > For finite x and y, the dictionary defines x|y > as y-x*<.y%x+0=x . This device is as good > (or as bad) as any other to make sense of the > cases when x or y are infinite. Accordingly: > > res=: 4 : 'y-x*<.y%x+0=x' > 10 res _ > |NaN error: res > | y -x*<.y%x+0=x > _ res __ > |NaN error: res > | y-x*<.y %x+0=x > > Basically, 10|_ founders on doing _-_ , and > _|__ founders on __%_ . Thank you and > congratulations for being the first successful > hunter in the treasure hunt. > > > > ----- Original Message ----- > From: Henry Rich <[EMAIL PROTECTED]> > Date: Monday, February 25, 2008 2:34 > Subject: RE: [Jbeta] Use of the name 'NaN' deprecated > To: 'Beta forum' <[email protected]> > > > 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 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > ______________________________________________________________ > ______________________ > Be a better friend, newshound, and > know-it-all with Yahoo! Mobile. Try it now. > http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ > > ---------------------------------------------------------------------- > For information about J forums see > http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
