Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #11331 > unrolled thread

is the < operator transitive?

Back to article view | Back to comp.lang.c

Contents

  is the < operator transitive? Francois Grieu <fgrieu@gmail.com> - 2011-10-07 19:10 +0200
    Re: is the < operator transitive? Robert Wessel <robertwessel2@yahoo.com> - 2011-10-07 13:44 -0500
    Re: is the < operator transitive? Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2011-10-07 18:50 +0000
      Re: is the < operator transitive? Keith Thompson <kst-u@mib.org> - 2011-10-07 12:42 -0700
        Re: is the < operator transitive? Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2011-10-07 20:23 +0000
          Re: is the < operator transitive? Patrick Scheible <kkt@zipcon.net> - 2011-10-07 14:29 -0700
          Re: is the < operator transitive? Keith Thompson <kst-u@mib.org> - 2011-10-07 16:49 -0700
            Re: is the < operator transitive? Patrick Scheible <kkt@zipcon.net> - 2011-10-07 19:19 -0700
          Re: is the < operator transitive? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-08 09:57 -0400
      Re: is the < operator transitive? "BartC" <bc@freeuk.com> - 2011-10-08 13:17 +0100
        Re: is the < operator transitive? Harald van Dijk <truedfx@gmail.com> - 2011-10-08 06:06 -0700
          Re: is the < operator transitive? "BartC" <bc@freeuk.com> - 2011-10-08 14:48 +0100
            Re: is the < operator transitive? Harald van Dijk <truedfx@gmail.com> - 2011-10-08 07:18 -0700
            Re: is the < operator transitive? "BartC" <bc@freeuk.com> - 2011-10-08 15:19 +0100
    Re: is the < operator transitive? Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2011-10-07 18:50 +0000
      Re: is the < operator transitive? jacob navia <jacob@spamsink.net> - 2011-10-07 21:23 +0200
        Re: is the < operator transitive? Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2011-10-07 20:24 +0000
          Re: is the < operator transitive? James Kuyper <jameskuyper@verizon.net> - 2011-10-07 16:40 -0400
            Re: is the < operator transitive? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-07 23:12 +0100
              Re: is the < operator transitive? Harald van Dijk <truedfx@gmail.com> - 2011-10-07 15:28 -0700
                Re: is the < operator transitive? Harald van Dijk <truedfx@gmail.com> - 2011-10-07 15:31 -0700
                Re: is the < operator transitive? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-07 23:36 +0100
                  Re: is the < operator transitive? Patrick Scheible <kkt@zipcon.net> - 2011-10-07 16:18 -0700
                    Re: is the < operator transitive? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-08 10:32 +0100
              Re: is the < operator transitive? James Kuyper <jameskuyper@verizon.net> - 2011-10-07 18:30 -0400
                Re: is the < operator transitive? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-08 00:21 +0100
                  Re: is the < operator transitive? James Kuyper <jameskuyper@verizon.net> - 2011-10-07 21:33 -0400
                    Re: is the < operator transitive? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-08 10:45 +0100
                      Re: is the < operator transitive? James Kuyper <jameskuyper@verizon.net> - 2011-10-08 14:02 -0400
                        Re: is the < operator transitive? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-08 21:49 +0100
                          Re: is the < operator transitive? James Kuyper <jameskuyper@verizon.net> - 2011-10-08 17:17 -0400
                            Re: is the < operator transitive? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-08 22:59 +0100
                              Re: is the < operator transitive? James Kuyper <jameskuyper@verizon.net> - 2011-10-08 21:33 -0400
                                Re: is the < operator transitive? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-09 09:09 +0100
                                  Re: is the < operator transitive? James Kuyper <jameskuyper@verizon.net> - 2011-10-09 07:00 -0400
                      Re: is the < operator transitive? "BartC" <bc@freeuk.com> - 2011-10-09 01:12 +0100
                        Re: is the < operator transitive? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-09 08:55 +0100
              Re: is the < operator transitive? Robert Wessel <robertwessel2@yahoo.com> - 2011-10-07 18:16 -0500
                Re: is the < operator transitive? David Thompson <dave.thompson2@verizon.net> - 2011-10-18 02:03 -0400
                  Re: is the < operator transitive? Robert Wessel <robertwessel2@yahoo.com> - 2011-10-20 18:03 -0500
          Re: is the < operator transitive? Keith Thompson <kst-u@mib.org> - 2011-10-07 16:50 -0700
      Re: is the < operator transitive? "io_x" <a@b.c.invalid> - 2011-10-09 11:00 +0200
        Re: is the < operator transitive? Willem <willem@toad.stack.nl> - 2011-10-09 09:42 +0000
          Re: is the < operator transitive? Ike Naar <ike@sverige.freeshell.org> - 2011-10-09 12:20 +0000
            Re: is the < operator transitive? Willem <willem@toad.stack.nl> - 2011-10-09 12:40 +0000
              Re: is the < operator transitive? Ike Naar <ike@sverige.freeshell.org> - 2011-10-09 12:54 +0000
                Re: is the < operator transitive? Willem <willem@toad.stack.nl> - 2011-10-09 13:04 +0000
              Re: is the < operator transitive? "BartC" <bc@freeuk.com> - 2011-10-09 15:34 +0100
                Re: is the < operator transitive? Willem <willem@toad.stack.nl> - 2011-10-09 15:08 +0000
              Re: is the < operator transitive? Robert Wessel <robertwessel2@yahoo.com> - 2011-10-09 12:14 -0500
    Re: is the < operator transitive? James Kuyper <jameskuyper@verizon.net> - 2011-10-07 15:36 -0400
      Re: is the < operator transitive? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-07 20:00 -0400
        Re: is the < operator transitive? James Kuyper <jameskuyper@verizon.net> - 2011-10-07 21:38 -0400
        Re: is the < operator transitive? Francois Grieu <fgrieu@gmail.com> - 2011-10-09 21:40 +0200
          Re: is the < operator transitive? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-09 16:34 -0400
            Re: is the < operator transitive? Francois Grieu <fgrieu@gmail.com> - 2011-10-11 14:08 +0200
            Re: is the < operator transitive? Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 16:14 -0800

