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 3 of 3 — ← Prev page 1 2 [3]

#11367

Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> writes:
> jacob navia wrote:
>> Le 07/10/11 20:50, Edward Rutherford a écrit :
[...]
>> In C
>> 
>> a<b<c
>> 
>> means
>> 
>> a < 1
>> or
>> a < 0
>> 
>> depending on the value of b<c

No, it means 0 < c or 1 < c, depending on the value of a < b.

>> 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.

I believe you could also write it in Python as

    (a < b) < c

just as you'd write it in 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]

#11435

"Edward Rutherford" <edward.p.rutherford79@REMOVETHIS.gmail.com> ha scritto nel
messaggio news:j6nhm0$sh9$1@speranza.aioe.org...
> 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.

possible exst one define macro processor power enought for allow this:
#MyDefine   ò1<ò2<ò3   ò1<ò2 && ò2<ò3

if(a<b<c && c>1)  ....
expanded to
if(a<b && b<c && c>1) ....
but that would break C language...
Ciao

> // EPR

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

#11439

io_x wrote:
) possible exst one define macro processor power enought for allow this:
) #MyDefine   ?1<?2<?3   ?1<?2 && ?2<?3
)
) if(a<b<c && c>1)  ....
) expanded to
) if(a<b && b<c && c>1) ....
) but that would break C language...
) Ciao

The C way to handle this would be to have a (varargs) function
increasing(...), which you would then call as increasing(a,b,c),
which returns true if a<b<c in the mathematical sense, and which
(listen very carefully) evaluates b only once.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

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

#11442

On 2011-10-09, Willem <willem@toad.stack.nl> wrote:
> io_x wrote:
> ) possible exst one define macro processor power enought for allow this:
> ) #MyDefine   ?1<?2<?3   ?1<?2 && ?2<?3
> )
> ) if(a<b<c && c>1)  ....
> ) expanded to
> ) if(a<b && b<c && c>1) ....
> ) but that would break C language...
> ) Ciao
>
> The C way to handle this would be to have a (varargs) function
> increasing(...), which you would then call as increasing(a,b,c),
> which returns true if a<b<c in the mathematical sense, and which
> (listen very carefully) evaluates b only once.

Wouldn't this lead to a combinatorial explosion of functions?

    a < b < c      -> increasing(a,b,c)
    a <= b <= c    -> younameit0(a,b,c)
    a <= b < c     -> younameit1(a,b,c)
    a < b == c     -> younameit2(a,b,c)
       ...
    a < b > c      -> younameitn(a,b,c)

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

#11444

Ike Naar wrote:
) On 2011-10-09, Willem <willem@toad.stack.nl> wrote:
)> The C way to handle this would be to have a (varargs) function
)> increasing(...), which you would then call as increasing(a,b,c),
)> which returns true if a<b<c in the mathematical sense, and which
)> (listen very carefully) evaluates b only once.
)
) Wouldn't this lead to a combinatorial explosion of functions?

You perhaps missed the 'varargs' bit:
increasing(a,b,c,d,e,f) -> a<b<c<d<e<f

)     a < b < c      -> increasing(a,b,c)
)     a <= b <= c    -> younameit0(a,b,c)
Yup, one for each inequality operator, that's 4.

)     a <= b < c     -> younameit1(a,b,c)
I can see the need for this, to check if a value is inside a certain range,
where both ends can be closed or open.

That's a different approach from what I proposed above.
Still, you get 4 combinations in total.

)     a < b == c     -> younameit2(a,b,c)
I fail to see the need for this.

)        ...
)     a < b > c      -> younameitn(a,b,c)
That's a different set, where you check if one element is smaller than a
number of others.  Again, 4 functions if you want all of them.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

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

#11445

On 2011-10-09, Willem <willem@toad.stack.nl> wrote:
> Ike Naar wrote:
> ) On 2011-10-09, Willem <willem@toad.stack.nl> wrote:
> )> The C way to handle this would be to have a (varargs) function
> )> increasing(...), which you would then call as increasing(a,b,c),
> )> which returns true if a<b<c in the mathematical sense, and which
> )> (listen very carefully) evaluates b only once.
> )
> ) Wouldn't this lead to a combinatorial explosion of functions?
>
> You perhaps missed the 'varargs' bit:

No, I did not miss that, I was trying to keep the examples simple.

