On Tuesday, April 16, 2002, at 11:54 PM, Julian Foad wrote:

> Jonathan Polley wrote:
>>
> ...
>>
>> Aside from removing unreferenced variables, the bulk of the changes were
>> in the area of the use of floating-point.  Since C does all passing of
>> floats as doubles, and does all math in double, could we have a mandate
>> that all floating-point valued be double?  I can see it being a pain for
>> the programmer to always add the 'f' at the end of float constants, just
>> go get around the compiler warnings.
>
> No: C (since about 1995) and C++ do not pass all floats as doubles and do 
> not do all (floating) math in double.  If the result is going to be 
> converted back to float, the compiler is allowed to to the calculation in 
> float precision.  Adding "f" to constants is a pain, I agree.  Some 
> compilers can be told to choose the appropriate type for unsuffixed 
> constants in this situation.

My C training goes back to circa 1985, at which time all floats were 
passed as doubles.  In fact, the modern C/C++ compilers to which I have 
access still do this (I don't use gcc, except to rebuild FlightGear).  All 
floating-point co-processors do their work in extended precision (usually 
80-96 bits) and "shorten" the numbers back to the range desired by the 
user, and the single-precision math libraries I have used just cast the 
results of the double-precision routines to be single-precision (it saves 
on duplicated code).

>> While on the subject of floating-point, I will get on one of my soap 
>> boxes.
>>    Taking 5/2.0 may not always yield the result you intend.  I would
>> suggest using 5.0/2.0 or, if you really want the integer result, floor(5.
>> 0/
>> 2.0) and ceil(5.0/2.0).
>
> The C/C++ programmer will intend the result to be 2.5.  This is defined 
> by the "standard arithmetic conversion" rules of C/C++.  What do you 
> think might happen instead?

I must be older than anyone else here, but my collegiate C training drove 
home the fact that mixing integer and floating-point can give you 
unpredictable results.  Granted, this was pre-ANSI C.

>>   Another personal nit is the lack of a leading
>> zero on numbers < 1.0 (I prefer seeing 0.5 rather than .5).  Is there a
>> general preference for FlightGear?
>
> I prefer the leading zero too, but I don't think there is a strong reason 
> to persuade everyone to use it.

There is quite a bit to be said about consistency.

> - Julian
>

Jonathan Polley


_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to