[Issue 2973] std.math.pow(int, int), etc.

2015-06-09 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=2973

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|2.030   |D2

--


[Issue 2973] std.math.pow(int, int), etc.

2010-02-12 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2973


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


--- Comment #10 from Don clugd...@yahoo.com.au 2010-02-12 00:16:38 PST ---
FIXED: 3^^3 works in DMD 2.040.

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


[Issue 2973] std.math.pow(int, int), etc.

2009-12-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2973


ZY Zhou rin...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |


--- Comment #9 from ZY Zhou rin...@gmail.com 2009-12-04 22:17:46 PST ---
Now we have power operator.
It will be very confusing that 3.0^^3 works but 3^^3 doesn't. Most people would
think ^^ in D is just like ** in python.

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


[Issue 2973] std.math.pow(int, int), etc.

2009-10-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2973


David Simcha dsim...@yahoo.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WONTFIX


--- Comment #7 from David Simcha dsim...@yahoo.com 2009-10-18 07:51:24 PDT ---
Since I filed this one and I'm thoroughly convinced now that it's not necessary
and noone else seems to want it, I'm resolving it as WONTFIX.

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


[Issue 2973] std.math.pow(int, int), etc.

2009-10-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2973



--- Comment #8 from Andrei Alexandrescu and...@metalanguage.com 2009-10-18 
13:06:15 PDT ---
(In reply to comment #7)
 Since I filed this one and I'm thoroughly convinced now that it's not 
 necessary
 and noone else seems to want it, I'm resolving it as WONTFIX.

Thanks for following through.

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


[Issue 2973] std.math.pow(int, int), etc.

2009-10-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2973


Andrei Alexandrescu and...@metalanguage.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|nob...@puremagic.com|and...@metalanguage.com


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


[Issue 2973] std.math.pow(int, int), etc.

2009-08-11 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2973


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au




--- Comment #6 from Don clugd...@yahoo.com.au  2009-08-11 04:58:06 PDT ---
 Casting to floating point is not a good solution b/c
 you lose performance and, in some cases, precision.

Are you sure?
Performance: 
Floating point multiplication is typically the same speed or faster than
integer multiplication on most CPUs from the past 15 years. On most Intel CPUs,
integer multiplication is actually done in the floating point unit.

Precision:
You'll only lose precision if the base is greater than the 1/real.epsilon. For
an 80-bit real, this means precision is lost only when the result is exactly
equal to ulong.max. And the only time that can happen is with pow(ulong.max,
1).
(because ulong.max is divisible by 5, but not by 25).

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


[Issue 2973] std.math.pow(int, int), etc.

2009-07-21 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2973


Andrei Alexandrescu and...@metalanguage.com changed:

   What|Removed |Added

 CC||and...@metalanguage.com




--- Comment #2 from Andrei Alexandrescu and...@metalanguage.com  2009-07-21 
19:19:38 PDT ---
We currently have:

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

I think we're in good shape. We could add overloads for raising integrals to
unsigned powers but I fear confusion due to wraparound. The magnitudes of
exponents for which efficiency could become an issue are also those that would
wraparound the result. If no compelling arguments come up, I'll close this
soon.

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


[Issue 2973] std.math.pow(int, int), etc.

2009-07-21 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2973





--- Comment #3 from David Simcha dsim...@yahoo.com  2009-07-21 19:55:36 PDT 
---
Couldn't you just stick an assert in there to make sure it doesn't wrap around?
 I haven't tested, but I would think that even in debug mode, this would be
faster than using the float version.

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


[Issue 2973] std.math.pow(int, int), etc.

2009-07-21 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2973





--- Comment #4 from Andrei Alexandrescu and...@metalanguage.com  2009-07-21 
20:15:20 PDT ---
(In reply to comment #3)
 Couldn't you just stick an assert in there to make sure it doesn't wrap 
 around?
  I haven't tested, but I would think that even in debug mode, this would be
 faster than using the float version.

1. Please test. What powers are you looking at? For most bases and most
exponents the result will go off range.

2. I prefer returning a floating point number instead of attempting to return
an integer and failing dynamically, all for a doubtful speed benefit.

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