MPFR 2.3.1 Release Candidate

MPFR 2.3.1 Release Candidate

[Vincent Lefevre]

The release of MPFR 2.3.1 is imminent. Please help to make this
release as good as possible by downloading and testing this
release candidate:

http://www.mpfr.org/mpfr-2.3.1/mpfr-2.3.1-rc1.tar.bz2
http://www.mpfr.org/mpfr-2.3.1/mpfr-2.3.1-rc1.tar.gz
http://www.mpfr.org/mpfr-2.3.1/mpfr-2.3.1-rc1.zip

The MD5's:
3a029172c380fc28f17db9c727d244e5  mpfr-2.3.1-rc1.tar.bz2
59f3523b93ec6674241110512b932f22  mpfr-2.3.1-rc1.tar.gz
ec69f43ad4bf00c3ce28467f0650bcb8  mpfr-2.3.1-rc1.zip

Changes from version 2.3.0 to version 2.3.1:
- Bug fixes; see <http://www.mpfr.org/mpfr-2.3.0/#bugs>.
- Improved MPFR manual.

Please send success and failure reports to <mpfr@loria.fr>.

If no problems are found, MPFR 2.3.1 should be released around
2008-01-12.

Happy New Year,

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: MPFR 2.3.1 Release Candidate

[Dennis Clarke]

> The release of MPFR 2.3.1 is imminent. Please help to make this
> release as good as possible by downloading and testing this
> release candidate:
>
> http://www.mpfr.org/mpfr-2.3.1/mpfr-2.3.1-rc1.tar.bz2
> http://www.mpfr.org/mpfr-2.3.1/mpfr-2.3.1-rc1.tar.gz
> http://www.mpfr.org/mpfr-2.3.1/mpfr-2.3.1-rc1.zip
>
> The MD5's:
> 3a029172c380fc28f17db9c727d244e5  mpfr-2.3.1-rc1.tar.bz2
> 59f3523b93ec6674241110512b932f22  mpfr-2.3.1-rc1.tar.gz
> ec69f43ad4bf00c3ce28467f0650bcb8  mpfr-2.3.1-rc1.zip
>
> Changes from version 2.3.0 to version 2.3.1:
> - Bug fixes; see <http://www.mpfr.org/mpfr-2.3.0/#bugs>.
> - Improved MPFR manual.
>
> Please send success and failure reports to <mpfr@loria.fr>.
>
> If no problems are found, MPFR 2.3.1 should be released around
> 2008-01-12.

Do you have a testsuite ?  Some battary of tests that can be thrown at the
code to determine correct responses to various calculations, error
conditions, underflows and rounding errors etc etc ?

Dennis Clarke

RE: MPFR 2.3.1 Release Candidate

[Dave Korn]

On 29 December 2007 20:07, Dennis Clarke wrote:

> 
> Do you have a testsuite ?  Some battary of tests that can be thrown at the
> code to determine correct responses to various calculations, error
> conditions, underflows and rounding errors etc etc ?

  There's a "make check" target in the tarball.  I don't know how thorough it
is.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: MPFR 2.3.1 Release Candidate

[Dennis Clarke]

> On 29 December 2007 20:07, Dennis Clarke wrote:
>
>>
>> Do you have a testsuite ?  Some battary of tests that can be thrown at the
>> code to determine correct responses to various calculations, error
>> conditions, underflows and rounding errors etc etc ?
>
> There's a "make check" target in the tarball.  I don't know how thorough
> it is.

That is what scares me.

Dennis

Re: MPFR 2.3.1 Release Candidate

[Vincent Lefevre]

On 2007-12-29 20:09:58 -0000, Dave Korn wrote:
> On 29 December 2007 20:07, Dennis Clarke wrote:
> > Do you have a testsuite ?  Some battary of tests that can be thrown at the
> > code to determine correct responses to various calculations, error
> > conditions, underflows and rounding errors etc etc ?
> 
>   There's a "make check" target in the tarball.  I don't know how thorough it
> is.

The testsuite has been improved, but many things remain to do. Here
are the generic improvements since the release of MPFR 2.3.0 (though
not everything is in the 2.3 branch, the tests from the trunk can now
be run against the 2.3 branch):

  * In the generic tests (based on random inputs), much fewer cases
    that yield an exception are generated, i.e. more interesting
    cases are tested in average.

  * Generic bad cases for the correct rounding are now tested for
    functions that have an inverse function implemented (r4817).
    For the other functions, this should also be possible with a
    Newton iteration, but this isn't implemented yet.

  * Some functions were failing when some global flag was set before
    the call, and unfortunately most tests were done with all flags
    cleared. Now, in the generic tests, all the global flags are
    set before a test with a probability 1/2 (part of r5115).

  * The exponent range is now checked at the end of each test file
    (r5136). So, if a function doesn't restore the exponent range
    in some cases, this will probably be detected.

