condition true or false? -> (-1 < sizeof("test"))

[Terence]

Funny; I remember the time when a "calculator' meant a person who calculated
for a living.
The clockwork machine he/she might very well use only understand a negative
input as rotation of the crank one way, and positive as going the other
over-the-top way.
Would you believe I did a postgraduate degree in how, precisely, to use one
of those hand-crank things properly, when studying Numerical Analysis? Yes,
we had electricity of a sort (D.C.at 240 volt; no coil-based transformers -
I had a minature train 00 layout with a dynamo-generator to get 240v down to
12v DC), but see R.Feynman on his opinion of the use of powered omputing
devices at Los Alamos.
It was very much later I met my first American Marchant machine (after we we
got A.C. power).
How could the electical power engineers guess wrong ?(like Edison did in the
USA actually).

 

[gwowen]

While there's a lot of truth to that, the problem is that the C
language defines operators on those abstractions that no mathematician
would.

For arithmetic (+,-,* and [maybe] /) the unsigned integers model Z_N
for some large value of N. That's all fine and dandy, but no sane
mathematician attempts to consider Z_N to be an ordered field, because
there aren't any total orderings that behave sanely w.r.t. addition or
multiplication.

That, and for the Ns in question (powers of 2), Z_N isn't a field.

So the unsigned integers aren't just "not the mathematical concept we
think", they're a solidly defined mathematical concept, with a load of
horribly inappropriate concepts bolted on, whose behaviour is far more
closely related to how silicon works, rather than how mathematics
works.

Except that there is a mathematical object that corresponds exactly to
the defined behaviour (including <), namely Z_N with the ordered induced
by the natural order of N. Yes, it's not as "nice" as an ordered field,
but it's still there.

Well, yes, but an ordering on a field that does not respect the field
operations (or even the group operation) has no uses. You have a
group, and you have an order, but *you don't have an ordered group*.
You have something so useless, it doesn't even have a name. It's not
an ordering in any meaningful way. It's a novelty, not an abstract
model of anything useful. No-one studies them.

And, since Z_N is often defined in terms of equivalence classes (x ~ x
+N), what you say is not even true.

 

[Martin Shobe]

On May 20, 11:37 pm, James Kuyper <[email protected]> wrote:

Note: "mathematically wrong" would require identification of specific
aspects of math that are supposed to correspond to C operators. Oddly
enough, mathematics is sufficiently broad field of study that it does
encompass concepts that correspond very well with the behavior required
by the C standard; they're just not the concepts you think should be
relevant. The problem is not that the choices made by the C standard are
mathematically wrong, it's only that they're different from the ones you
think they should have made.

While there's a lot of truth to that, the problem is that the C
language defines operators on those abstractions that no mathematician
would.

For arithmetic (+,-,* and [maybe] /) the unsigned integers model Z_N
for some large value of N. That's all fine and dandy, but no sane
mathematician attempts to consider Z_N to be an ordered field, because
there aren't any total orderings that behave sanely w.r.t. addition or
multiplication.

That, and for the Ns in question (powers of 2), Z_N isn't a field.

So the unsigned integers aren't just "not the mathematical concept we
think", they're a solidly defined mathematical concept, with a load of
horribly inappropriate concepts bolted on, whose behaviour is far more
closely related to how silicon works, rather than how mathematics
works.

Except that there is a mathematical object that corresponds exactly to
the defined behaviour (including <), namely Z_N with the ordered induced
by the natural order of N. Yes, it's not as "nice" as an ordered field,
but it's still there.

Well, yes, but an ordering on a field that does not respect the field
operations (or even the group operation) has no uses.

Oh please, it quite obviously has at least one use.

You have a
group, and you have an order, but *you don't have an ordered group*.

No one claimed it was an ordered group. But why should we restrict
ourselves to such?

You have something so useless, it doesn't even have a name. It's not
an ordering in any meaningful way. It's a novelty, not an abstract
model of anything useful. No-one studies them.

There aren't enough names to give everything in mathematics a name. So
why should that matter? In any case, it does have a name, you've used
it. It also belongs to several classes of structures including
commutative associative rings with units, groups, etc. which are study,
and when they get studied, so does it.

As for it studying that particular combination of group properties and
ordering? Well, they do study it, they just study each aspect seperately
since the two don't interact in any meaningful way.

And, since Z_N is often defined in terms of equivalence classes (x ~ x
+N), what you say is not even true.

With that definition of Z_N, you'd define < using the smallest
member of each equivalence class.

Martin Shobe

 

[Tim Rentsch]

Mine said 8.42n. But if you used the -v2 verbose switch, it said 8.52.5n.

Your code also gave 0,0,1 on my DMC, and on two other C compilers. But
0,0,0 on lcc-win32.

I extended the program to do sizeof on strings again (and add some
parentheses):

printf( "-1 < sizeof 1 == %d\n", -1 < sizeof 1 );
printf( "-1 < (0l + sizeof 1) == %d\n", -1 < (0l + sizeof 1) );
printf( "-1 < (0ll + sizeof 1) == %d\n", -1 < (0ll + sizeof 1) );
printf( "-1 < sizeof \"\" == %d\n", -1 < sizeof "" );
printf( "-1 < (0l + sizeof \"\") == %d\n", -1 < (0l + sizeof "") );
printf( "-1 < (0ll + sizeof \"\") == %d\n", -1 < (0ll + sizeof "") );

This gave these results:

lccwin32: 0,0,0, 0,0,0
DMC: 0,0,1, 1,1,1
gcc: 0,0,1, 0,0,1
PellesC: 0,0,1, 0,0,1

So definitely something funny with DMC when using sizeof on string
literals, up to 32-bits anyway.

One thing I found puzzling, was why the long-long version compared
differently. Is seemed to give the wrong result (for what C purports
to do) on every compiler except lcc-win32.

But on the whole, I'm more confused now than before..

I played around with dmc852 a little more, and found out the
following:

1. The type 'size_t' is the same as 'unsigned int'.
Note that signed/unsigned long have the same
sizes as signed/unsigned int, even though they
are different types, and signed/unsigned long long
is larger. This explains the '0,0,1' behavior
for the different comparisons (ie, no addition,
adding 0L, and adding 0LL). So that's all by
the book.

2. Apparently the particular case for sizeof applied
to a string literal has a type of int rather than
size_t (which is the same as unsigned int). That's
why '-1 < sizeof "foo"' produces the result it
does. Needless to say, taking int as the type for
a sizeof expression, even just the one case of
sizeof applied to a string literal, is not allowed
in a conforming implementation. This is a bug in
the DM implementation. (I didn't find any other
cases in dmc852 where sizeof gives a signed type
rather than an unsigned type.)

3. Curious observation: although this is nominally a
C99 implementation (it supports variable length
arrays, for example), it does not appear to support
compound literals.