Re: Math Functions

From: Kevin Lynch (krlynch_at_[hidden])
Date: 2001-10-04 12:02:03

Eric Ford writes:

> Is there a reason why you use define's to deal with the std_compat
> namespace?  Why not just use std_compat and make std_compat an alias
> to std, iff the cmath is compliant?

No there really wasn't a reason, it was just the snap decision I made;
in fact, in my development copy, I've changed the way I handle this (I
needed to modify the macros to handle the C99 functions, so the NS is
now a parameter of the macros).  I'll look at changing this some more to
use namespace aliasing here (which I agree is probably the right way to
go.

> MAKE_STD_FUNCTION_REAL2 (and SPECIALIZE_...) need to be able to deal
> with arguments of differing types.  More template arguments...

> ldexp will either need to take two template arguments (even though we
> know the second should be an int) or be done separately.  

I'm not sure I understand these two comments.  Could you elaborate a
bit?  I understand removing the limitation on the SPECIALIZE_... macros
(I've already run into a need to make the return type a parameter
already for some of the C99 functions).  But why does M_S_F_R_2 need to
change?  It is a convenience macro that generates four particular
implementations of template overloads ... is it better to provide a new
macro that takes type arguments to change the current one?  I'll look
into both approaches.  I'm not sure I understand using multiple template
arguments for ldexp; since the second argument MUST be an int, why do we
need to provide it as a template parameter?  And if we do, what should
the behavior be for other types?  Perhaps you could elaborate a little
bit when you have some time.

> for pow, I think we should specialize
> to allow for integers (more likely to be intentional).   I'm not sure
> whether it's appropriate to have the specializations perform
> optimzations in this layer, so maybe just convert both arguments to
> the longer type.  Fernado posted some simple type promotion code a
> while ago, which seems reasonable.

Oops... you're right.  I'll make sure to add those specializations.  I
see these as reasonable

F pow(F,F), F pow(F,I), I pow(I,I), F pow(I,F)

where F is any of the floating point types and I is int or long

I'll also look and see if any of the other functions need this type of
behavior, although I can't think of any off the top of my head for which
this makes sense.  I also just realized that I've still never
implemented the integer functions from <cstdlib>

> Making progress...

Cool.  I'll try to get these changes made by tomorrow, but I'm not sure
that I'll be able to do so.  I'll keep people informed.

Thanks,
E
-- 
-------------------------------------------------------------------------------
Kevin Lynch				voice:	 [phone]
Physics Department			Fax: [phone]
Boston University			office:	 PRB-565
590 Commonwealth Ave.			e-mail:	 krlynch_at_[hidden]
Boston, MA 02215 USA			http://physics.bu.edu/~krlynch
-------------------------------------------------------------------------------