I think we need to get off this idea of thinking of _. as 'not a number'. That's IEEE talk, not J. IEEE supports a whole family of NaNs, but that's immaterial to J.
In J, the definition is enigmatic: The indeterminate _. results from expressions such as _-_ (infinity minus infinity) and from expressions (such as 3+_.) in which an indeterminate argument occurs. but it seems clear to me that _. represents 'an unknown number', not 'a non-number'. As such, we can see some of the rules it obeys in 602: _. ^ 0 1 (correct in my opinion) 0 * _. 0 (again correct in my opinion) 0 ^ _. 0 (incorrect in my opinion, since 0 ^ 0 is 1 and 0 ^ _1 is _) _ >: _. 0 (incorrect IMO - this is what we have been talking about) Henry Rich PS. _. ^ _. |limit error I wonder what's happening there? > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Kip Murray > Sent: Thursday, February 07, 2008 11:21 AM > To: Beta forum > Subject: RE: [Jbeta] Another incompatibility: _ >. _. WAS: _ <. _. > > I think _. as an answer signals the question didn't make > sense. As _. > is _not a number_ (it could be Lucciano Pavarotti's high C), > operations > like x + _. and x >. _. are undefined. Another user could be > depending > on _. as a signal the operation was undefined. > > Of course, depending on _. for anything can be questioned, > and you can > ask why _ , which also is not a number, gets special treatment. The > difference is, we know what rules _ obeys. See for example > The Extended > Real Number System, Section 1.23 of Walter Rudin's Principles of > Mathematical Analysis, Third Edition. > > Kip Murray > > On Thu, 7 Feb 2008, Henry Rich wrote: > > (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 > > > Kip Murray > > [EMAIL PROTECTED] > http://www.math.uh.edu/~km > ---------------------------------------------------------------------- > For information about J forums see > http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
