Bug 1721 – std.math.nextafter should be backported to D1 Phobos

Status
RESOLVED
Resolution
WONTFIX
Severity
normal
Priority
P2
Component
phobos
Product
D
Version
D1 (retired)
Platform
x86
OS
Windows
Creation time
2007-12-09T13:48:00Z
Last change time
2015-11-03T17:45:23Z
Assigned to
nobody
Creator
wbaxter

Comments

Comment #0 by wbaxter — 2007-12-09T13:48:05Z
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.
Comment #1 by braddr — 2007-12-09T18:06:04Z
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.
Comment #2 by wbaxter — 2007-12-09T18:15:05Z
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.
Comment #3 by braddr — 2007-12-09T18:47:18Z
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?
Comment #4 by wbaxter — 2007-12-09T19:04:39Z
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
Comment #5 by andrei — 2015-11-03T17:45:23Z
It's unlikely this D1 issue will get worked on, if anyone plans to work on it feel free to reopen.