too stringent tests in tango/math/Probability.d ?

Yes, the tests are too stringent. I made them the toughest possible that would still pass on my machine (that way I would know if I accidentally interfered with the convergence properties). The last few digits in those tests come down to luck (may depend on compiler optimisations); if it needs to change by 1..6 digits, that's OK.

So the first should be real.mant_dig-4, the second real.mant_dig-5.

The last one is the only one that's disturbing.

But hey, that's why those unit tests are in there -- they are working!

actually the first two should be real.mant_dig-5 because the test is > not >=.

Last one well as said I don't know. :)

(In [3509]) Reduce stringency (is that a word?) on probability unittests - refs #1048

What can we do to debug the last of the three? I committed the discussed fix for the first two.t

I think there must be a bug in GDC's pow(), since to my relief it's not a bug in the beta or incomplete gamma functions.

Try this code. Does it print the same results as DMD? If they are different, replace pow() with powl() (from tango.stdc.math).

import tango.stdc.stdio;
import tango.math.Math;
void main() {
    real x = pow(1.0L-0.637L, 24);
    printf("%La %La %La\n", 1.0L-0.637L, x, pow(x, 1.0L/24.0L));
    //DMD: 0x1.73b645a1cac08314p-2 0x1.e20907015ee9e66cp-36 0x1.73b645a1cac08314p-2
}

I tried DMD on Linux, GDC on Linux (32 bit and 64 bit), and with both pow (from Math) and powl (from stdc.math) and all ended up with the following result, no variance whatsoever, and note that it is nothing like the one provided above.

0xb.9db22d0e560418ap-5 0xf.1048380af74f336p-39 0xb.9db22d0e560418ap-5

Wierd. Actually those values are the same as DMD. I didn't realize that the format of %La was different on Linux compared to Windows. That's really stupid. Anyway: In probability.d, add the line:

    w = binomialDistribution(0, 24, 0.637L);
    printf("%La %La \n", w, binomialDistributionInv(0, 24, w)); // <--- add this
    assert(feqrel(binomialDistributionInv(0, 24, w), 0.637L)>=real.mant_dig-3);

It should print: 0xf.1048380af74f336p-39 0xb.9db22d0e560418ap-5

It printed

0xf.1048380af74f336p-39 0xa.3126e97902178f2p-4

so the latter value is wrong?

Yes, we have a compiler bug. Actually, the second number I gave wasn't quite right. Converting to the Windows %La format: Should be: 0x1.4624dd2f2042f1e4p-1 = 0.6370000000025636397 Actually is: 0x1.4624dd2f1a9fbe76p-1 = 0.6370000000000000000

We can now proceed with normal compiler bug identification.

Test case is: assert(1.0L - binomialDistributionInv(0, 24, 0xf.1048380af74f336p-39L) == 0x1.73b645a1cac08314p-2L);

Cut it down as normal to make a GDC bug report. Shouldn't be too difficult -- the relevant bit of binomialDistributionInv() is just a call to pow(). Somehow, it's not making the call correctly, or else it is corrupting the return value. We've already proved that pow() itself is fine.

the strange thing is that I don't seem able to reduce it much external programs seem to work, the bug kicks in only with unit test, and only within the probability module (the same unit test in an external module works)... Tomorrow I will try the take the probability module and reduce it as much as possible...

unittest codegen error?

a file like

module xxx.test;
private import tango.math.Math;

import tango.stdc.stdio;

unittest {
    real x = pow(1.0L-0.637L, 24);
    printf("tst %La %La %La\n", 1.0L-0.637L, x, pow(x, 1.0L/24.0L));
}

shows the error when xxx=tango.math

I tried to reproduce it copying one by one the tango.math files in a separate tango/math directory, and the error seems to appear or not depending on the order of compilation of the files(if the file is compiled after Probability.d then the error appears. I do not know if it is connected with symbols in the .a library of the package or the use of package private functions (I suspect the first).

looking more carefully it seems that linking order is the reason of the behavior, linking Math.o before test.o gives the error...

distilled to gdc bug, and submitted as

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