> 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.
NaN is an error indicator, a bit pattern that the hardware returns instead of signaling error. When you say that "It would be very hard or inconcievable to predict which initial values and at what step would trigger NaN", you can substitute "cause an error" for "trigger NaN". Hard to predict when an error would happen? No kidding. As for slowing things down. I don't know about "complex geometric calculations", but here is a common matrix calculation, the determinant. If a matrix contains _ or __, then its determinant can not be computed by Gaussian elimination (do the math, you'll see), and the only way I know of is expansion by minors. The former is order n^3; the latter order !n (even though we know the determinant of such a matrix must be _, __, 0, or _.). So if you want to be fast, already you have to do something when _ or __ is present, never mind when _. is present. More slowing down: In J6.02 qbeta x=: 1e6 [EMAIL PROTECTED] 0 y=: 1e6 [EMAIL PROTECTED] 0 a=: _. (1e5 [EMAIL PROTECTED] 1e6)}1e6 [EMAIL PROTECTED] 0 b=: _. (1e5 [EMAIL PROTECTED] 1e6)}1e6 [EMAIL PROTECTED] 0 10 (6!:2) 'x*y' 0.0345632 10 (6!:2) 'a*b' 0.16342 The benchmark was done on an Intel Celeron (AMD Athlon does much better). ----- Original Message ----- From: Oleg Kobchenko <[EMAIL PROTECTED]> Date: Monday, February 25, 2008 20:09 Subject: RE: [Jbeta] Use of the name 'NaN' deprecated To: Beta forum <[email protected]> > 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 > inconcievableto 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
