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
