"a < b < c" not the same as "(a < b) && (b < c)"?

[Paminu]

In math this expression:

(a < b) && (b < c)

would be described as:

a < b < c

But why is it that in C these two expressions evaluate to something
different for the same values of a, b and c?

e.g:

for a = 0, b = 3 and c = 2:

a < b < c = 1
(a < b) && (b < c) = 0

when typed in C.

 

[pemo]

In math this expression:

(a < b) && (b < c)

would be described as:

a < b < c

But why is it that in C these two expressions evaluate to something
different for the same values of a, b and c?

e.g:

for a = 0, b = 3 and c = 2:

a < b < c = 1
(a < b) && (b < c) = 0

when typed in C.

(0 < 0) && (0 < 0)

false && false = false according to the truth table for logical AND

 

[pemo]

(0 < 0) && (0 < 0)

false && false = false according to the truth table for logical AND

Oops - sorry - bit too quick there!

(0 < 3) && (3 < 2)

true && false = false - logical AND requires both operands to be true to get
a true result

 

[Paminu]

Oops - sorry - bit too quick there!

(0 < 3) && (3 < 2)

true && false = false - logical AND requires both operands to be true to
get a true result

Yes but then what about

0 < 3 < 2

how is that evaluated?

 

[pemo]

pemo wrote:

Yes but then what about

0 < 3 < 2

how is that evaluated?

Associativity - what happens when operators have the same precedence.

< = left to right

So, you've got ((0 < 3) < 2)

which resolves to (1 < 2)

1 [true] (as 0 IS less than 3)

which resolves to 1 (true)

 

[mailtoliyaqing]

I think the problem is the order is from left to right,
the value of a<b is TRUE, which equal to 1, then 1 < c is also TRUE, so
the value of a<b<c is TRUE;

but in the (a<b)&&(b<c)
a<b is TRUE ,1
b<c is FALSE, 0
so they equal to 1&&0 ,means 0

 

[August Karlstrom]

In math this expression:

(a < b) && (b < c)

would be described as:

a < b < c

But why is it that in C these two expressions evaluate to something
different for the same values of a, b and c?

e.g:

for a = 0, b = 3 and c = 2:

a < b < c = 1
(a < b) && (b < c) = 0

when typed in C.

Remember that C has no boolean type. The (binary) "<" operator returns 0
(false) or 1 (true), so `0 < 3' is 1 and `1 < 2' is 1.


August

 

[pete]

In math this expression:

(a < b) && (b < c)

would be described as:

a < b < c

But why is it that in C these two expressions evaluate to something
different for the same values of a, b and c?

Because
(a < b < c)
means
(((a < b) != 0) < c)

 

[August Karlstrom]

Because
(a < b < c)
means
(((a < b) != 0) < c)

....or

((((a < b) != 0) < c) != 0)

or why not

(((((a < b) != 0) < c) != 0) != 0)

and so on... ;-)


August

 

[Keith Thompson]

Remember that C has no boolean type. The (binary) "<" operator returns
0 (false) or 1 (true), so `0 < 3' is 1 and `1 < 2' is 1.

C has had a boolean type for 6 years; C99 added _Bool. It's true that
support for C99 is not yet universal, though.

 

[Skarmander]

C has had a boolean type for 6 years; C99 added _Bool. It's true that
support for C99 is not yet universal, though.

Your second sentence sort-of undoes the first completely, you know.

Next they'll be telling me C++ compilers have started to support the
"export" keyword... though that is completely not comparable, of course.

S.

 

[Keith Thompson]

Your second sentence sort-of undoes the first completely, you know.

Um, no. There's a big difference between "not yet univeral" and
"nonexistent" -- and, strictly speaking, C99 *is* the current C
standard. Most, but not all, compilers I currently have access to do
support _Bool, even if they don't fully support C99.

Saying that C has no boolean type is comparable to saying in, say,
1992 that C has no function prototypes (adjust the year to taste). It
was true that support for prototypes was not universal, but they had
become part of the language.

Most discussions of C99 features to need to be qualified with a
statement that they're not universally supported, but it doesn't make
sense to ignore C99 completely.

 

[August Karlstrom]

C has had a boolean type for 6 years; C99 added _Bool. It's true that
support for C99 is not yet universal, though.