> increasing(a,b,c,d,e,f) -> a<b<c<d<e<f
>
> )     a < b < c      -> increasing(a,b,c)
> )     a <= b <= c    -> younameit0(a,b,c)
> Yup, one for each inequality operator, that's 4.

But if the number of variables increases (when using varargs),
so does the number of combinations.

> )     a <= b < c     -> younameit1(a,b,c)
> I can see the need for this, to check if a value is inside a certain range,
> where both ends can be closed or open.

It's not so far-fetched.  Here is a common idiom in C:

    /* precondition for evaluating a[i] where a has N_A elements */
    0 <= i < N_A

> That's a different approach from what I proposed above.
> Still, you get 4 combinations in total.

That's 2^n if there are n operators in the general (varargs) case.

> )     a < b == c     -> younameit2(a,b,c)
> I fail to see the need for this.

Use your imagination.

> )        ...
> )     a < b > c      -> younameitn(a,b,c)
> That's a different set, where you check if one element is smaller than a
> number of others.  Again, 4 functions if you want all of them.

Again, 2^n in the varargs case.

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

#11447

Ike Naar wrote:
) On 2011-10-09, Willem <willem@toad.stack.nl> wrote:
)> That's a different approach from what I proposed above.
)> Still, you get 4 combinations in total.
)
) That's 2^n if there are n operators in the general (varargs) case.

No, because in the varargs case you have to have all operators the same.
There cannot be 2^n cases, because you don't know beforehand what n is.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

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

#11449

"Willem" <willem@toad.stack.nl> wrote in message
news:slrnj935he.pt6.willem@toad.stack.nl...
> Ike Naar wrote:

> )     a < b == c     -> younameit2(a,b,c)
> I fail to see the need for this.

You might use it wherever you might write:

 a<b && b==c

And C allows that without questioning whether or not it might be useful!

If you're going to allow an arbitrary chain of relational operators, you 
can't just pick and choose whatever combinations might appear useful.

And a general solution using macros probably isn't how to implement it.

-- 
bartc 

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

#11450

BartC wrote:
)
) "Willem" <willem@toad.stack.nl> wrote in message
) news:slrnj935he.pt6.willem@toad.stack.nl...
)> Ike Naar wrote:
)
)> )     a < b == c     -> younameit2(a,b,c)
)> I fail to see the need for this.
)
) You might use it wherever you might write:
)
)  a<b && b==c
)
) And C allows that without questioning whether or not it might be useful!
)
) If you're going to allow an arbitrary chain of relational operators, you 
) can't just pick and choose whatever combinations might appear useful.
)
) And a general solution using macros probably isn't how to implement it.

But I'm NOT picking an arbitrary chain of relational operators.
I'm picking a chain of the _same_ operator, of arbitrary length.

Although there is no real need for that either, in retrospect.
"a < b < c" is very common (in maths) but "a < b < c < d" is not.

What *would* be useful would be a 'between' function.
In 4 flavours, of course (either end can be open and closed).
With open and closed I mean:

a < b < c
a <= b < c
a < b <= c
a <= b <= c

Or, written differently:
b in (a .. c)
b in [a .. c)
b in (a .. c]
b in [a .. c]


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

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

#11451

On Sun, 9 Oct 2011 12:40:14 +0000 (UTC), Willem <willem@toad.stack.nl>
wrote:

>Ike Naar wrote:
>) On 2011-10-09, Willem <willem@toad.stack.nl> wrote:
>)> The C way to handle this would be to have a (varargs) function
>)> increasing(...), which you would then call as increasing(a,b,c),
>)> which returns true if a<b<c in the mathematical sense, and which
>)> (listen very carefully) evaluates b only once.
>)
>) Wouldn't this lead to a combinatorial explosion of functions?
>
>You perhaps missed the 'varargs' bit:
>increasing(a,b,c,d,e,f) -> a<b<c<d<e<f
>
>)     a < b < c      -> increasing(a,b,c)
>)     a <= b <= c    -> younameit0(a,b,c)
>Yup, one for each inequality operator, that's 4.
>
>)     a <= b < c     -> younameit1(a,b,c)
>I can see the need for this, to check if a value is inside a certain range,
>where both ends can be closed or open.
>
>That's a different approach from what I proposed above.
>Still, you get 4 combinations in total.
>
>)     a < b == c     -> younameit2(a,b,c)
>I fail to see the need for this.
>
>)        ...
>)     a < b > c      -> younameitn(a,b,c)
>That's a different set, where you check if one element is smaller than a
>number of others.  Again, 4 functions if you want all of them.


I could see at least a few more cases.  Equality of all values and one
value with a given relationship to a set of values (a greater than (b
or c) ).  Although in thinking about it the first is actually a subset
of the second.  With the single evaluation of each parameter.

But still, I think there's limited utility without something even more
flexible.  It's going to miss many cases (even the common "a <= b < c"
fails to meet any of these patterns).

I think you'd want to end up being able to specify both chains of
operations and sets of values.  Probably with distinct
punctuators/keywords specifying those operations.  Perhaps something
like:

   a $> ($ b, c, d  $) $> ($ e, f $)

Interpreted as a is greater than any of b, c or d, which are in turn
greater than e and f.

How you actually fit this into C syntax is more puzzling.

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

#11342

On 10/07/2011 01:10 PM, Francois Grieu wrote:
> Is it certain that  ( a<b && b<c && !(a<c) )  is 0?

No.

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

None of the counterexamples  that I was able to come up with could be
demonstrated using constants, since C constants cannot be negative (-1
is a unary expression, not a constant), or have pointer type, be NaNs,
or have a trap representation.

> If not, what about a counterexample?

For pointer types the behavior is undefined unless all three pointers
point into or one past the end of the same array object.

Any relation involving a NaN is required to have a value of false.

    #include <math.h>

    double a = 1.0;
    double b = nan();
    double c = 2.0;

Another type of counter-example involves expressions where the usual
arithmetic conversions (6.3.1.8p1) result in the same variable being
converted to two different values in the two different places where it
occur in that expression:

   unsigned long a = 98765UL;
   int b = -12345;
   short c = 1;

The key here is that in a<b, unsigned long has greater rank than long.
As a result, the usual arithmetic conversions (6.3.1.8p1) call for b to
be converted to unsigned long, with the resulting value of
ULLONG_MAX-12344, which is guaranteed to be greater than 98765UL. The
same conversion occurs in a<c, but since c is positive, the conversion
doesn't change it's value. No such conversion occurs in b<c.

> 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);

An uninitialized object may contain a trap representation. If that's the
case, attempting to read it will render the behavior undefined. When the
behavior is undefined, then anything is permitted by the standard. foo()
could return 1, or 0, or -3.5, or "You did it wrong". Your program could
also abort(), or get stuck in an infinite loop, or send hate mail to
your boss.

>    }
> 
> What if unsigned is changed to int? To double?

The behavior of foo() may be undefined when using any type which is
allowed to have a trap representation. The types which are not allowed
to trap include char, unsigned char, signed char, and the exact-width
types from <stdint.h>.

However, even if you use only those types for a, b, and c, the value you
get by reading an uninitialized variable is unspecified; it's not
required to be the same unspecified value each time you read it.
Therefore, foo() could still return either 0 or 1.

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

#11370

On 10/7/2011 3:36 PM, James Kuyper wrote:
> On 10/07/2011 01:10 PM, Francois Grieu wrote:
>> Is it certain that  ( a<b&&  b<c&&  !(a<c) )  is 0?
>
> No.
>
>> First assume that each of  a b c  is a constant
>> per ISO/IEC 9899:1999 6.4.4 ?
>
> None of the counterexamples  that I was able to come up with could be
> demonstrated using constants, since C constants cannot be negative (-1
> is a unary expression, not a constant),[...]

     Nitpick:

	enum { MINUSONE = -1 };

Now MINUSONE *is* an `int' constant with negative value, hence

	(MINUSONE < 0 && 0 < 1u && !(MINUSONE < 1u))

evaluates to 1.

     Also, it is implementation-defined whether the constant '$'
is positive or negative.  All characters in the "basic execution
set" are non-negative, but the dollar sign and many others one might
encounter are not in the BES.

     We now return you to your regularly scheduled pedantry.  Er,
I mean, "programming."

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

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

#11376

On 10/07/2011 08:00 PM, Eric Sosman wrote:
> On 10/7/2011 3:36 PM, James Kuyper wrote:
>> On 10/07/2011 01:10 PM, Francois Grieu wrote:
>>> Is it certain that  ( a<b&&  b<c&&  !(a<c) )  is 0?
>>
>> No.
>>
>>> First assume that each of  a b c  is a constant
>>> per ISO/IEC 9899:1999 6.4.4 ?
>>
>> None of the counterexamples  that I was able to come up with could be
>> demonstrated using constants, since C constants cannot be negative (-1
>> is a unary expression, not a constant),[...]
> 
>      Nitpick:
> 
> 	enum { MINUSONE = -1 };
> 
> Now MINUSONE *is* an `int' constant with negative value, hence
> 
> 	(MINUSONE < 0 && 0 < 1u && !(MINUSONE < 1u))
> 
> evaluates to 1.