We also test worst cases in double precision for some elementary
functions.

Then there are very useful tests provided by users (in particular
Kevin Rauch, who found many bugs in special cases).

The concept of bad cases should be extended to the underflow and
overflow thresholds, but this isn't done yet.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: MPFR 2.3.1 Release Candidate

[Kaveh R. GHAZI]

On Sat, 29 Dec 2007, Vincent Lefevre wrote:

> The release of MPFR 2.3.1 is imminent. Please help to make this
> release as good as possible by downloading and testing this
> release candidate:
> [...]
> Changes from version 2.3.0 to version 2.3.1:
> - Bug fixes; see <http://www.mpfr.org/mpfr-2.3.0/#bugs>.
> - Improved MPFR manual.

Hi Vincent,

I read through the bugs in 2.3.0 from the above link.  I'm trying to see
if I can write a GCC testcase that exposes one of those bugs when GCC is
linked with mpfr-2.3.0, but passes when I use 2.3.1-rc1.

The bug would need to be exposed using a mantissa size of a C type, like
53 for double, and the default exponent range.  And all the global mpfr
flags are cleared beforehand, and the input precision is the same as the
output precision.  These circumstances seem to eliminate many (all?) of
the potential failures.

I tried several things through gcc+mpfr-2.3.0 like asin(-0.0), but that
folds to -0.0 correctly.  I tried a call to sqrt(2.0) with
-frounding-math.  But the inexact flag is apparently set and gcc
appropriately does not fold this case, instead replying on the library
call to get the rounding correct.

I'd rather not test for inefficiencies or infinite loops because then the
testcase will take too long to timeout and slow down everyone's testsuite
runs.

Often the bug says it will fail on "huge" inputs, but doesn't say exactly
what they are.

Rather than further guessing on my part, would you please suggest
something?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: MPFR 2.3.1 Release Candidate

[Vincent Lefevre]

On 2007-12-31 14:38:21 -0500, Kaveh R. GHAZI wrote:
> I read through the bugs in 2.3.0 from the above link.  I'm trying to see
> if I can write a GCC testcase that exposes one of those bugs when GCC is
> linked with mpfr-2.3.0, but passes when I use 2.3.1-rc1.
> 
> The bug would need to be exposed using a mantissa size of a C type, like
> 53 for double, and the default exponent range.  And all the global mpfr
> flags are cleared beforehand,

Are they cleared before each call to MPFR functions?

> and the input precision is the same as the output precision. These
> circumstances seem to eliminate many (all?) of the potential
> failures.

The fact that the input precision is the same as the output precision
will also eliminate some bugs.

> I tried several things through gcc+mpfr-2.3.0 like asin(-0.0), but
> that folds to -0.0 correctly.

Perhaps because the same variable is used for the input and output?

> I tried a call to sqrt(2.0) with -frounding-math. But the inexact
> flag is apparently set and gcc appropriately does not fold this
> case, instead replying on the library call to get the rounding
> correct.

The ternary value was correct, and I suppose that GCC tests the
ternary value instead of the global inexact flag (this is what one
does in general).

> Often the bug says it will fail on "huge" inputs, but doesn't say
> exactly what they are.

Most of the time, testcases were included in the changesets (not
in 53 bits, but in general, this shouldn't matter). You may want
to look at them.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: MPFR 2.3.1 Release Candidate

[Vincent Lefevre]

On 2007-12-29 23:25:39 +0100, Vincent Lefevre wrote:
>   * Some functions were failing when some global flag was set before
>     the call, and unfortunately most tests were done with all flags
>     cleared. Now, in the generic tests, all the global flags are
>     set before a test with a probability 1/2 (part of r5115).

Unfortunately, there was a bug in these tests, with the consequence
that the value wasn't checked (so, these tests could only detect
assertion failures or freeze). I've just fixed it and another bug
in reciprocal trig/hyperbolic functions which wasn't detected because
of that. If GCC calls these functions with all the flags cleared, it
isn't affected by this bug.

Moreover there is now an mpfrlint script (available via Subversion)
that can be used to detect bad constructs; it should have detected
the above bug, but was incomplete. Again, fixed.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: MPFR 2.3.1 Release Candidate

