Re: Compile-time arithmetics needed

        Preston Briggs


        you want to be careful about folding real arithmetic; this is an easy
        way to get into precision trouble. I limit myself to cases where I
        can prove that the operands (or operand) is equal to some integer.
        That is, I won't fold


3.14 * 1.23


And then we wonder why numeric programmers do obscenities like:


#define E 2.718281828
#define PI 3.141592654
#define E_PI 8.539734223


instead of
#define E_PI (E*PI)


(This is a mild one. Wait until you've had to maintain a large FORTRAN
code full of numbers like the above, two letter variable names like
A1, B2, etc., and no comments! (What's fun is that I was able to
determine what commonly used book of mathematical tables the SOB in
the 1960s used - there were bugs in the Bessel function values entered
in.))


*Some* numerical programmers need full accuracy control. Give them a
way to obtain this. Others, however, don't, so please provide compiler
switches that avoid the need for them to go in and do by hand all of
the arithmetic a compiler could be doing for them.


(By the way, I hope that you *do* preevaluate things like
#define HALF_PI ACOS(1)
because lots of numerical programmers use such
techniques to get the best values for special constants they can get,
without typing in lots of digits. (Of course, it is even more fun when
the compiler gives a different value evaluating such a constant than
the runtime!))


Yes, I know E and PI are available in common header files. They're
only examples.
--
Andy "Krazy" Glew, glew@ichips.intel.com, Intel,
M/S JF1-19, 5200 NE Elam Young Pkwy, Hillsboro, Oregon 97124-6497.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.