MPFI-1.5.1 is released

Hi,

MPFR users may be interested by the new MPFI version which is mostly a 
bug-fix release. You can read the announce here: 
http://lists.gforge.inria.fr/pipermail/mpfi-users/2012-January/000046.html

The MPFI library is based on MPFR and provides interval arithmetic and 
elementary functions in arbitrary precision.

Best Regards,
The MPFI development team

incomplete (upper) gamma function

Dear all,

I'm using mpfr library via Rmpfr in R for few days. So tell me if I'm wrong, but it seems the incomplete (upper)
gamma function is not implemented in mpfr?

According to http://www.mpfr.org/mpfr-current/mpfr.html#Special-Functions, there is only gamma,
lgamma and polygamma functions. Is that correct?

Kind regards

Christophe

--
Christophe Dutang
Ph.D. student at ISFA, Lyon, France
website: http://dutangc.free.fr

"FAIL: tatan" still a problem in 3.0.1-p4

Tried it with -p3 and -p4.

CentOS 4.9
gmp 5.0.2
gcc 4.4.2 (used to compile, prepping for 4.4.6)

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz
stepping        : 7
cpu MHz         : 2392.319
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips        : 4787.05

-----

My MTA bounces all mail from all non-US non-CA
autonomous systems--sorry about that.

MPFR and mini-gmp

Hello,

over the last few weeks, I have been hacking on "mini-gmp", a small and
portable implementation of a subset of the GMP mpz and mpn interfaces.
The aim is to be small (say, mini-gmp.c of size comparable to the GMP
configure.ac  ), at most ten times slower than GMP for numbers of
size up to a few hundred bits, and fully source-level compatible with
GMP (for the subset implemented).

Some intended uses:

1. During the GMP build itself, replacing the current dumbmp.c when
   computing various tables early in the build process.

2. Use by any application which needs arithmetic on numbers larger than
   the computer word size, but which doesn't need high performance for
   realy large numbers.

3. For making the real GMP an *optional* dependency for packages which
   always need bignums but which may or may not need high performance
   for large numbers. A particular case is guile, which is intended to
   be useable as an extension language, and hence should be conservative
   with additonal dependencies.

   Such packages could use a configure test for the real GMP, and use
   mini-gmp as a fallback.

It would also be nice to not have GMP be a mandatory dependency for gcc.
To get there, one would need to be able to build mpfr (or a suitable
mpfr subset) using mini-gmp rather than the real thing.

Exact sampling from the normal distribution

RandomLib now contains a class ExactNormal which samples exactly from
the normal distribution with mean = 0 and variance = 1.  See

    http://randomlib.sf.net/html/classRandomLib_1_1ExactNormal.html

The definition of "exactly" is as follows:

    Given a source of perfectly random bits uniformly distributed, the
    algorithm with generate the initial portion of a random deviate.
    For example the result might be 1.10... (in binary notation); here
    the ... represents an infinite sequence of uniform distributed
    binary bits.  Thus 1.10... is equivalent to a random number sampled
    uniformly from the interval (1.5, 1.75) (in decimal notation).  The
    resulting deviates are sampled exactly from the normal distribution.

The algorithm only uses simple logical operations; it contains no
floating point arithmetic and there are no round-off errors.  The
algorithm is inspired by a similar one for sampling from the exponential
distribution due to von Neumann, J. Res. Nat. Bur. Stand.,
Appl. Math. Ser. 12, 36-38 (1951).  RandomLib contains a class
ExactExponential that implements this algorithm; see

    http://randomlib.sf.net/html/classRandomLib_1_1ExactExponential.html

These algorithms enable the implementation of exact mpfr sampling
functions which are equivalent to sampling a real number from the exact
distribution and rounding the result appropriately.  This is merely a
question of supplying sufficient additional random digits in place of
... so that the resulting interval can be unambiguously rounded.  The
asymptotic scaling of the algorithm is perfect.  The time to generate a

Ensuring reproducibility of extended calculations

solaris 10 sparc using solaris ld and solaris as problems

mpfr gurus

i've been trying to upgrade to newer gcc from old version shipped
as /usr/sfw/bin/gcc (gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath))

gmp 4.2.1 compiled long ago ok, but mpfr has always been troublesome ...

when trying to build gcc-4.4.6 i quickly found the need for mpfr along
with the instructions that a subdir containing mpfr in the gcc-4.4.6 tld
would configure the gcc build to build mpfr ... and that worked fine
for first stage of gcc.

   note that gcc-4.4.6 on sparc solaris 10 (not opensolaris) requires
   (and allows) the configuration of both the assembler (as) and linker (ld)
   to be the gnu versions at /usr/sfw/bin/gas and /usr/sfw/bin/gld respectively).

unfortunately, a subsequent stage failed to correctly locate mpfr.h (
it was never moved to the gcc-4.4.6 configure mfpr source dir) and
the gcc build fails ...

encouraged by the complete mpfr build i ran the mpfr tests and all but
one (iirc) passed, further encouraged by this i then attempted to independently
build/install mpfr (3.1.0).

i've not had any luck and am looking for suggestions, advice, assistance, whatever ...

current state:
 *  i have applied the 3.0.1 cumulative patches. but independent mpfr
    builds continue to fail as described below, the gcc-4.4.6 build has
    not been re-attempted with the patched mpfr yet ...

 *  if i run configure without any particular arguments gcc and libtool
    will use the solaris /usr/ccs/bin/ld and everything builds and links.
    but most tests core dump either seg-fault or bus-error. interestingly
    test/tversion works fine.
       note that for some reason /usr/local/include/libintl.h is being
       used rather than the solaris stock version at /usr/include/libintl.h.
       i haven't checked which intl library is being searched ... but this
       could very well be the cause of the cores.

 * if i specify --with-gnu-ld=no and set envvar LD to /usr/sfw/bin/gld
   the first (dynamic?) library link-edit fails
