http://d.puremagic.com/issues/show_bug.cgi?id=5613

           Summary: std.mathspecial.betaIncomplete makes excessively
                    stringent assumptions about FP Precision
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody@puremagic.com
        ReportedBy: dsimcha@yahoo.com


--- Comment #0 from David Simcha <dsimcha@yahoo.com> 2011-02-19 08:00:49 PST ---
std.mathspecial.betaIncomplete fails horribly anytime floating point precision is slightly degraded.  For example, in GDC, exp2() is implemented (don't ask me why) in terms of powl().  This isn't terribly accurate, but the performance of std.mathspecial should degrade more gracefully in the face of this.

The relevant bug reports filed against GDC are:

https://bitbucket.org/goshawk/gdc/issue/140/stdmathspecialbetaincomplete-broken-for-64

https://bitbucket.org/goshawk/gdc/issue/153/exp-not-computed-to-full-80-bit-precision

A test case that completely blows up if precision is somewhat reduced is:

import std.mathspecial, std.stdio;

void main() {
    writeln(betaIncomplete(950, 51, 0.96));
}


From tracing through the code, it appears that betaIncomplete takes the gamma() instead of the logGamma() branch anytime the result can fit in an 80-bit real, including in my test case.  This is silly.  Instead it should leave some margin for safety and make sure the high order bits are right at the expense of some fuzz in the low order bits.

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

http://d.puremagic.com/issues/show_bug.cgi?id=5613


Don <clugdbug@yahoo.com.au> changed:

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


--- Comment #1 from Don <clugdbug@yahoo.com.au> 2011-02-19 11:54:02 PST ---
If exp is only 64 bits, there is ZERO value in supporting 80-bit reals. None at all. If tests are only failing because of low exp() precision, they deserve to fail. I would say that DMD's implementation of 80-bit exp and transcendentals is as inaccurate as you could possibly allow. Probably too inaccurate. If anything does worse than it, it's really, really bad.

OTOH we will need 64-bit function results, for machines where real == double.

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

http://d.puremagic.com/issues/show_bug.cgi?id=5613



--- Comment #2 from David Simcha <dsimcha@yahoo.com> 2011-02-19 12:13:06 PST ---
Ok, so I guess the fix is to put in a version statement to redefine all those constants that determine what branch is used, so that it's still correct in 64-bit precision.  Then, to get GDC working until its exp() function stops sucking, maybe the GDC patches should set the flag to assume 64-bit precision on GDC x64, since as you note, for all practical purposes it is only 64-bit.

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

http://d.puremagic.com/issues/show_bug.cgi?id=5613


David Simcha <dsimcha@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME


--- Comment #3 from David Simcha <dsimcha@yahoo.com> 2011-12-28 06:44:20 PST ---
I'm closing this because it now works fine on GDC, LDC and 64-bit DMD, so it wasn't as much of a problem as I thought it was.

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