Thank you for clarification of NaN handling conventions.
They come in accord with NaN handling in JavaScript.
See below some examples including reconstruction of
calculating ~. Nub of rank-1 numeric array with NaNs.
> You get another order of magnitude increase in difficulty
> if you have NaN in arrays. Does Javascript allow that?
Welcome to Console for JScript v5.7.5730, Windows Script Host v5.6.
(C) Copyright 2000-2004 Oleg Kobchenko. No warranties extended.
function Array.prototype.monad(f){var r=[];for(var i=this.length;i--;)r[i]=f(
this[i]);return r;}
function Array.prototype.dyad(f,y){var r=[];for(var i=this.length;i--;)r[i]=f
(this[i],y[i]);return r;}
function Array.prototype.indexOf(y){for(var i=0;i<this.length;i++)if(this[i]=
=y)break;return i;}
function Array.prototype.copy(y){var r=[];for(var i=0;i<y.length;i++)if(y[i])
r.push(this[i]);return r;}
function iota(n){var r=[];for(var i=n;i--;)r[i]=i;return r;}
A = [1,NaN,2,NaN,3,2];
1,NaN,2,NaN,3,2
A.monad(function(y){return y==NaN});
false,false,false,false,false,false
A.monad(function(y){return y!=NaN});
true,true,true,true,true,true
A.monad(function(y){return y>2});
false,false,false,false,true,false
A.monad(function(y){return y<=2});
true,false,true,false,false,true
// nub of x, ((i.#x)=x i. x)#x
si = A.monad(function(y){return A.indexOf(y)});
0,6,2,6,4,2
A.copy(iota(A.length).dyad(function(x,y){return x==y;},si));
1,2,3
--- Roger Hui <[EMAIL PROTECTED]> wrote:
> > Finally, if someone really wanted an error on NaN,
> > wouldn't be available with:
> >
> > [EMAIL PROTECTED]@(1 e. ,)@(_. = ])
>
> The real problem with NaN is that it defies all logic:
> x rel y is specified to be 0 if x or y is NaN and rel is
> a relation (< <: = >: > ~:). So your expression
> would not work. You can change it around so that
> it "works", but in any such expressions you have to
> step very carefully, because all the time your brain
> is screaming at you that (for example) if x>0 is true
> then x<:0 is false. But not if x is NaN.
>
> You get another order of magnitude increase in difficulty
> if you have NaN in arrays. Does Javascript allow that?
>
> Some (rhetorical) questions: What should the answers
> be the following, and why?
>
> ~. _. _. _. _. 4 5
> i.~ _. _. _. _. 4 5
> /: _. _. _. _. 4 5
> /:~ _. _. _. _. 4 5
>
> As another small example, consider the following
> expression for finding the nub of x, ((i.#x)=x i. x)#x ,
> well-known in APL and J for 40 years. Well you
> can forget it if x contains NaN. In J6.02beta:
>
> x=: _. _. _. _. 4 5
> ((i.#x)=x i. x)#x
> 4 5
>
> The last is the "right" answer according to the specs
> for NaN (_.) Funny things happen when you fool
> around with equals.
>
>
>
> ----- 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.
> ----------------------------------------------------------------------
> 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
