www.digitalmars.com         C & C++   DMDScript  

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

reply d-bugmail puremagic.com writes:
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



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


Don <clugdbug yahoo.com.au> changed:

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



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




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


David Simcha <dsimcha yahoo.com> changed:

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



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: -------
Dec 28 2011