ken@cs.toronto.edu (Ken Lalonde) (02/05/90)
On a 4D/240S running 3.2:
% cat t.c
main()
{
double a,b,c;
b = 1.0;
c = 2.0;
a = b==c;
printf("a=%f\n",a);
}
% cc t.c
% ./a.out
a=2147469288.000000markv@gauss.Princeton.EDU (Mark VandeWettering) (02/05/90)
In article <90Feb5.000622est.4918@neat.cs.toronto.edu> ken@cs.toronto.edu (Ken Lalonde) writes: >On a 4D/240S running 3.2: > % cat t.c > main() > { > double a,b,c; > > b = 1.0; > c = 2.0; > a = b==c; > printf("a=%f\n",a); > } > % cc t.c > % ./a.out > a=2147469288.000000 Just what did you expect this to return? Unless I am mistaken, ANSI C still doesn't any distinction about what number is returned, only that it is NOT zero, which is certainly the case for your code here. It is probably also true that comparison of floating point numbers is an inherently dicey proposition. It is also probably bad practice to use a "double" to receive the results of a comparison, the result is usually concieved as an integer quantity. The implicit conversion in the statement above is a little strange and misleading. If I have a complaint, it is that compilers tend not to warn someone of such inherently unportable code. I guess the maxim would be "A correct compiler shouldn't have to compile incorrect programs". Mark
davea@quasar.wpd.sgi.com (David B. Anderson) (02/06/90)
In article <90Feb5.000622est.4918@neat.cs.toronto.edu>, ken@cs.toronto.edu (Ken Lalonde) writes: > double a,b,c; > b = 1.0; > c = 2.0; > a = b==c; The cc bug is in assigning the required 1 or 0 to a double where the conditional involves doubles: int i; i = (a==c); and if(a ==c) .... etc.... work ok. It has been fixed for the release after 3.2. Sorry for the inconvenience. [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ]
conrad@cgl.ucsf.edu (Conrad Huang) (02/06/90)
>>On a 4D/240S running 3.2: >> % cat t.c >> main() >> { >> double a,b,c; >> >> b = 1.0; >> c = 2.0; >> a = b==c; >> printf("a=%f\n",a); >> } >> % cc t.c >> % ./a.out >> a=2147469288.000000 >Just what did you expect this to return? Unless I am mistaken, ANSI C >still doesn't any distinction about what number is returned, only that >it is NOT zero, which is certainly the case for your code here. It is probably >also true that comparison of floating point numbers is an inherently dicey >proposition. Say what!? In K&R, Appendix A, page 189, Section 7.6, "The operators < (less than), > (greater than), <= (less than or equal to) and >= (greater than or equal to) all yield 0 if the spricified relation is false, and 1 if it is true" and on page 190, Section 7.7, "The == (equal to) and the != (not equal to) operators are exactly analogous to the relation operators except for their lower precedence." Please tell me if ANSI C has revoked these statements! So... In the first place, the program ought to print 0, since 1.0 == 2.0 is *false*. In the second place, even if they were equal, it should print 1.000000. Conrad
markv@gauss.Princeton.EDU (Mark VandeWettering) (02/06/90)
In article <12999@cgl.ucsf.EDU> conrad@cgl.ucsf.edu (Conrad Huang) writes: >Say what!? In K&R, Appendix A, page 189, Section 7.6, > > "The operators < (less than), > (greater than), <= (less than or > equal to) and >= (greater than or equal to) all yield 0 if the > spricified relation is false, and 1 if it is true" Gadzooks. I went back and looked this up, and you were right. I had always operated on the assumption that the only thing you knew about TRUE was that it wasn't zero. Oh well, pie in my face number one. >In the first place, the program ought to print 0, since 1.0 == 2.0 is *false*. >In the second place, even if they were equal, it should print 1.000000. Actually, if we wanna get really technical about it, this program shouldn't work at all, because you passed a double to the printf, when in fact it wants a float argument. This usually works out, but I have had it fail on various machines (particularly mips based ones) in very odd ways, so one should be careful. But ignoring that, you are of course correct. It should return 0.0000 and doesn't. Pie in the face #2 for me. That's what I get for posting late at night. Mark
semicon@watsci.uwaterloo.ca (Robert Adsett) (02/06/90)
In article <13600@phoenix.Princeton.EDU> markv@gauss.Princeton.EDU (Mark VandeWettering) writes: >In article <12999@cgl.ucsf.EDU> conrad@cgl.ucsf.edu (Conrad Huang) writes: >> >>In the second place, even if they were equal, it should print 1.000000. > >Actually, if we wanna get really technical about it, this program shouldn't >work at all, because you passed a double to the printf, when in fact it >wants a float argument. This usually works out, but I have had it fail >on various machines (particularly mips based ones) in very odd ways, so >one should be careful. No, floats get expanded to doubles when they are passed. Printf expects to receive a double. If this fails on some machines then either their compiler or library is broken. In ANSI C when a prototype indicates a float parmaeter then there is no implicit conversion. -- Robert Adsett <semicon@watsci.UWaterloo.ca> Dept. of Phys, Univ. of Waterloo, Waterloo Ont. Canada