digitalmars.D.bugs - [Issue 5613] New: std.mathspecial.betaIncomplete makes excessively stringent assumptions about FP Precision
- d-bugmail puremagic.com (34/34) Feb 19 2011 http://d.puremagic.com/issues/show_bug.cgi?id=5613
- d-bugmail puremagic.com (15/15) Feb 19 2011 http://d.puremagic.com/issues/show_bug.cgi?id=5613
- d-bugmail puremagic.com (10/10) Feb 19 2011 http://d.puremagic.com/issues/show_bug.cgi?id=5613
- d-bugmail puremagic.com (12/12) Dec 28 2011 http://d.puremagic.com/issues/show_bug.cgi?id=5613
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: -------
Feb 19 2011
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: -------
Feb 19 2011
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: -------
Feb 19 2011
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: -------
Dec 28 2011