[Issue 5613] New: std.mathspecial.betaIncomplete makes excessively stringent assumptions about FP Precision

[d-bugmail at puremagic.com]

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 at puremagic.com
        ReportedBy: dsimcha at yahoo.com


--- Comment #0 from David Simcha <dsimcha at 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: -------