Thread overview
[Issue 1721] New: std.math.nextafter should be backported to D1 Phobos
Dec 09, 2007
d-bugmail
Dec 10, 2007
d-bugmail
Dec 10, 2007
d-bugmail
Dec 10, 2007
d-bugmail
Dec 10, 2007
d-bugmail
December 09, 2007
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.


-- 

December 10, 2007
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.


-- 

December 10, 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.


-- 

December 10, 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?


-- 

December 10, 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


--