Re: An interesting object lesson (Ada vs C)

Re: An interesting object lesson (Ada vs C)

[Jonathan Guthrie]

In comp.lang.ada Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> Recently during one of my classes (on microprocessor architecture, where
> I asked them to do tests on some particular aspect of MP performance), I
> received the message below from a student who really knows what he is
> doing, and got completely stumped, to the point, where, as you will see
> from the message, he was sure he had found a gcc or Pentium bug.

In the C world, "really knows what he is doing" means "knows how to turn
the warnings on".  Do the student a favor and introduce him to lint and
-Wall.

Elapsed time to my solution of the problem: 45 seconds.  Eliminate the
warnings, and the code gives (on my computer) 
arctan 0.5 = 0.463648
Clock ticks:  1933

> arctan 0 = 3.25435e-229
> Clock ticks:  2160

Wow!  I've got a faster computer!  (I didn't know that was possible!
Maybe it isn't possible.  What value of CLOCKS_PER_SEC does he
have?  Mine is 100.)

> How did x get set to 0!?!?!?!?

It didn't.  It got DISPLAYED as 0.  That's what happens when you use 
compiler-specific extensions (as "long double" is, at least for the
time being) without understanding the underlying mechanisms.  By the
mechanism that printf uses to accept parameters, it had every reason to
expect that you would pass it a double, but you passed it a long
double.

Is this a problem with the language?  Well, yes.  The original language
specified that floating-point values be passed as doubles to avoid
this exact problem.  Since the prototype system doesn't work with
functions with a variable number of procedures, it still uses that
mechanism to avoid problems.  When ISO C added new (higher-precision)
floating-point types without care, they broke that safety net.

Of course, using a language that does better type checking would have
eliminated the possibility of this particular error.  However, this
sort of error is common enough to be checked by the compiler, if you
tell it to.  It is commonly accepted practice (at least with GCC, which
doesn't "cry wolf" too often) to enable all the warnings and to not
accept the code for test if the compiler emits any warnings during the
compile.

Frankly, I don't find this sort of error to be very difficult to debug.
The errors that drive me up a wall all seem to be language-independant.
For example, the last time a problem had me muttering to myself and
thinking of compiler (actually, library) bugs, the problem turned out to
be a reversed branch.  Build me a language that can tell me when I've
put "greater than" when I really mean "less than" and you'll have
something.  (If you could also arrange it to make sure I haven't put
"+" when I meant "-" or vice-versa, that would be nice, too.)

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.

Re: An interesting object lesson (Ada vs C)

[Andi Kleen]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Recently during one of my classes (on microprocessor architecture, where
> I asked them to do tests on some particular aspect of MP performance), I
> received the message below from a student who really knows what he is
> doing, and got completely stumped, to the point, where, as you will see
> from the message, he was sure he had found a gcc or Pentium bug. These
> kind of dangers that come from using an untyped language waste a huge
> amount of time. Needless to say if the student had used Ada, he would
> have saved himself a lot of time.

... Or just teach your students to always compile with gcc -Wall (it would
have catched that).

-Andi

Re: An interesting object lesson (Ada vs C)

[Robert Dewar]

<<It didn't.  It got DISPLAYED as 0.  That's what happens when you use
compiler-specific extensions (as "long double" is, at least for the
time being) without understanding the underlying mechanisms.  By the
mechanism that printf uses to accept parameters, it had every reason to
expect that you would pass it a double, but you passed it a long
double.
>>

Incidentally, just so no confusion arises (the use of "you" in the above)
no need to tell me what is wrong, I know (or I would not have posted it),
and no use speaking to the student (he didn't post it here, and is not
reading CLA!)

Re: An interesting object lesson (Ada vs C)

[Robert Dewar]

<<In the C world, "really knows what he is doing" means "knows how to turn
the warnings on".  Do the student a favor and introduce him to lint and
-Wall.
>>

Yes, of course, but the point is that having to rely on warnings for such
very basic type consistency checking is *exactly* the weakness that this
example pointed out (if you think all C compilers come with such warnings,
you have been lucky :-).

Someone else complained at the use of the non-standard long double, true,
but it seems a pity that you *need* a non-standard extension to get at
a basic facility of the underlying architecture -- certainly not something
that is required in Ada!

Re: An interesting object lesson (Ada vs C)

[Al Christians]

Jonathan Guthrie wrote:
> 
> 
> Elapsed time to my solution of the problem: 45 seconds.  Eliminate the
> warnings, and the code gives (on my computer)
> arctan 0.5 = 0.463648
> Clock ticks:  1933
> 
> > arctan 0 = 3.25435e-229
> > Clock ticks:  2160
> 
> Wow!  I've got a faster computer!  (I didn't know that was possible!
> Maybe it isn't possible.  What value of CLOCKS_PER_SEC does he
> have?  Mine is 100.)
> 
> > How did x get set to 0!?!?!?!?
> 
> It didn't.  It got DISPLAYED as 0.  That's what happens when you use
> compiler-specific extensions (as "long double" is, at least for the
> time being) without understanding the underlying mechanisms.  By the
> mechanism that printf uses to accept parameters, it had every reason to
> expect that you would pass it a double, but you passed it a long
> double.
> 

