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

Reply via email to