You're right, I missed that - so it is possible to demonstrate that '<'
isn't necessarily transitive just using constants:

	(98765UL < MINUSONE ) && ( MINUSONE < 1) && !(97865UL < 1)
-- 
James Kuyper

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

#11454

On 08/10/2011 02:00, Eric Sosman wrote:

> enum { MINUSONE = -1 };
>
> Now MINUSONE *is* an `int' constant with negative value, hence
>
>   (MINUSONE < 0 && 0 < 1u && !(MINUSONE < 1u))

Exactly the counterexample that I was looking after.

   Francois Grieu

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

#11455

On 10/9/2011 3:40 PM, Francois Grieu wrote:
> On 08/10/2011 02:00, Eric Sosman wrote:
>
>> enum { MINUSONE = -1 };
>>
>> Now MINUSONE *is* an `int' constant with negative value, hence
>>
>> (MINUSONE < 0 && 0 < 1u && !(MINUSONE < 1u))
>
> Exactly the counterexample that I was looking after.

     It's a bit of a nit-pick because it relies on sometimes converting
and sometimes not converting an operand.  To the best of my knowledge,
your original expression `( a<b && b<c && !(a<c) )' is guaranteed to be
zero if (not "iff")

     1: a,b,c are expressions of the same type, and
     2: there are no side-effects (including `volatile' references)
        in evaluating a,b,c, and
     3: evaluating a,b,c produces no undefined behavior, and
     4: the three comparisons are themselves defined (a,b,c aren't
        structs, aren't pointers into unrelated arrays, etc.)

     NaN seems a red herring: If any of a,b,c is NaN, then at least one
of a<b and b<c evaluates to zero and the entire expression therefore
evaluates to zero.

     In a follow-up you asked about the case where one or more of
a,b,c is an uninitialized variable.  If so, it has an indeterminate
value and the (3) test fails; the behavior is undefined, and nothing
can be said about the larger expression's value.

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

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

#11516

Le 09/10/2011 22:34, Eric Sosman a écrit :
> (..) To the best of my knowledge,
> your original expression `( a<b && b<c && !(a<c) )' is guaranteed
> to be zero if (not "iff")
>
> 1: a,b,c are expressions of the same type, and
> 2: there are no side-effects (including `volatile' references)
> in evaluating a,b,c, and
> 3: evaluating a,b,c produces no undefined behavior, and
> 4: the three comparisons are themselves defined (a,b,c aren't
> structs, aren't pointers into unrelated arrays, etc.)


I agree with that. I wonder how much we can usefully expand 1,
perhaps to
   1': (among a,b,c, there are not one which is an unsigned integer
   expression and another which is a signed integer expression), and

   Francois Grieu

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

#16145

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 10/9/2011 3:40 PM, Francois Grieu wrote:
>> On 08/10/2011 02:00, Eric Sosman wrote:
>>
>>> enum { MINUSONE = -1 };
>>>
>>> Now MINUSONE *is* an `int' constant with negative value, hence
>>>
>>> (MINUSONE < 0 && 0 < 1u && !(MINUSONE < 1u))
>>
>> Exactly the counterexample that I was looking after.
>
>     It's a bit of a nit-pick because it relies on sometimes converting
> and sometimes not converting an operand.  To the best of my knowledge,
> your original expression `( a<b && b<c && !(a<c) )' is guaranteed to be
> zero if (not "iff")
>
>     1: a,b,c are expressions of the same type, and
>     2: there are no side-effects (including `volatile' references)
>        in evaluating a,b,c, and
>     3: evaluating a,b,c produces no undefined behavior, and
>     4: the three comparisons are themselves defined (a,b,c aren't
>        structs, aren't pointers into unrelated arrays, etc.)

Can be 1 if a, b, and c are expressions with floating-point
operations in them.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web