www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5757] New: std.math: exp, expm1, exp2 return 'inf' when no asm.

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5757

           Summary: std.math: exp, expm1, exp2 return 'inf' when no asm.
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody puremagic.com
        ReportedBy: ibuclaw ubuntu.com


--- Comment #0 from Iain Buclaw <ibuclaw ubuntu.com> 2011-03-20 09:05:43 PDT ---
The fallback if D_InlineAsm is not a version predicate (true for non-x86
arch's) is not calling the appropriate libm functions for the precision we
require (need 80bit precision).

Regards


diff --git a/std/math.d b/std/math.d
index e5591e7..6bdb3e7 100644
--- a/std/math.d
+++ b/std/math.d
   -967,7 +967,7    real exp(real x)  safe pure nothrow
         // and exp2 are so similar).
         return exp2(LOG2E*x);
     } else {
-        return core.stdc.math.exp(x);
+        return core.stdc.math.expl(x);
     }
 }
 /// ditto
   -1133,7 +1133,7    L_largenegative:
             ret;
         }
     } else {
-        return core.stdc.math.expm1(x);
+        return core.stdc.math.expm1l(x);
     }
 }

   -1315,7 +1315,7    L_was_nan:
             ret;
         }
     } else {
-        return core.stdc.math.exp2(x);
+        return core.stdc.math.exp2l(x);
     }
 }

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 20 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5757


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au


--- Comment #1 from Don <clugdbug yahoo.com.au> 2011-03-20 16:34:11 PDT ---
(In reply to comment #0)

 The fallback if D_InlineAsm is not a version predicate (true for non-x86
 arch's) is not calling the appropriate libm functions for the precision we
 require (need 80bit precision).


Tricky. On most systems (such as OSX), those functions either don't exist, or
just call the 64 bit versions. Even in cases when they do exist, they are
usually implemented incorrectly. Have you found 80-bit systems where they pass
all the unit tests?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 20 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5757


David Simcha <dsimcha yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsimcha yahoo.com


--- Comment #2 from David Simcha <dsimcha yahoo.com> 2011-03-20 20:27:12 PDT ---
Even if they're not totally correct, I doubt (correct me if I'm wrong) that
they're worse than the 64-bit versions.  The origin of this bug report was
trying to get std.mathspecial working on GDC, which doesn't have inline ASM and
has to use the fallback functions.  For fixing this immediate issue, they may
be good enough.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 20 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5757



--- Comment #3 from Iain Buclaw <ibuclaw ubuntu.com> 2011-03-21 04:09:10 PDT ---
GDC somewhat a bit exceptional, as there's both library functions and it's own
internal real_t floating point emulation routines available (which is not
exactly IEEE 754 compliant, but is close to the description of characteristics
of floating types in the ISO C99 standard), etc...
And there's call optimisation and constant folding which means if the values
are known at compile-time, then most calls would have been evaluated away. (ie:
logN(expN(x))  =>  x)

And I'm sure both GCC and libc aren't always quite what the DMD unittests
expect anyway. I know of at least 1 'off-by-one' math unittest that fails
because of GCC backend truncates rather than rounds the value from real to
double, and another where 1.5 * 10 makes 15.0000000001 - or something to that
effect when formatted into a string literal.

In any case, I'm more concerned about not hurting the systems that *do* have
80-bit math functions. The only other systems out there I can think of that
have it is IA64 - which I have no hardware (though David's already mentioned
that there's yet no IASM for for 64bit on GDC anyway. :)

Regards

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 21 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5757



--- Comment #4 from Don <clugdbug yahoo.com.au> 2011-03-21 10:58:35 PDT ---
(In reply to comment #3)

 GDC somewhat a bit exceptional, as there's both library functions and it's own
 internal real_t floating point emulation routines available (which is not
 exactly IEEE 754 compliant, but is close to the description of characteristics
 of floating types in the ISO C99 standard), etc...
 And there's call optimisation and constant folding which means if the values
 are known at compile-time, then most calls would have been evaluated away. (ie:
 logN(expN(x))  =>  x)
 
 And I'm sure both GCC and libc aren't always quite what the DMD unittests
 expect anyway. I know of at least 1 'off-by-one' math unittest that fails
 because of GCC backend truncates rather than rounds the value from real to
 double, and another where 1.5 * 10 makes 15.0000000001 - or something to that
 effect when formatted into a string literal.
 
 In any case, I'm more concerned about not hurting the systems that *do* have
 80-bit math functions. The only other systems out there I can think of that
 have it is IA64 - which I have no hardware (though David's already mentioned
 that there's yet no IASM for for 64bit on GDC anyway. :)
 
 Regards


Fair enough. AFAIK the only other system with 80-bit reals is Motorola 68K, but
the Freescale(?) upgrades to those processors only have 64 bit. So it's
probably a legacy system even for embedded processors, and won't ever have much
D presence even in the most optimistic scenario.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 21 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5757


Alex Rønne Petersen <alex lycus.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |alex lycus.org
         Resolution|                            |FIXED


--- Comment #5 from Alex Rønne Petersen <alex lycus.org> 2012-09-04 09:09:48
CEST ---
Relevant pull request has been merged:
https://github.com/D-Programming-Language/phobos/pull/770

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