From: Gabor Grothendieck <ggrothendieck_at_myway.com>

Date: Mon 26 Jul 2004 - 03:15:30 EST

R-help@stat.math.ethz.ch mailing list

https://www.stat.math.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html Received on Mon Jul 26 03:35:26 2004

Date: Mon 26 Jul 2004 - 03:15:30 EST

Peter Dalgaard <p.dalgaard@biostat.ku.dk> writes:

*>
**> Barry Rowlingson <B.Rowlingson@lancaster.ac.uk> writes:
**>
**> > Liaw, Andy wrote:
**> > > Stupid me: fell into this trap:
**> > >
**> > >>0 == 0 == 0
**> > > [1] FALSE
**> > >
**> >
**> > Ouch!
**> >
**> > Python's comparison operators don't have this trap, since they
**> > unravel each comparison pair in a chain so that:
**> >
**> > (A op1 B op2 C)
**> >
**> > becomes:
**> >
**> > (A op1 B) and (B op2 C)
**>
**> [chop]
**>
**> > Of course old hand Fortran programmers understand all this since the
**> > second thing they learnt (after learning how to tap the space bar six
*

> > times) was the order of precedence of operators...

*>
**> SAS does likewise, at least in recent versions. Whether this kind of
**> syntactical exceptions is actually helpful is debatable. The problem
**> is that you get to teach people that comparisons are binary operators
**> except when they are not...
**>
**> I wonder how Python actually manages this; doesn't look like something
**> that is easy to implement in a yacc-style parser.
*

3 < 5 < 6 ==> (3 < 5) < 6 ==> 5 < 6 ==> 6

which is interpreted as TRUE in if statements, etc.

Note that the 5 is only evaluated once in the above whereas in

(3 < 5) and (5 < 6)

R-help@stat.math.ethz.ch mailing list

https://www.stat.math.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html Received on Mon Jul 26 03:35:26 2004

*
This archive was generated by hypermail 2.1.8
: Fri 18 Mar 2005 - 02:38:22 EST
*