If x didn't get changed,  howcome the answers for arctan are so
different?
I put the code posted into MS VC++ v5 with the strictest warning level,
and
I got the 0.463648 answer (looks reasonable for arctan 0.5) with no
warnings
at all.  MingW32, based on GCC gives the warnings and the arctan 0
answer.

I guess that MS would probably say that you don't need to issue the
warning
if you don't drop the ball.  

This obviously has profound implications for Ada, but I won't mention
them
here for lack of interest in compiler/vendor/ .../ .../language  wars.  


Al

An interesting object lesson (Ada vs C)

[Robert Dewar]

Recently during one of my classes (on microprocessor architecture, where
I asked them to do tests on some particular aspect of MP performance), I
received the message below from a student who really knows what he is
doing, and got completely stumped, to the point, where, as you will see
from the message, he was sure he had found a gcc or Pentium bug. These
kind of dangers that come from using an untyped language waste a huge
amount of time. Needless to say if the student had used Ada, he would
have saved himself a lot of time.

I will leave it as an excercise for the reader to see the error in
the student's C code:

Classmates & Professor Dewar,

I am comparing the performance of floating point for single, double and
extended double precision numbers.  I am using the code below, with only the
types changed for the three different versions.  This version, the extended
double (long double) version, is returning strange results.  In fact, I'm
convinced I've found a bug in either gcc or the Pentium.

Here is the code:

#include <stdio.h>
#include <time.h>

long double mysqrt( long double number );

long double a, b, y, x = 0.5;
int c;
clock_t ticks1, ticks2;

int main() {
    ticks1 = clock();
    for ( c = 0; c < 100000; c++ ) {
	a = 1.0 / mysqrt(1.0 + x*x);
	b = 1.0;
	while ( (a - b < 0.0 ? b - a : a - b) > 10e-9 ) {
	    a = 0.5 * (a + b);
	    b = mysqrt(a * b);
	}
	y = x / ( mysqrt(1.0 + x*x) * a );
    }
    ticks2 = clock();
    printf( "arctan %g = %g\n", x, y );
    printf( "Clock ticks:  %d\n",
	ticks2 - ticks1 );

    return 0;
}

long double mysqrt( long double number ) {
    long double r = number / 2.0;
    long double old_r = 0.0;
    while ( ( r > old_r ? r - old_r : old_r - r ) / r > 10e-9 ) {
	old_r = r;
	r = 0.5 * ( r + number / r );
    }

    return r;             
}

Notice that x is only assigned to once, when it is initialized.

Here are the results:

arctan 0 = 3.25435e-229
Clock ticks:  2160

How did x get set to 0!?!?!?!?

Re: An interesting object lesson (Ada vs C)

[Aaro Koskinen]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Recently during one of my classes (on microprocessor architecture, where
> I asked them to do tests on some particular aspect of MP performance), I
> received the message below from a student who really knows what he is
> doing, and got completely stumped, to the point, where, as you will see
> from the message, he was sure he had found a gcc or Pentium bug. These
> kind of dangers that come from using an untyped language waste a huge
> amount of time. Needless to say if the student had used Ada, he would
> have saved himself a lot of time.

Perhaps, however this error would have been detected by using correct
compiler options. Apparently, the student has not been taught how to
compile C programs with gcc, or he has been taught wrong...

This is a good example of badly chosen default options of a compiler
(or any other tool). I can't think of any good reason why compiler
should omit warnings, or allow the use of non-language extensions, or
omit run-time checks enforced by the language, unless the user
explicitly wants it.
-- 
Aaro Koskinen, aaro@iki.fi, http://www.iki.fi/aaro

Re: An interesting object lesson (Ada vs C)

[Samuel Tardieu]

>>>>> "Andi" == Andi Kleen <ak@muc.de> writes:

Andi> ... Or just teach your students to always compile with gcc -Wall
Andi> (it would have catched that).

I use myself "gcc -Wall -Werror" each time I have to write C code, but 
even with these settings, it lets me do some stupid mistakes that would
have been caught by type checking.

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: An interesting object lesson (Ada vs C)

