NaN is IEEE terminology. It need have nothing to do with J's _. . Implementing _. as a NaN is an implementation decision and shouldn't affect this discussion.
I think I agree that domain error would be a good idea (but it would break working code). If not, then we need to remember that _. is a number (3!:0 says so), and it has to follow a minimal set of rules, like being not greater than infinity. 0 * _. 0 from 602, seems right to me too. Henry Rich > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Eric Iverson > Sent: Thursday, February 07, 2008 8:56 AM > To: Beta forum > Subject: Re: [Jbeta] Another incompatibility: _ >. _. WAS: _ <. _. > > Remember that NAN is by some accounts "Not a Number" and is > not "An Unknown > Number". This may not help much in figuring out what to do, > but it is an > interesting distinction. By this reasoning there should be > domain errors but > the choice is made to avoid domain error and propogate NAN. > > ----- Original Message ----- > From: "Henry Rich" <[EMAIL PROTECTED]> > To: "'Beta forum'" <[email protected]> > Sent: Thursday, February 07, 2008 8:16 AM > Subject: RE: [Jbeta] Another incompatibility: _ >. _. WAS: _ <. _. > > > > (Note that the subject of the original message contained > > a typo <. for >., though the text was correct.) > > > > I don't see the logic. x+_. > > is _. because if you don't know what _. is, you don't > > know the result, even if x is _ . But with _ >. _. > > you know the result, no matter what _. is: _ >. x > > is _ for all x. So _ would be a reasonable answer. > > > > You said earlier that _. <: _ should produce 1, > > which seems to conform to my argument above. If > > _. is recognized as less-or-equal _, I think it > > needs to follow that _. >. _ is _ . > > > > The case that got me into this _. mess was > > > > 1 2 3 _ I. _. > > > > where I had a list that I thought I had terminated with a > > high value, but I found that _. is higher yet. It > > would simplify analysis and description if _. were > > consistently recognized as not being bigger than _ . > > > > Henry Rich > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Roger Hui > >> Sent: Wednesday, February 06, 2008 10:45 PM > >> To: Beta forum > >> Subject: Re: [Jbeta] Another incompatibility: _ <. _. > >> > >> The answer should be _. for the same reason that x+_. > should be _. . > >> That is, for all numeric atoms x, _. should be the answer for > >> > >> x + _. > >> x >. _. > >> x <. _. > >> _. + x > >> _. >. x > >> _. <. x > >> > >> > >> > >> ----- Original Message ----- > >> From: Henry Rich <[EMAIL PROTECTED]> > >> Date: Wednesday, February 6, 2008 6:55 > >> Subject: [Jbeta] Another incompatibility: _ <. _. > >> To: 'Beta forum' <[email protected]> > >> > >> > I also just got bit by > >> > > >> > _ >. _. > >> > _. > >> > > >> > This gave _ in 601. And in 602, > >> > > >> > _. >. _ > >> > _ > >> > > >> > > >> > I think both results should be _ > >> > ---------------------------------------------------------------------- > >> For information about J forums see > >> http://www.jsoftware.com/forums.htm > > > > > ---------------------------------------------------------------------- > > For information about J forums see > http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see > http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
