http://d.puremagic.com/issues/show_bug.cgi?id=2636

           Summary: std.math.pow should be a template
           Product: D
           Version: 1.039
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Phobos
        AssignedTo: clugdbug@yahoo.com.au
        ReportedBy: schveiguy@yahoo.com


Currently, pow is an overloaded function, which always takes real as the first argument.

However, real isn't a common variable type, so passing something that can be implicitly casted to real results in a compiler overload resolution error.

This problem could be solved by implementing pow as a wrapper to the original function (named e.g. _pow):

real pow(T, U)(T t, U u)
{
   return _pow(cast(real)t, u);
}

This should take care of cases where you try to pass a double, int, or even possibly a custom struct that supports an opCast to real.

I'm not sure if casts are needed for the second argument, if they are, special care should be taken to not cast integral types to real, as the integer versions are optimized for that.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2636





------- Comment #1 from andrei@metalanguage.com  2009-01-30 10:56 -------
(In reply to comment #0)
> Currently, pow is an overloaded function, which always takes real as the first argument.
> 
> However, real isn't a common variable type, so passing something that can be implicitly casted to real results in a compiler overload resolution error.
> 
> This problem could be solved by implementing pow as a wrapper to the original function (named e.g. _pow):
> 
> real pow(T, U)(T t, U u)
> {
>    return _pow(cast(real)t, u);
> }
> 
> This should take care of cases where you try to pass a double, int, or even possibly a custom struct that supports an opCast to real.
> 
> I'm not sure if casts are needed for the second argument, if they are, special care should be taken to not cast integral types to real, as the integer versions are optimized for that.
> 

I had the following in my tree for a while, just committed it now so you can look at it:

F pow(F)(F x, uint n) if (isFloatingPoint!(F))
F pow(F)(F x, int n) if (isFloatingPoint!(F))
F pow(F)(F x, F y) if (isFloatingPoint!(F))

Would this be enough?


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2636





------- Comment #2 from schveiguy@yahoo.com  2009-01-30 12:57 -------
(In reply to comment #1)
> I had the following in my tree for a while, just committed it now so you can look at it:
> 
> F pow(F)(F x, uint n) if (isFloatingPoint!(F))
> F pow(F)(F x, int n) if (isFloatingPoint!(F))
> F pow(F)(F x, F y) if (isFloatingPoint!(F))
> 
> Would this be enough?

Is returning F a legitimate concern?  Generally when one is working with one type, one tends to stick with that type, but you would lose precision, as the actual implementation does return a real.  I'd say it's ok to return F instead of real, but others might disagree.

But in general, your implementation is probably viable for D2, but not for D1. D1 Tango can at least be fixed, if Walter nixes fixing D1 phobos (even though this is a fix that does not change the API).


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2636





------- Comment #3 from clugdbug@yahoo.com.au  2009-01-31 04:25 -------
Steven -
(1) Actually, since any x86 implementation using 80-bit reals returns the
result on the FP stack, double pow(double x) actually returns an 80-bit result!
So I think it's OK to return F.
(2) I've managed to sneak a couple of minor improvements into std.math since D1
was frozen, which closed the gap between Tango and Phobos. I think this problem
also can be fixed without any change to user code. I'll do it in Tango first,
though.
(3) pow(x, int) is a function which could sensibly be a compiler intrinsic. (In
fact there are interesting cases like pow(x, 15) which can be done most rapidly
as y = x*x*x; z = y*y return y * z*z; but which are only worth doing if you
know the exponent at compile time).


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2636


Brad Roberts <braddr@puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |braddr@puremagic.com


--- Comment #4 from Brad Roberts <braddr@puremagic.com> 2010-02-18 21:25:20 PST ---
What's the state of this bug with all the pow related changes over the last month or so?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2636



--- Comment #5 from Don <clugdbug@yahoo.com.au> 2010-02-21 11:54:26 PST ---
(In reply to comment #4)
> What's the state of this bug with all the pow related changes over the last month or so?

No change. It's been implemented for D2 for a year. It was never implemented for D1.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2636



--- Comment #6 from Brad Roberts <braddr@puremagic.com> 2010-02-21 13:34:02 PST ---
Any intent to fix in d1 or should it be closed as wontfix?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2636



--- Comment #7 from Steven Schveighoffer <schveiguy@yahoo.com> 2010-02-22 04:57:02 PST ---
As there seems to be very little care for D1 phobos, I'm not sure it matters. Most phobos users probably use D2, and D1 users are probably mostly using Tango (which should have the fix).

I have no problem closing this, I wasn't really caring if Phobos 1 was fixed, but this bug was filed as the result of helping someone who was using phobos (don't remember the details) or discussing it on the newsgroup.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2636


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


--- Comment #8 from Don <clugdbug@yahoo.com.au> 2010-06-13 13:03:54 PDT ---
I do not think it is possible to change this in D1 without breaking existing code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------