[Keith Thompson]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
[...]
> Someone else complained at the use of the non-standard long double, true,
> but it seems a pity that you *need* a non-standard extension to get at
> a basic facility of the underlying architecture -- certainly not something
> that is required in Ada!

The type long double is part of the C standard.  See ANSI/ISO 9899-1990,
section 6.1.2.5:

	There are three floating types, designated as float, double, and
	long double.  The set of values of the type float is a subset
	of the set of values of the type double; the set of values of
	the type double is a subset of the set of the set of values of
	the type long double.

Admittedly, there are still C compilers in use that don't support long
double -- just as there are still Ada compilers in use that don't support
the new features of Ada 95.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> <*>
Qualcomm, San Diego, California, USA  <http://www.qualcomm.com>
It takes a Viking to raze a village.

Re: An interesting object lesson (Ada vs C)

[John McCabe]

Al Christians <achrist@easystreet.com> wrote:

>If x didn't get changed,  howcome the answers for arctan are so
>different?

x is a long double and is displayed incorrectly by the printf %g option. 
Why do you think that the answer, which is also a long double, is so 
different?

-- 
Best Regards
John McCabe

Re: An interesting object lesson (Ada vs C)

[Jonathan Guthrie]

In comp.lang.ada Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> <<In the C world, "really knows what he is doing" means "knows how to turn
> the warnings on".  Do the student a favor and introduce him to lint and
> -Wall.
> >>

> Yes, of course, but the point is that having to rely on warnings for such
> very basic type consistency checking is *exactly* the weakness that this
> example pointed out (if you think all C compilers come with such warnings,
> you have been lucky :-).

No, I have used a tremendous variety of C compilers.  Some have good
warnings, some don't.  In particular, gcc checks this pretty well. 
However I haven't seen that particular warning given by any other
compiler.  That's why I mentioned lint.  That's widely available and
has caught that particlar kind of error for 20 (or so) years.
(Unfortunately, it tends to complain about things like ignored returned
values, that generally are not a big deal.)

The thing is, that type of parameter string/passed parameter mismatch is
determinable to be incorrect by static semantic checking.  (There are
other errors, however, involving similar functions, that are not possible
to analyze using static semantic checks.)  My point is that you need to
make use of all available tools when you have a problem, whether they're
built in to the compiler or not.

Of course, it is possible to design a language that doesn't have this
kind of weakness, but the guys who did C did a pretty good job with the
I/O considering the situation WRT the language design arts of the late
60's.  (Of course, they had it easy.  They stole the system from
FORTRAN.  It was the FORTRAN guys, working in the late 50's that actually
invented this approach to formatted printing.)

> Someone else complained at the use of the non-standard long double, true,
> but it seems a pity that you *need* a non-standard extension to get at
> a basic facility of the underlying architecture -- certainly not something
> that is required in Ada!

First off, "long double" is not non-standard.  It was added by the ANSI C
committee in the mid 80's.  It is now part of the official ISO C standard,
and has been for about a decade.  I suspect that since the "long" size
modifier for floating-point values isn't used very much because it isn't
used very much.  I certainly had no idea that it was standard until I
looked it up.  (I was going to complain about the non-standard extension
myself.)

Secondly, while I understand (I'm interested in Ada, even though I've
never written a program in it) that Ada allows you to specify the sizes of
the various types are, I would expect the compiler to have considerable
leeway to determine how the operations are done.  I would expect the
compiler vendor to trade off between performance and portable
calculations.

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.

Re: An interesting object lesson (Ada vs C)

[Jonathan Guthrie]

In comp.lang.ada Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> <<
> It didn't.  It got DISPLAYED as 0.  That's what happens when you use
> compiler-specific extensions (as "long double" is, at least for the
> time being) without understanding the underlying mechanisms.
> >>

> Incidentally, just so no confusion arises (the use of "you" in the above)
> no need to tell me what is wrong, I know (or I would not have posted it),
> and no use speaking to the student (he didn't post it here, and is not
> reading CLA!)

Two things (then I achieve closure) the "you" is just a general "you" and
might have been replaced by "one".  It holds as well for me as it does
for you and as well as it does for the student in question.

Also, that paragraph wasn't supposed to be part of my post.  I was sure
that "long double" was non-standard, and I wrote that, but I thought I'd
make sure before posting.  (When making statements of fact, it is best to
confirm before making a fool of yoursel.)  After I HAD looked it up, I
apparently didn't delete the correct part of the post.  Apologies to all.

Further deponant sayeth not.

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.