OK, let me rephrase that: C has no native (primitive) boolean type. If
it had then `a < b < c' would not be a valid expression.


August

 

[pete]

...or

((((a < b) != 0) < c) != 0)

or why not

(((((a < b) != 0) < c) != 0) != 0)

and so on... ;-)

The nature of the question was something like
"Why does the same word mean different things,
in different languages?"

Things like
i = i + 1
are never going to make sense,
if Paminu doesn't realise that C is a language,
and that symbols that he knows from mathematics
may have different meanings in C.

 

[Skarmander]

[...]


Remember that C has no boolean type. The (binary) "<" operator returns
0 (false) or 1 (true), so `0 < 3' is 1 and `1 < 2' is 1.

C has had a boolean type for 6 years; C99 added _Bool. It's true
that
support for C99 is not yet universal, though.

Your second sentence sort-of undoes the first completely, you know.

Um, no. There's a big difference between "not yet univeral" and
"nonexistent" -- and, strictly speaking, C99 *is* the current C
standard. Most, but not all, compilers I currently have access to do
support _Bool, even if they don't fully support C99.

OK. Granted. There's a big difference. That nobody is noticing in
practice. Yet. But I can't deny you're right.

Saying that C has no boolean type is comparable to saying in, say,
1992 that C has no function prototypes (adjust the year to taste). It
was true that support for prototypes was not universal, but they had
become part of the language.

Most discussions of C99 features to need to be qualified with a
statement that they're not universally supported, but it doesn't make
sense to ignore C99 completely.

Yeah, yeah. Let's come back and reconvene in, say, 8 years, and count
what percentage of C programs are C99 as opposed to C89. For now,
mentioning C99's features, while instructive and certainly topical,
remains at best a career investment.

I know the exact same inertia happened with C89 and C++ (although
frankly C++ was an extreme example because they kept tweaking the
language) and eventually full support for those became ubiquitous. But I
for one get impatient with so much inertia, and when I see the claim
that support is "not yet universal", I think "is it understatement time
already?"

S.

 

[Dik T. Winter]

>
> C has had a boolean type for 6 years; C99 added _Bool. It's true that
> support for C99 is not yet universal, though.

But that is not really relevant. The operators will not return the boolean
values for a long time. And once they return it: a < b < c becomes
illegal I think.

 

[Dik T. Winter]

> > [...]
> >

> >>Remember that C has no boolean type. The (binary) "<" operator returns
> >>0 (false) or 1 (true), so `0 < 3' is 1 and `1 < 2' is 1.

> >
> >
> > C has had a boolean type for 6 years; C99 added _Bool. It's true that
> > support for C99 is not yet universal, though.

>
> OK, let me rephrase that: C has no native (primitive) boolean type. If
> it had then `a < b < c' would not be a valid expression.

It would be if also other conditions had been fulfilled. Overloading
operators depending on the type returned would be needed. This can be
made sense of if the language allows it (like Ada).

 

[Keith Thompson]

OK, let me rephrase that: C has no native (primitive) boolean type.

If it had then `a < b < c' would not be a valid expression.

That doesn't follow. Even if the "<" operator yielded a value of type
_Bool rather than int, the expression "a < b" would yield either true
or false, and the comparison "true < c" or "false < c" would still be
legal.

C's (more precisely, C99's) native boolean type happens to be an
integer type, and integer type can be freely and implicitly converted
to each other.

 

[Christian Bau]

In math this expression:

(a < b) && (b < c)

would be described as:

a < b < c

But why is it that in C these two expressions evaluate to something
different for the same values of a, b and c?

e.g:

for a = 0, b = 3 and c = 2:

a < b < c = 1
(a < b) && (b < c) = 0

when typed in C.

Because that's the way the syntax is defined. Not very useful. Just for
fun, try defining a grammar that doesn't allow a < b < c (that's easy),
then try defining a grammar that allows expressions like a <= b < c == d
<= e but not a <= b > c, then try defining the semantics like in
mathematics. It's fun.

 

[Keith Thompson]

I know the exact same inertia happened with C89 and C++ (although
frankly C++ was an extreme example because they kept tweaking the
language) and eventually full support for those became ubiquitous. But
I for one get impatient with so much inertia, and when I see the claim
that support is "not yet universal", I think "is it understatement
time already?"

Actually, I think C89 was adopted much more quickly than C99, because
it was such an improvement over K&R C. Function prototypes in
particular caught on very well; it was also popular, I think, just
because of the need for a standard. C99 doesn't have the same
advantages.

In a quick test, I found only one C compiler that rejected the
declaration
_Bool b;
and that was an older version of a compiler whose current version does
support it. (I don't for a moment claim that the compilers I tried
were a representative sample.) And gcc, probably the most popular C
compiler out there, supports *most* of C99, including _Bool. If gcc
ever supports all of C99, I suspect that will provide the needed
pressure on the other vendors.