[Kaveh R. GHAZI]

On Tue, 1 Jan 2008, Vincent Lefevre wrote:

> On 2007-12-31 14:38:21 -0500, Kaveh R. GHAZI wrote:
> > The bug would need to be exposed using a mantissa size of a C type, like
> > 53 for double, and the default exponent range.  And all the global mpfr
> > flags are cleared beforehand,
>
> Are they cleared before each call to MPFR functions?

Yes I call mpfr_clear_flags() before each mpfr function call.  Also, the
individual mpfr types are initialized and destroyed for each call, no
reuse occurs between different mpfr calls.  However...


> > I tried several things through gcc+mpfr-2.3.0 like asin(-0.0), but
> > that folds to -0.0 correctly.
>
> Perhaps because the same variable is used for the input and output?

Yes, reuse occurs for src and dest variable:
          mpfr_clear_flags ();
          inexact = func (m, m, GMP_RNDN);

So I guess I got lucky here. :-)


> > I tried a call to sqrt(2.0) with -frounding-math. But the inexact
> > flag is apparently set and gcc appropriately does not fold this
> > case, instead replying on the library call to get the rounding
> > correct.
>
> The ternary value was correct, and I suppose that GCC tests the
> ternary value instead of the global inexact flag (this is what one
> does in general).

Right, as seen above.  Later on, I do check the global overflow and
underflow flags, but not global inexact.


> > Often the bug says it will fail on "huge" inputs, but doesn't say
> > exactly what they are.
>
> Most of the time, testcases were included in the changesets (not
> in 53 bits, but in general, this shouldn't matter). You may want
> to look at them.

I'll poke around some more and see if I can find something.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: MPFR 2.3.1 Release Candidate

[Vincent Lefevre]

On 2008-01-02 01:06:28 -0500, Kaveh R. GHAZI wrote:
> I'll poke around some more and see if I can find something.

See the new bug fixed in r5162 (for the 2.3 branch). mpfr_gamma on
-1000000001.5 will give you -0 instead of +0.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: MPFR 2.3.1 Release Candidate

[Kaveh R. GHAZI]

On Wed, 2 Jan 2008, Vincent Lefevre wrote:

> See the new bug fixed in r5162 (for the 2.3 branch). mpfr_gamma on
> -1000000001.5 will give you -0 instead of +0.

So I tried that, but mpfr_gamma on that value sets the global underflow
flag.  If overflow/underflow are set by mpfr, GCC will intentionally
bypass folding.  So this particular case is not something I can use.

I don't know if this mpfr case should be setting the underflow flag or if
it's a bug.  Calling the glibc tgamma doesn't seem to think it underflowed
when looking at fetestexcept().

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: MPFR 2.3.1 Release Candidate

[Vincent Lefevre]

On 2008-01-03 21:52:31 -0500, Kaveh R. GHAZI wrote:
> On Wed, 2 Jan 2008, Vincent Lefevre wrote:
> > See the new bug fixed in r5162 (for the 2.3 branch). mpfr_gamma on
> > -1000000001.5 will give you -0 instead of +0.
> 
> So I tried that, but mpfr_gamma on that value sets the global underflow
> flag.  If overflow/underflow are set by mpfr, GCC will intentionally
> bypass folding.  So this particular case is not something I can use.

OK, I forgot that.

> I don't know if this mpfr case should be setting the underflow flag or if
> it's a bug.

It's really an underflow, and the bug (wrong sign) can occur only if
there's an underflow.

> Calling the glibc tgamma doesn't seem to think it underflowed
> when looking at fetestexcept().

vin:~> gp
Reading GPRC: /home/vlefevre/.gprc ...Done.

                  GP/PARI CALCULATOR Version 2.3.2 (released)
           i486 running linux (ix86/GMP-4.2.1 kernel) 32-bit version
    compiled: Apr 13 2007, gcc-4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
                (readline v5.2 enabled, extended help available)

                     Copyright (C) 2000-2006 The PARI Group

PARI/GP is free software, covered by the GNU General Public License, and 
comes WITHOUT ANY WARRANTY WHATSOEVER.

Type ? for help, \q to quit.
Type ?12 for how to get moral (and possibly technical) support.

parisize = 4000000, primelimit = 500000
? gamma(-1000000001.5)
  *** gamma: exponent (expo) overflow
? gamma(-10000001.5)
%1 = 8.262136614106674385317743887 E-65657070

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)