www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2636] New: std.math.pow should be a template

reply d-bugmail puremagic.com writes:
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.


--
Jan 30 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2636








 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?


--
Jan 30 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2636








 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).


--
Jan 30 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2636






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).


--
Jan 31 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2636


Brad Roberts <braddr puremagic.com> changed:

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



---
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: -------
Feb 18 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2636






 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: -------
Feb 21 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2636




---
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: -------
Feb 21 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2636




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: -------
Feb 22 2010
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2636


Don <clugdbug yahoo.com.au> changed:

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



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: -------
Jun 13 2010