Re: [boost] Compile-time power of a run-time base

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2008-02-14 12:53:30

>-----Original Message-----
>From: boost-bounces_at_[hidden] 
>[mailto:boost-bounces_at_[hidden]] On Behalf Of Bruno Lalande
>Sent: 12 February 2008 09:24
>To: boost_at_[hidden]
>Subject: Re: [boost] [Boost] Compile-time power of a run-time base
>
>Maybe we don't have the same need here. What I don't 
>understand is the fact
>that for you, a power with integral argument should return a double. My
>original need when I first talked about returning different 
>possible types
>was just to respect the type used by the caller. That is, if 
>the caller asks
>for pow<2>(int) and works with integers in all the rest of its code,
>providing the result in a float or double can be disturbing 
>and even slow it
>down. For instance, returning the result of pow<2>(10) in a 
>float sounds
>unnatural to me if 10 was originally stored in an int. But obviously,
>pow<-N>(int) should return a floating point since the result 
>is of the form 1/int.
>
>If I understand well, your approach is rather to take care of 
>providing a
>type capable of holding the result even in case of big 
>integral exponent and
>big integral base. Am I right or is there another rationale 
>behind what you propose?

I feel there is an assumption that most applications will use the resultant value in a calculation using a floating-point type, so
you don't lose anything by not returning an integral type. And it reduces the (quite serious) risk of overflowing the integer type.
It avoids an ugly asymmetry with negative exponents too.

While it might be possible to test if the result will overflow, it all sounds a bit too complicated.

But I have to admit that there will be occasions when an integer type is the Right Type.  But there are other ways of achieving this
when efficiency demands it.

So on balance, I think following the rules used in Math Toolkit sounds the best compromise.

"These rules are chosen to be compatible with the behaviour of ISO/IEC 9899:1999 Programming languages - C and with the Draft
Technical Report on C++ Library Extensions, 2005-06-24, section 5.2.1, paragraph 5.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf
"

Perhaps, to allow us to 'have our cake and eat it', some other name (int_positive_pow?) could be used for a version that returns an
integral type? This would have an *unsigned* exponent parameter?  But I am also not quite clear what int type should be returned.
And if and how the serious risk of overflow should be dealt with. Is it all getting a bit too complicated?

Paul

---
Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
[phone] & SMS, Mobile [phone] & SMS
pbristow_at_[hidden]