Your matrix example is apt. Perhaps you would rather have _. then. But maybe not, if you don't know how _. will behave.
If you have to check the output of matrix operations, maybe you could do better to check the inputs to prevent _%_ which is going to produce a value _. that with better- controlled input would be somewhere between 0 and _ . The other side of the argument is one I can appreciate better, because it happened to me when 6.02 came out. I had some code that had been running for years, and it failed because unbeknownst to me it produced _. in some cases. The _. was used in calculations, and eventually an index error resulted in 6.02 where the same code ran fine in 6.01. This is to me a terrifying prospect. As time goes on, I have more & more code deployed, & the idea that a new release may break things becomes more & more to be feared. So, I want to avoid anything that is known to be unpredictable. If _. isn't going to follow known rules, I want no part of it. I want the 'NaN error' to make sure I never see it. It is an outlaw in my data. You might feel differently. You might make a case that NaN error should be something that can be disabled by a foreign, so you can have it in your matrix multiplies. I wouldn't argue against you, as long as I can run in a mode where _. is never generated. So, should NaN error be maskable? Henry Rich > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Oleg Kobchenko > Sent: Monday, February 25, 2008 11:09 PM > To: Beta forum > Subject: RE: [Jbeta] Use of the name 'NaN' deprecated > > Thank you for clarifying the rationale for the > NaN error. > > In some languages division by zero is bad and > they throw an error. While in other very well-designed > languages like JavaScript, NaN is perfectly acceptable, > without an error, and behaves like it used to in J, > supposing the same machine/compiler differences. > > Trapping the NaN error seems like an extra effort, > as opposed to just allowing it to happen with a possibility > of cleaning up the data in an extra step, while allowing > other calculations to proceed. > > The clean-up operation would use a conjunction like > the new one, or the same code invoked with a special-cased > _.=y or x=_. expressions for code sugar. > > The NaN error will prevent operations to proceed > uninterrupted. Suppose you have a large matrix and complex > geometrical calculations. At some point it will yield > _%_ for some positions in the matrix. Knowing your domains > you would substitute the NaN's with some values like 0 or so > *after the calculation*. > > Now let's see what happens with the new NaN error. You apply > your complex expressions to your matrix, and one of the values > triggers the NaN error. The whole matrix evaluation is invalidated > and interrupted with the NaN error. It would be very hard or > inconcievable > to predict which initial values and at what step would trigger > NaN. The seeming alternative of Adverse :: won't be feasible > either, as it has infinite rank and will slow down the calculation. > > These are just a few examples how it's not very clear to see > practical benefits of the new NaN error. On the contrary, > it only seems to serve some seemingly pedantic goals. > > Finally, if someone really wanted an error on NaN, > wouldn't be available with: > > [EMAIL PROTECTED]@(1 e. ,)@(_. = ]) > > > --- Henry Rich <[EMAIL PROTECTED]> wrote: > > > 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 > > > > > > > ______________________________________________________________ > ______________________ > 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
