🚀 go-pugleaf

In article <4d1hh7$kd@lyra.csx.cam.ac.uk>, nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
>Numerical analysts use values of the sort that are found in <float.h>
>for many purposes, including:
>    1) Switching to alternate algorithms for special functions.
>    2) Avoiding overflow, underflow and rounding error.
>    3) Selecting appropriate precisions for conversion on I/O.
>    4) Varying the algorithm in the rare cases where it matters.
>Now, (1) needs the values to be preprocessor constants for efficiency.
>Remember that such people are the very people who write the functions
>called via <math.h>, and we like to be able to write code that compiles
>automatically and correctly even on machines that we have never heard
>of!  But to do this efficiently, we have to define our OWN <float.h>,
>which isn't portable!

No, for (1), you do not need to define your own <float.h>.  You need
to address two categories:

(A)  Implementations where definitions in <float.h> are preprocessor
constants.  You can write one version of your code using #if directives
as necessary, presuming that these are preprocessor constants, and your
code will work under all such implementations.

(B)  Implementations where definitions in <float.h> are not preprocessor
constants.  Some of these implementations would be written for and by the
PC crowd that your article mentioned, in which the underlying features
really are not constant and can be varied at run time.  Others of these
implementations would be perverse and not really allow varying at run
time, but you do not have to worry about that, you can just assume that
varying is allowed and you have no problem.  You can write one version of
your code using if statements as necessary, without presuming that these
are preprocessor constants, and your code will work under all implementations.

You might want to provide just one version with additional #if directives
to choose between version (A) for efficiency and (B) for reliability.

And to make this relevant to the C standard, someone who is allowed to
propose new features should propose a preprocessor operator "const",
in the same form as the preprocessor operator "defined", which returns
a 1 if the preprocessor can evaluate the argument as a constant.
This even avoids stealing a keyword from the language, since there
isn't much else a program could do with an identifier named "const".
(Of course this doesn't indicate whether later phases of translation
can evaluate the argument as a constant, but some preprocessors cannot
know whether later phases are capable of that anyway.)

>For categories (2)-(4), efficiency is not crucial.

In another thread going on now at your friendly local news server, some
participants argue that for category (2), efficiency is just as crucial.
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer