cottrell@nbs-vms.arpa (COTTRELL, JAMES) (12/14/85)
/* > > >> float a,b; > > >> > > >> a = b + 1.0; /* Gets done in double because 1.0 is a double. > > >> Gag me with a spoon. */ One spoon coming up! > > > Nah, gets done in single because the compiler realizes that 1.0 has > > > the same representation in single and double, and therefore that > > > the result of the addition will be the same. Try as I might, I could not generate any single precision instruxions. I even tried stuff like `a += 1.0' and `a++'. Would that `twere so. > > Sorry, it get's done in double. ALL floats are converted to double prior > > to any operation. (Refer to K&R p. 41 on implicit type conversions.) Agreed. But beware of the word `implicit'. Normally char's & short's get promoted to int's even when combined with themselves, but using the `++', `--', or `op=' forms will do the operation entirely in the shorter length. This is/was a big concern of some implementations of C on say, a z80, where one does not want to extend a char to an int just to mask it with the constant 037. > I really wish people would NOT POST if they don't know what > they're talking about. Andy Koenig, as usual, gave a correct > answer and some turkey, as usual, contradicts him. Sheesh. I couldn't agree more with the intent of this statement. People, before posting, *ask the machine* after you RTFM. Unfortunately, you picked the wrong time to post that. Andy is usually right, but not this time. (Well maybe he is if he has something other than a 4.2 BSD VAX). I agree he *should* be. But I think you owe some turkey an apology and are left eating crow. jim cottrell@nbs */ ------
gwyn@BRL.ARPA (VLD/VMB) (12/16/85)
Add Cottrell to the turkey list if you haven't long ago. It doesn't matter whether HIS particular compiler has the ability to avoid unnecessary conversions in the code it generates or not. The C implementor may at his discretion do so, so long as the effect of the code is as prescribed by the language spec. In the case of char<->int, many compilers do indeed take care to avoid unnecessary conversions. They could do so for float<->double, if the implementor would take the trouble (perhaps the Tartan Labs compiler does; I don't know). When we're discussing general properties of the C language, appeal to a particular implementation proves nothing.
ark@alice.UucP (Andrew Koenig) (12/17/85)
>>> >> float a,b; >>> >> >>> >> a = b + 1.0; /* Gets done in double because 1.0 is a double. >>> >> Gag me with a spoon. */ > One spoon coming up! >>> > Nah, gets done in single because the compiler realizes that 1.0 has >>> > the same representation in single and double, and therefore that >>> > the result of the addition will be the same. > Try as I might, I could not generate any single precision instruxions. > I even tried stuff like `a += 1.0' and `a++'. Would that `twere so. >>> Sorry, it get's done in double. ALL floats are converted to double prior >>> to any operation. (Refer to K&R p. 41 on implicit type conversions.) > Agreed. But beware of the word `implicit'. Normally char's & short's > get promoted to int's even when combined with themselves, but using > the `++', `--', or `op=' forms will do the operation entirely in > the shorter length. This is/was a big concern of some implementations > of C on say, a z80, where one does not want to extend a char to an > int just to mask it with the constant 037. >> I really wish people would NOT POST if they don't know what >> they're talking about. Andy Koenig, as usual, gave a correct >> answer and some turkey, as usual, contradicts him. Sheesh. > I couldn't agree more with the intent of this statement. People, > before posting, *ask the machine* after you RTFM. > Unfortunately, you picked the wrong time to post that. Andy is > usually right, but not this time. (Well maybe he is if he has > something other than a 4.2 BSD VAX). I agree he *should* be. ----------------------------------------------- Let me set the record straight. First, I had intended my comment beginning "Nah, gets done in single..." as semi-facetious, semi-wishful-thinking. If I had written it out fully, it would have gone somewhat like this: "Yes, the language says it should be done in double. However, it is possible for even a fairly stupid compiler to recognize that in many cases of this sort it is possible to obtain exactly the same results by doing the operation in single, and the compiler can reasonably do it in single without butchering the language." Now, obviously what ACTUALLY happens is up to your particular compiler, SO YOU CAN'T TAKE WHAT I SAID AS NECESSARILY APPLYING TO YOUR IMPLEMENTATION! However, I will go so far as to point out that the compiler on my machine does both a=a+1.0 and a=b+1.0 in single.
jimc@ucla-cs.UUCP (12/18/85)
In article <689@brl-tgr.ARPA> cottrell@nbs-vms.arpa (COTTRELL, JAMES) writes: >/* >> > >> float a,b; >> > >> >> > >> a = b + 1.0; /* Gets done in double because 1.0 is a double. >> > >> Gag me with a spoon. */ > >One spoon coming up! > >> > > Nah, gets done in single because the compiler realizes that 1.0 has >> > > the same representation in single and double, and therefore that >> > > the result of the addition will be the same. > >> (3.5x>) and extensive related discussions for the last few days. The preliminary draft "C" standard X3J11/85-138 says in sect. B.1.2.3 (program execution) line 171 that the compiled code has to produce the same (sic) result as double precision, but needn't actually be double. Line 163 makes a similar statement about promoting char to int. By the way, it's hard to be sure that (float)x * (float)y == (float) ( (double)x * (double)y) down to the last bit in every pathological case, but in practice all we really need is that the answers differ less than an implementation-defined maximum, typically 1 least significant bit of float. How do people think about interpreting "same" in this way? James F. Carter (213) 206-1306 UCLA-SEASnet; 2567 Boelter Hall; 405 Hilgard Ave.; Los Angeles, CA 90024 UUCP:...!{ihnp4,ucbvax,{hao!cepu}}!ucla-cs!jimc ARPA:jimc@locus.UCLA.EDU