Because it's a bug introduced by our use of a different version of the C compiler for J6.02.
----- Original Message ----- From: Don Guinn <[EMAIL PROTECTED]> Date: Thursday, February 7, 2008 9:54 Subject: Re: [Jbeta] Another incompatibility: _ >. _. WAS: _ <. _. To: Beta forum <[email protected]> > Then how come grade down has _. the largest? > > z=._. __ _123.45 0 456.78 _ > z > _. __ _123.45 0 456.78 _ > /:~z > _. __ _123.45 0 456.78 _ > \:~z > _. _ 456.78 0 _123.45 __ > > > On Feb 7, 2008 10:04 AM, Roger Hui <[EMAIL PROTECTED]> wrote: > > > You are correct. I was wrong when I said _ >. _. and _ > <. _. > > should be _. , and the situation is different from x+_. . > > The difference is that J specifies a total array ordering, > > and in this ordering the sequence from smallest to greatest is: > > > > _. __ _123.45 0 456.78 _ > > > > If you are going to have a TAO, obviously _. should be less > > than _ (infinity). _. is specified to be less than __ > (negative> infinity) for to enable an algorithmic > (implementation) advantage. > > > > > > > > ----- Original Message ----- > > From: Henry Rich <[EMAIL PROTECTED]> > > Date: Thursday, February 7, 2008 5:14 > > Subject: RE: [Jbeta] Another incompatibility: _ >. _. > WAS: _ <. _. > > To: 'Beta forum' <[email protected]> > > > > > (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
