I totally disagree. An error is far superior to NaN or _. . Look what you had to give up to get NaN: x=x is 1 except when x is NaN, and this fact is enshrined in hardware.
----- Original Message ----- From: Björn Helgason <[EMAIL PROTECTED]> Date: Thursday, February 7, 2008 6:21 Subject: Re: [Jbeta] Another incompatibility: _ >. _. WAS: _ <. _. To: Beta forum <[email protected]> > Domain error is hardly ever a good idea. > If it can be avoided by using _. it is much better. > > 2008/2/7, Henry Rich <[EMAIL PROTECTED]>: > > > > 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
