Nope, just vagaries of benchmarking.
----- Original Message ----- From: bill lam <[EMAIL PROTECTED]> Date: Tuesday, February 26, 2008 2:34 Subject: Re: [Jbeta] Use of the name 'NaN' deprecated To: Beta forum <[email protected]> > I got these in AMD Athlon > 10 (6!:2) 'x*y' > 0.030096498 > 10 (6!:2) 'a*b' > 0.029117603 > > a*b is faster? > > Roger Hui wrote: > >> 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
