The problem with having _. in arrays and array 
operations is not so much implementation as definition,
not so much how you get the result as what should
be the result.

In the nub example, ((i.#x)=x i.x)#x gives you the
"right" answer for x=: _. _. _. _. 4 5, namely 4 5,
according to how _. is treated by = .  However,
it is counterintuitive that _. is not in the result.
Another example is:

   # ~. _. _. _.
0

That is, the nub of an non-empty array can be empty,
when _. is involved.  Another example is:

   _. _. _. -. _.
_. _. _.

In words, if you removed _. from a vector containing _.,
you still have some _. left.  As I said in my msg,
funny things happen when you fool around with = .



----- Original Message -----
From: Oleg Kobchenko <[EMAIL PROTECTED]>
Date: Tuesday, February 26, 2008 9:21
Subject: Re: [Jbeta] Use of the name 'NaN' deprecated
To: Beta forum <[email protected]>

> 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.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to