digitalmars.D.bugs - [Issue 1721] New: std.math.nextafter should be backported to D1 Phobos
- d-bugmail puremagic.com (16/16) Dec 09 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1721
- d-bugmail puremagic.com (13/13) Dec 09 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1721
- d-bugmail puremagic.com (16/16) Dec 09 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1721
- d-bugmail puremagic.com (14/14) Dec 09 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1721
- d-bugmail puremagic.com (17/17) Dec 09 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1721
http://d.puremagic.com/issues/show_bug.cgi?id=1721
Summary: std.math.nextafter should be backported to D1 Phobos
Product: D
Version: 1.024
Platform: PC
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: bugzilla digitalmars.com
ReportedBy: wbaxter gmail.com
On every platform but Linux, D1's std.math.nextafter just throws a
NotImplemented exception. This was fixed in D2's phobos, but hasn't been
backported to D1.
--
Dec 09 2007
d-bugmail puremagic.com
http://d.puremagic.com/issues/show_bug.cgi?id=1721
braddr puremagic.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
------- Comment #1 from braddr puremagic.com 2007-12-09 18:06 -------
I'm reluctant to backport this. It's not a bug fix, and is potentially
behavior changing. Float and double are implicitly converted to real with just
the one version of the function always returning the real precision nextafter
result. Adding specific float and double implementations of nextafter would
result in lower precision result.
Lowering severity to enhancement while pondering the risks more.
--
Dec 09 2007
http://d.puremagic.com/issues/show_bug.cgi?id=1721
wbaxter gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|enhancement |normal
------- Comment #2 from wbaxter gmail.com 2007-12-09 18:15 -------
Yes it changes the behavior. On Windows it would go from being "Unimplemented
error" in all cases to actually doing something. That's the part I was
suggesting be backported. I agree the backport can maintain the exact same
code for version(linux) and do something as close as possible on other
platforms.
In any event it is definitely some sort of bug that a function in std.math
throws undocumented NotImplemented exceptions on a platform-specific basis.
scalebn, lrint, lround, remquo, and nextafter all do this and none of them is
documented as unconditionally throwing an exception on any platform.
--
Dec 09 2007
http://d.puremagic.com/issues/show_bug.cgi?id=1721
braddr puremagic.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
------- Comment #3 from braddr puremagic.com 2007-12-09 18:47 -------
The documentation issue is a problem. I'll fix that no matter what we decide.
I'm reluctant to have nextafter have this grid of support for d1:
windows linux
float yes no (yes via real)
double yes no (yes via real)
real no yes
Is that what you're asking for?
--
Dec 09 2007
http://d.puremagic.com/issues/show_bug.cgi?id=1721
------- Comment #4 from wbaxter gmail.com 2007-12-09 19:04 -------
Yeh, you're right. That does look kind of sucky.
Actually I don't even see how something like "float via real" even works. The
difference between x and nextafter x in 80-bit precision should be zilch in
single precision. So probably the grid is more like:
windows linux
float yes no (incorrect output implicitly generated via real)
double yes no (incorrect output implicitly generated via real)
real no yes
And if I'm right that those linux 'no's are just silently generating incorrect
answers, then it seems reasonable to fix those and make the table:
windows linux
float yes yes
double yes yes
real no yes
--
Dec 09 2007