www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1721] New: std.math.nextafter should be backported to D1 Phobos

reply d-bugmail puremagic.com writes:
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
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1721


braddr puremagic.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement





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


wbaxter gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal





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


braddr puremagic.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED





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






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