Page 1 of 3  [1] 2 3  Next page →

#11331 — is the < operator transitive?

Is it certain that  ( a<b && b<c && !(a<c) )  is 0?

First assume that each of  a b c  is a constant
per ISO/IEC 9899:1999 6.4.4 ?

If not, what about a counterexample?

How far can we extend (or shrink) the kind of things
that  a b c  can be for this to hold?

In particular, what about unitialized variable such as

int foo(void) {
   {
   unsigned a,b,c;
   return a<b && b<c && !(a<c);
   }

What if unsigned is changed to int? To double?


   Francois Grieu

[toc] | [next] | [standalone]

#11336

On Fri, 07 Oct 2011 19:10:52 +0200, Francois Grieu <fgrieu@gmail.com>
wrote:

>Is it certain that  ( a<b && b<c && !(a<c) )  is 0?
>
>First assume that each of  a b c  is a constant
>per ISO/IEC 9899:1999 6.4.4 ?
>
>If not, what about a counterexample?
>
>How far can we extend (or shrink) the kind of things
>that  a b c  can be for this to hold?
>
>In particular, what about unitialized variable such as
>
>int foo(void) {
>   {
>   unsigned a,b,c;
>   return a<b && b<c && !(a<c);
>   }
>
>What if unsigned is changed to int? To double?


For IEEE style floats, it's not transitive if there are any NaNs ("1.0
> NaN" and "NaN > 1.0" are both *false*).  In your example, if b is a
NaN then a<b and b<c are both false, while a<c could be true.

Some integer formats have NaN-like values as well (covered under trap
representations in the standard).

[toc] | [prev] | [next] | [standalone]

#11338

Francois Grieu wrote:
> Is it certain that  ( a<b && b<c && !(a<c) )  is 0?
> 
> First assume that each of  a b c  is a constant per ISO/IEC 9899:1999
> 6.4.4 ?
> 
> If not, what about a counterexample?
> 
> How far can we extend (or shrink) the kind of things that  a b c  can be
> for this to hold?
> 
> In particular, what about unitialized variable such as
> 
> int foo(void) {
>    {
>    unsigned a,b,c;
>    return a<b && b<c && !(a<c);
>    }
> 
> What if unsigned is changed to int? To double?
> 
> 
>    Francois Grieu

Python comparisons have the cool feature, that a<b<c is the same as (a<b 
&& b<c). So you can use normal notation for multiple comparisons.

IMO it would be great if this could be backported to C.

// EPR

[toc] | [prev] | [next] | [standalone]

#11344

Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
[...]
> Python comparisons have the cool feature, that a<b<c is the same as (a<b 
> && b<c). So you can use normal notation for multiple comparisons.
>
> IMO it would be great if this could be backported to C.

The trouble is that ``a < b < c'' already has a meaning in C, so it would
be an incompatible chnage.

Just as ``a + b + c'' is equivalent to ``(a + b) + c'' ``a < b < c'' is
equivalent to ``(a < b) < c''.  In other words, it evaluates ``(a <b)'',
which yields a value of 0 or 1, and compares that value to c.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#11348

Keith Thompson wrote:

> Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
> [...]
>> Python comparisons have the cool feature, that a<b<c is the same as
>> (a<b && b<c). So you can use normal notation for multiple comparisons.
>>
>> IMO it would be great if this could be backported to C.
> 
> The trouble is that ``a < b < c'' already has a meaning in C, so it
> would be an incompatible chnage.
> 
> Just as ``a + b + c'' is equivalent to ``(a + b) + c'' ``a < b < c'' is
> equivalent to ``(a < b) < c''.  In other words, it evaluates ``(a <b)'',
> which yields a value of 0 or 1, and compares that value to c.

This is just my point, Keith.

I find it hard to believe theres much existing code that deliberately 
uses this unintuitive interpretation. However it must be a cause of many 
bugs!

//EPR

[toc] | [prev] | [next] | [standalone]

#11352

Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:

> Keith Thompson wrote:
>
>> Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
>> [...]
>>> Python comparisons have the cool feature, that a<b<c is the same as
>>> (a<b && b<c). So you can use normal notation for multiple comparisons.
>>>
>>> IMO it would be great if this could be backported to C.
>> 
>> The trouble is that ``a < b < c'' already has a meaning in C, so it
>> would be an incompatible chnage.
>> 
>> Just as ``a + b + c'' is equivalent to ``(a + b) + c'' ``a < b < c'' is
>> equivalent to ``(a < b) < c''.  In other words, it evaluates ``(a <b)'',
>> which yields a value of 0 or 1, and compares that value to c.
>
> This is just my point, Keith.
>
> I find it hard to believe theres much existing code that deliberately 
> uses this unintuitive interpretation. However it must be a cause of many 
> bugs!

That's been C's behavior since K&R.  It wouldn't be my choice if I were
making up a language from scratch, but it makes sense with C's use of
integers for booleans.

-- Patrick

[toc] | [prev] | [next] | [standalone]

#11366

Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
> Keith Thompson wrote:
>> Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
>> [...]
>>> Python comparisons have the cool feature, that a<b<c is the same as
>>> (a<b && b<c). So you can use normal notation for multiple comparisons.
>>>
>>> IMO it would be great if this could be backported to C.
>> 
>> The trouble is that ``a < b < c'' already has a meaning in C, so it
>> would be an incompatible chnage.
>> 
>> Just as ``a + b + c'' is equivalent to ``(a + b) + c'' ``a < b < c'' is
>> equivalent to ``(a < b) < c''.  In other words, it evaluates ``(a <b)'',
>> which yields a value of 0 or 1, and compares that value to c.
>
> This is just my point, Keith.
>
> I find it hard to believe theres much existing code that deliberately 
> uses this unintuitive interpretation. However it must be a cause of many 
> bugs!

The point is that it could *potentially* break existing code, and the
committee is justifiably hesitant to make language changes that do that.

But you may well be right that it would fix more code than it would
break.

Another idea might be to *forbid* expressions like a < b < c.  This
could still break existing code, but wouldn't quietly give it a new
meaning.

Some compilers in effect already do this, by issuing a warning.  gcc,
for example, warns "comparisons like ‘X<=Y<=Z’ do not have their
mathematical meaning".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#11378

Keith Thompson <kst-u@mib.org> writes:

> Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
>> Keith Thompson wrote:
>>> Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
>>> [...]
>>>> Python comparisons have the cool feature, that a<b<c is the same as
>>>> (a<b && b<c). So you can use normal notation for multiple comparisons.
>>>>
>>>> IMO it would be great if this could be backported to C.
>>> 
>>> The trouble is that ``a < b < c'' already has a meaning in C, so it
>>> would be an incompatible chnage.
>>> 
>>> Just as ``a + b + c'' is equivalent to ``(a + b) + c'' ``a < b < c'' is
>>> equivalent to ``(a < b) < c''.  In other words, it evaluates ``(a <b)'',
>>> which yields a value of 0 or 1, and compares that value to c.
>>
>> This is just my point, Keith.
>>
>> I find it hard to believe theres much existing code that deliberately 
>> uses this unintuitive interpretation. However it must be a cause of many 
>> bugs!
>
> The point is that it could *potentially* break existing code, and the
> committee is justifiably hesitant to make language changes that do that.
>
> But you may well be right that it would fix more code than it would
> break.

Doubtful.  New C programmers learn fairly quickly that booleans are
integers.  This particular bug should show up quickly in testing, in
most cases.

> Another idea might be to *forbid* expressions like a < b < c.  This
> could still break existing code, but wouldn't quietly give it a new
> meaning.

It would be really foolish to forbid a language construction that was
allowed for 40 years.

> Some compilers in effect already do this, by issuing a warning.  gcc,
> for example, warns "comparisons like ‘X<=Y<=Z’ do not have their
> mathematical meaning".

That would be more tolerable.  Still, it's a bit like the compiler
issuing a warning every time you use = and might have meant ==.

-- Patrick

[toc] | [prev] | [next] | [standalone]

#11393

On 10/7/2011 4:23 PM, Edward Rutherford wrote:
> [...]
> I find it hard to believe theres much existing code that deliberately
> uses this unintuitive interpretation. However it must be a cause of many
> bugs!

     Can you cite instances of a few of those "many" bugs?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#11390

"Edward Rutherford" <edward.p.rutherford79@REMOVETHIS.gmail.com> wrote in 
message news:j6nhku$s34$1@speranza.aioe.org...


> Python comparisons have the cool feature, that a<b<c is the same as (a<b
> && b<c). So you can use normal notation for multiple comparisons.

When the terms are not simple, then it's not quite the same:

a=1
c=4

def f():
        global c
        c=c-1
        return 2

print (a < f() < c)
print (a < f() and f() < c)

These gives different results.

It's a question of whether the middle term is evaluated once or twice. If 
twice, then the two forms are equivalent, but someone writing a<b<c might 
not know b will be evaluated twice, with unexpected side-effects.

And if once, then a<b<c can give different results from a && b && c.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#11391

On Oct 8, 2:17 pm, "BartC" <b...@freeuk.com> wrote:
> "Edward Rutherford" <edward.p.rutherfor...@REMOVETHIS.gmail.com> wrote in
> messagenews:j6nhku$s34$1@speranza.aioe.org...
> > Python comparisons have the cool feature, that a<b<c is the same as (a<b
> > && b<c). So you can use normal notation for multiple comparisons.
>
> When the terms are not simple, then it's not quite the same:
>[...]
> It's a question of whether the middle term is evaluated once or twice. If
> twice, then the two forms are equivalent, but someone writing a<b<c might
> not know b will be evaluated twice, with unexpected side-effects.
>
> And if once, then a<b<c can give different results from a && b && c.

Isn't this just like saying that C's a+=1 is not equivalent to a=a+1,
because the evaluation of a might have side effects? In C, I don't
believe anybody considers that a problem. Why would it be a problem in
other languages for a<b<c?

[toc] | [prev] | [next] | [standalone]

#11392

"Harald van Dijk" <truedfx@gmail.com> wrote in message 
news:7acdbce2-b878-465a-ab86-a918e847bcd6@x19g2000vbl.googlegroups.com...
> On Oct 8, 2:17 pm, "BartC" <b...@freeuk.com> wrote:
>> "Edward Rutherford" <edward.p.rutherfor...@REMOVETHIS.gmail.com> wrote in
>> messagenews:j6nhku$s34$1@speranza.aioe.org...
>> > Python comparisons have the cool feature, that a<b<c is the same as 
>> > (a<b
>> > && b<c). So you can use normal notation for multiple comparisons.
>>
>> When the terms are not simple, then it's not quite the same:
>>[...]
>> It's a question of whether the middle term is evaluated once or twice. If
>> twice, then the two forms are equivalent, but someone writing a<b<c might
>> not know b will be evaluated twice, with unexpected side-effects.
>>
>> And if once, then a<b<c can give different results from a && b && c.
>
> Isn't this just like saying that C's a+=1 is not equivalent to a=a+1,

EPR was saying it *was* equivalent.

-- 
Bartc

 

[toc] | [prev] | [next] | [standalone]

#11394

On Oct 8, 3:48 pm, "BartC" <b...@freeuk.com> wrote:
> "Harald van Dijk" <true...@gmail.com> wrote in messagenews:7acdbce2-b878-465a-ab86-a918e847bcd6@x19g2000vbl.googlegroups.com...
> > On Oct 8, 2:17 pm, "BartC" <b...@freeuk.com> wrote:
> >> "Edward Rutherford" <edward.p.rutherfor...@REMOVETHIS.gmail.com> wrote in
> >> messagenews:j6nhku$s34$1@speranza.aioe.org...
> >> > Python comparisons have the cool feature, that a<b<c is the same as
> >> > (a<b
> >> > && b<c). So you can use normal notation for multiple comparisons.
>
> >> When the terms are not simple, then it's not quite the same:
> >>[...]
> >> It's a question of whether the middle term is evaluated once or twice. If
> >> twice, then the two forms are equivalent, but someone writing a<b<c might
> >> not know b will be evaluated twice, with unexpected side-effects.
>
> >> And if once, then a<b<c can give different results from a && b && c.
>
> > Isn't this just like saying that C's a+=1 is not equivalent to a=a+1,
>
> EPR was saying it *was* equivalent.

Yes, just as I might say a+=1 is equivalent to a=a+1 in C. It's really
slightly different, but for an explanation of the += operator it'll do
just fine.

[toc] | [prev] | [next] | [standalone]

#11395

"BartC" <bc@freeuk.com> wrote in message news:j6pkbo$3bi$1@dont-email.me...
> "Harald van Dijk" <truedfx@gmail.com> wrote in message
> news:7acdbce2-b878-465a-ab86-a918e847bcd6@x19g2000vbl.googlegroups.com...
>> On Oct 8, 2:17 pm, "BartC" <b...@freeuk.com> wrote:

>>> And if once, then a<b<c can give different results from a && b && c.
>>
>> Isn't this just like saying that C's a+=1 is not equivalent to a=a+1,
>
> EPR was saying it *was* equivalent.

Let me rephrase that: yes it is the same as a+=b and a=a+b!

But the problems of a<b<c (and a<b==c>d=e...) are a little harder to solve I 
think.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#11339

Francois Grieu wrote:
> Is it certain that  ( a<b && b<c && !(a<c) )  is 0?
> 
> First assume that each of  a b c  is a constant per ISO/IEC 9899:1999
> 6.4.4 ?
> 
> If not, what about a counterexample?
> 
> How far can we extend (or shrink) the kind of things that  a b c  can be
> for this to hold?
> 
> In particular, what about unitialized variable such as
> 
> int foo(void) {
>    {
>    unsigned a,b,c;
>    return a<b && b<c && !(a<c);
>    }
> 
> What if unsigned is changed to int? To double?
> 
> 
>    Francois Grieu

Python comparisons have the cool feature, that a<b<c is the same as (a<b 
&& b<c). So you can use normal notation for multiple comparisons.

IMO it would be great if this could be backported to C.

// EPR

[toc] | [prev] | [next] | [standalone]

#11340

Le 07/10/11 20:50, Edward Rutherford a écrit :
>
> Python comparisons have the cool feature, that a<b<c is the same as (a<b
> &&  b<c). So you can use normal notation for multiple comparisons.
>
> IMO it would be great if this could be backported to C.
>
> // EPR


In C

a<b<c

means

a < 1
or
a < 0

depending on the value of b<c

How do you write that in python?

[toc] | [prev] | [next] | [standalone]

#11349

jacob navia wrote:

> Le 07/10/11 20:50, Edward Rutherford a écrit :
>>
>> Python comparisons have the cool feature, that a<b<c is the same as
>> (a<b &&  b<c). So you can use normal notation for multiple comparisons.
>>
>> IMO it would be great if this could be backported to C.
>>
>> // EPR
> 
> 
> In C
> 
> a<b<c
> 
> means
> 
> a < 1
> or
> a < 0
> 
> depending on the value of b<c
> 
> How do you write that in python?

I would write it as
a < (0 if b < c else 1)

I think this Python is clearer about what's going on than C's a<b<c, 
which is just plain misleading.

//EPR

[toc] | [prev] | [next] | [standalone]

#11350

On 10/07/2011 04:24 PM, Edward Rutherford wrote:
> jacob navia wrote:
> 
>> Le 07/10/11 20:50, Edward Rutherford a écrit :
>>>
>>> Python comparisons have the cool feature, that a<b<c is the same as
>>> (a<b &&  b<c). So you can use normal notation for multiple comparisons.
>>>
>>> IMO it would be great if this could be backported to C.
>>>
>>> // EPR
>>
>>
>> In C
>>
>> a<b<c
>>
>> means
>>
>> a < 1
>> or
>> a < 0
>>
>> depending on the value of b<c

Actually, a<b<c is equivalent to (a<b)<c, which means that can be
described as:
    1 < c
    or
    0 < c
    depending upon the value of a<b

> I would write it as
> a < (0 if b < c else 1)
> 
> I think this Python is clearer about what's going on than C's a<b<c, 
> which is just plain misleading.

I agree that it's not particularly useful, but it's the same way the
rest of the C expressions work; each complex expression is made up of a
single top-level operation working on sub-expressions whose result does
not depend upon the which type of expression they occur in. You cannot
give a<b<c a new meaning, equivalent to (a<b) && (b<c) in terms of the
current syntax, while staying within that framework.

You could define '< <' as a special trinary operator like "?:". But then
you'd have to define a<b<c<d as a quaternary operator, etc. That way
lies madness.

[toc] | [prev] | [next] | [standalone]

#11353

James Kuyper <jameskuyper@verizon.net> writes:
<snip>
> You could define '< <' as a special trinary operator like "?:". But then
> you'd have to define a<b<c<d as a quaternary operator, etc. That way
> lies madness.

The madness can be avoided.  There's no need define tertiary or
quaternary (and so on) versions.  In fact doing so either rules out a <
b <= c or it means you need < <= as yet another operator (and so on for
dozens of combinations).

If <, >, <=, >=, == and != all have the same priority, you can parse it
just like a + b - c + d and simply double the operand you have "in hand"
and add &&.  The operators need to be marked as non-associative, but it
can be fitted into an operator precedence grammar very simply.

I've spent the last hour (not exclusively, you understand) trying to
remember what language it was that I've worked on that does this, and
I've come up with nothing.  But I don't think I'm making it up, honest.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#11355

On Oct 8, 12:12 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> If <, >, <=, >=, == and != all have the same priority, you can parse it
> just like a + b - c + d and simply double the operand you have "in hand"
> and add &&.  The operators need to be marked as non-associative, but it
> can be fitted into an operator precedence grammar very simply.
>
> I've spent the last hour (not exclusively, you understand) trying to
> remember what language it was that I've worked on that does this, and
> I've come up with nothing.  But I don't think I'm making it up, honest.

Python does this. Is that what you were trying to think of?

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web