[comp.lang.c] Single and double precision math functions, are same names possible?

fangchin@portia.Stanford.EDU (Chin Fang) (01/13/91)

precision, libm.a, UNIX.

Not too long ago, Glenn Geers of The Univ. of Sydney published a
alternative math libs containing both single precision and double 
precision lib functions and a header file for Intel i486/386 boxes. 

These libs are designed for use in SysV/386 UNIX environment or 
for Sun i386 and use i387 instruction sets fully, therefore are 
much faster than vendor provided libm.a.

I typically see a 50% run time reduction with my codes which are
normally FLOPs aplenty.

However, if you use these two libs, you must use #include <fpumath.h>
instead of <math.h>.  This is no big deal. Just mv would do. The 
catch comes in when one wants to use the single precision version
of the lib (libffpu.a vs libfpu.a, the later being double precision
as traditional C libm.a). Then j0(), erf() etc. have to be written
as j0f(), erff() etc. in one's src.  This is bearable if one only
intends to run codes on i486/386 boxes.  But assuming porting src
is unavoidable sooner or later, this creates a somewhat unplesant
editing job to do.  Using a sed script should fix it quite nicely.
But I wonder whether C gurus in this group can provide a smart 
way of avoiding using different function names for single and
double precision versions?  

Of course, if they are not used in a code body at the same time,
a marco would do (brutal force however). But if that's not the case,
a wrapper probably would do too but too much hassle.  You don't
want to put a wrapper around each single precision function calls
first, and incur more overhead and one more name to handle the second.

Put it the other way, can you have both precisions using the same name
and just a single header file as though I were still using the standard
libm.a and math.h?  (So transparent that I would have no need to do
extra editing of function names for porting except perhaps a few -D
switches for compiliations?)

So could some one suggest a good way?

Regards

Chin Fang
Mechanical Engineering Department
Stanford University
fangchin@portia.stanford.edu

ps. please email me if possible.  I may not be able to return a
    thank you note to those using bang (!) address schemes due
    to my school's mail server's recent problems.

steve@taumet.com (Stephen Clamage) (01/15/91)

fangchin@portia.Stanford.EDU (Chin Fang) writes:

>precision, libm.a, UNIX.

>Not too long ago, Glenn Geers of The Univ. of Sydney published a
>alternative math libs containing both single precision and double 
>precision lib functions and a header file for Intel i486/386 boxes. 
...
>Put it the other way, can you have both precisions using the same name
>and just a single header file as though I were still using the standard
>libm.a and math.h?  (So transparent that I would have no need to do
>extra editing of function names for porting except perhaps a few -D
>switches for compiliations?)

1.  C method:  The header file looks like this:

	#ifdef USE_FLOATS
		float sin(float);
		float cos(float);
		...etc
	#else
		double sin(double);
		double cos(double);
		...etc
	#endif

You then need two floating-point libraries, one with the float versions,
one with the double versions.  At link time, you select the appropriate
library.  You can do this automatically in a Make file.


2.  C++ method:  The header file looks like this:

	float  sin(float);
	double sin(double);
	float  cos(float);
	double cos(double);
	...etc

To oversimplify a bit, C++ allows multiple versions of a function, as long
as their parameter lists are not the same.  Both versions of each function
reside in the same library, and the correct one will get linked.  No
special compile- or link-time attention is needed.  You can even mix calls
to the float and double versions of the same function within one program
(in which case both get linked).  If the library functions are written in
assembler, the C++ naming conventions must be used for the external names.

A program which conforms to ANSI C standards (including prototypes) will
generally also be a legal and correct C++ program.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com