libtool: link: gcc -shared  -fPIC -DPIC  ... -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath
-Wl,/usr/local/lib /usr/local/lib/libgmp.so -lc -O2 -Wl,-soname -Wl,libmpfr.so.4 -o .libs/libmpfr.so.4.1.0
ld: warning: option -o appears more than once, first setting taken
ld: fatal: file /usr/local/lib: unknown file type
ld: fatal: File processing errors. No output written to .libs/libmpfr.so.4.1.0
collect2: ld returned 1 exit status
gmake[2]: *** [libmpfr.la] Error 1
gmake[2]: Leaving directory `/usr/local/src/mpfr-3.1.0/src'

some versions data:
%    libtool --version
libtool (GNU libtool) 2.4
%    uname -a
SunOS xxxx 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Blade-1000
%    gcc --version
gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
%    ld -V
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.482
%    as -V
as: Sun Compiler Common 10 Patch 05/06/2005

i've likely missed something important, let me know what and if rather
esoteric provide a clue or two on how to get it ...

thanks for any suggestions (short of booting a newer/different os)

aloha

ras

MPFR

Copyright (c) 2004 Julien Chapiseau

    Permission is hereby granted, free of charge, to any person  
obtaining a copy of this logo, to deal in the logo without  
restriction, including without limitation the rights to use, copy,  
modify, merge,
    publish, distribute, sublicense, and/or sell copies of the logo,  
and to permit persons to whom the logo is furnished to do so, subject  
to the following conditions:

    The above copyright notice and this permission notice shall be  
included in all copies or substantial portions of the logo.

	

    Julien Chapiseau

make check failed on mpfr-3.1.0+allpatches (2011/11/25) CentOS-5 x86_64

Hi,

I have a failed "make check" fir mfpr 3.1.0 + patches from
http://www.mpfr.org/mpfr-current/allpatches as of 2011/11/25

details:
[tru <at> liberte mpfr-3.1.0]$ rpm -q gmp gmp-devel gcc
gmp-4.1.4-10.el5.x86_64
gmp-4.1.4-10.el5.i386
gmp-devel-4.1.4-10.el5.i386
gmp-devel-4.1.4-10.el5.x86_64
gcc-4.1.2-51.el5.x86_64

last lines of make check:
  $ tar xjvf  ~/sources/mpfr-3.1.0.tar.bz2
  $ cd mpfr-3.1.0
  $ wget http://www.mpfr.org/mpfr-current/allpatches
  $ patch -N -Z -p1 < allpatches
  $ ./configure --prefix=/c5/shared/mpfr/3.1.0
  $ make && make check
...
PASS: tui_sub
Error in bug20100914, expected 0.8488312, got 6.485367e-1
FAIL: turandom
PASS: tvalist
PASS: ty0
PASS: ty1
PASS: tyn
PASS: tzeta
PASS: tzeta_ui
[tversion] GMP: header 4.1.4, library 4.1.4
[tversion] MPFR tuning parameters from default
PASS: tversion
=====================
2 of 160 tests failed
(1 test was not run)
=====================
make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory `/dev/shm/mpfr-3.1.0/tests'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/dev/shm/mpfr-3.1.0/tests'
make: *** [check-recursive] Error 1

Thanks

Tru
--

-- 
Dr Tru Huynh          | http://www.pasteur.fr/recherche/unites/Binfs/
mailto:tru@... | tel/fax +33 1 45 68 87 37/19
Institut Pasteur, 25-28 rue du Docteur Roux, 75724 Paris CEDEX 15 France  

set_str_raw.c:54: MPFR assertion failed: res == 0

On some 32 bit RedHat Linux systems, the mpfr-3.1.0-p3 make check fails in
"tatan" with that message.
It happened with gcc-4.6.2 under RH Linux 7.1, RH Linux 9, and CentOS 4.9 but
not under Fedora 14.
I had hoped that p3 would fix it.
William

problem with gcc flags when building mpfr

I build mpfr on a number of RedHat Linux systems.
The systems have RedHat's distributed gcc in /usr/bin and more recent gcc's
like gcc-4.6.2 in /usr/local/bin that I have built from source.
When I build gmp, mpfr and mpc, I run ./configure with
CC=/usr/local/bin/gcc-4.6.2.
gmp builds ok.
The configure scripts in mpfr and mpc, however, are cautious when CC is
redefined and don't take __GMP_CFLAGS from gmp.h.
I think that the test is wrong.
It should compare CC (or whatever it will eventually use if CC isn't set) with
__GMP_CC and use __GMP_CFLAGS only if they match.  For example, if gmp was
built with strange options (maybe as part of a cross-compile), but mpfr is
being built normally, it would be wrong for the mpfr build to use __GMP_CFLAGS
even if CC was not set.
I made the patch temporarily for my builds.
It shows the line that is causing me problems.
I realize that the test is required for cross-compiles and that configure is
generated from configure.ac.
If the test can't be changed, would it be possible to add a configure flag that
could be set to control whether the mpfr build uses __GMP_CFLAGS?

William

--- mpfr-3.1.0/configure-	2011-10-03 10:17:33.000000000 +0200
+++ mpfr-3.1.0/configure	2011-11-03 03:26:57.795207365 +0100
@@ -3441,9 +3441,9 @@

 

-if test -n "$CFLAGS" || test -n "$CC" ; then
- user_redefine_cc=yes
-fi
+#if test -n "$CFLAGS" || test -n "$CC" ; then
+# user_redefine_cc=yes
+#fi

 
 if test -z "$user_redefine_cc" && test "$cross_compiling" != yes ; then