gmane.comp.lib.mpfr.general

Re: [OT] Long double precision

2013-05-11T03:08:36


-----Original Message----- 
From: Vincent Lefevre


Aaah - this becomes evident if I look at the value of float.h's LDBL_DIG.

Thanks Vincent.

Cheers,
Rob

Re: [OT] Long double precision

Vincent Lefevre — 2013-05-10T20:05:26

Hi Rob,

On 2013-05-10 22:35:42 +1000, sisyphus1-sFbbPxZDHXw0n/F98K4Iww< at >public.gmane.org wrote:
[...]

The size is not necessarily meaningful for the precision.
If you get 8, you know that's double precision, but if you
get more, you can't deduce much from it.


Indeed, according to the formula, for precisions 19 (from .18Le) and
64 (assuming x87 extended precision), getting the original value is
not guaranteed.

[...]

On PowerPC, the long double format is different: it is the double double
arithmetic. You have a 106-bit precision, with additional non-FP values.
Hence the result.

[OT] Long double precision

2013-05-10T12:35:42

Hi,

This follows on from an old thread from early September 2012:
https://sympa.inria.fr/sympa/arc/mpfr/2012-09/msg00011.html

That thread in turn grew out of:
https://sympa.inria.fr/sympa/arc/mpfr/2012-09/msg00004.html

The demo script:

#########################
/*
   With MinGW ports of gcc we need to define
   __USE_MINGW_ANSI_STDIO in order to have
   access to the %Lf specifier
*/

#ifdef  __MINGW32__
#ifndef __USE_MINGW_ANSI_STDIO
#define __USE_MINGW_ANSI_STDIO 1
#endif
#endif

#include <stdio.h>
#include <stdlib.h>

int main(void) {
long double ld = 1e-37L;

printf("%d\n%.17Le\n%.18Le\n%.0Le\n", sizeof(long double), ld, ld, ld);

return 0;
}

#########################

On MS Windows, with the mingw.org port of (32-bit) gcc-4.7.0:
#########################
12
1.00000000000000000e-037
9.999999999999999999e-038
1e-037
#########################

On MS Windows, with the mingw64.sf port of (32-bit) gcc-4.6.3:
#########################
12
1.00000000000000000e-037
9.999999999999999999e-038
1e-037
##########

Re: Tests Fail

Vincent Lefevre — 2013-04-22T07:31:42

[...]

The errors seem to be related to flags / exceptions, where global
variables are involved. Without more information on how MPFR was
compiled, I suspect that this is due to TLS problems with the platform.
Please try to configure MPFR with the --disable-thread-safe option.

Re: Tests Fail

Zimmermann Paul — 2013-04-22T05:22:47

your report is useless as such. Please include the information requested at
http://www.mpfr.org/mpfr-current/mpfr.html#Reporting-Bugs

Did "make check" from GMP 5.1.1 succeed?

Best regards,
Paul Zimmermann

Tests Fail

2013-04-22T04:11:17

/bin/sh ../libtool --tag=CC    --mode=link gcc  -O3 -fomit-frame-pointer -pipe
-g0 -march=corei7 -mtune=corei7 -mwin32 -no-install -L../src/.libs  -Xlinker
--gc-sections -L/home/User/GNU/local/lib -o tzeta_ui.exe tzeta_ui.o
libfrtests.la -lm ../src/libmpfr.la -lgmp
libtool: link: warning: `-no-install' is ignored for i686-pc-mingw32
libtool: link: warning: assuming `-no-fast-install' instead
libtool: link: gcc -O3 -fomit-frame-pointer -pipe -g0 -march=corei7 -
mtune=corei7 -mwin32 -Wl,--gc-sections -o .libs/tzeta.exe tzeta.o  -L../
src/.libs -L/home/User/GNU/local/lib ./.libs/libfrtests.a ../src/.libs/
libmpfr.dll.a /home/User/GNU/local/lib/libgmp.dll.a -L/home/User/GNU/
mpfr-3.1.2/src/.libs -L/home/User/GNU/local/lib -L/home/User/GNU/local/lib
make  check-TESTS
make[2]: Entering directory `/home/User/GNU/mpfr-3.1.2/tests'
[tversion] GMP: header 5.1.1, library 5.1.1
[tversion] MPFR tuning parameters from default
PASS: tversion.exe
Bad return value (1 instead of 0) for:
mpfr_get_str failed in test_round_near_

Re: New Python bindings for MPFR

Vincent Lefevre — 2013-04-02T00:48:16

Thanks for the information. I didn't notice this change.
This is now done.

Re: New Python bindings for MPFR

Case Van Horsen — 2013-03-30T02:44:25

Could it be moved to the "Interfaces ..." section of the web page and
list that GMP, MPFR, and MPC are supported?

Regards,
Case

Re: New Python bindings for MPFR

Vincent Lefevre — 2013-03-30T02:33:29

OK, I've changed it to gmpy2.

Re: NARS2000 Uses MPFR

Vincent Lefevre — 2013-03-30T02:28:05

Done. Thanks,

Re: New Python bindings for MPFR

Mark Friedenbach — 2013-03-30T02:22:56

Case, thank you for your work on GMPY2. We use it for a particular
distributed financial application requiring deterministic floating point
arithmetic.

Vincent, GMPY2 is not compatible with GMPY, but is definitely preferred. We
wrote our application using gmpy, then upgraded to gmpy2 because of the
much cleaner interface, even though it was still alpha software at the
time. IMHO the web site should be updated to say "gmpy2" now that it is
officially release, since the user has to make a choice as to install gmpy
vs gmpy2.

Mark



On Fri, Mar 29, 2013 at 7:07 PM, Vincent Lefevre <vincent-buymaDBGzMOsTnJN9+BGXg< at >public.gmane.org> wrote:

Re: New Python bindings for MPFR

Vincent Lefevre — 2013-03-30T02:07:51

Hi,

On 2013-03-25 09:00:04 -0700, Case Van Horsen wrote:

Thanks for the information.


The MPFR manual doesn't contain references to any bindings (perhaps it
should, but this is currently not the case).

A reference to GMPY (with the correct URL) is already given on the
main MPFR web page as:

  The Python bindings for GMP (gmpy).

I'd say that "gmpy" means here any version, but if you would like
another formulation, please tell us.

Regards,

Re: MPFR fails to build with (really) old versions of Makeinfo

Vincent Lefevre — 2013-03-30T02:00:00

Hi,

On 2013-03-29 19:02:21 +0100, flori-jpENlDPnyY8< at >public.gmane.org wrote:

Well, the --enable-encoding option was added in makeinfo 4.1,
released on 4 March 2002. So, this means that the installed
makeinfo is more than 11 years old!

Note that according to the texinfo NEWS file, the --enable-encoding
option is no longer needed since version 4.11, released on 9 September
2007. But if some user has makeinfo between 4.1 and 4.10, the info
file would not really be correct. Though it is quite old, I think
that it is much more probable to be affected by such a version than
with makeinfo 4.0. Moreover there may be other problems with texinfo
less than 4.2, as < at >copying is not supported, and the doc/README.dev
says:

  To generate mpfr.info, you need texinfo version 4.2 (or higher).

Also, if the user builds MPFR from the tarball, makeinfo is not
necessary (since the info file is provided).

So, I think that we should not change anything.

Regards,

MPFR fails to build with (really) old versions of Makeinfo

2013-03-29T18:02:21

Dear all,

It seems MPFR configures fine when makeinfo is not present but if by any
chance you have a really old version which does not support "--enable-
encoding" lurking in your PATH, then the configure step will fail.

This was reported ages ago here:
https://groups.google.com/d/msg/sage-support/lNp5t-vbT9c/yTHo9Bl1vdAJ
but I also encountered this problem recently on some machine I'm not admin of.
Fortunately, there was another more recent version of makeinfo later in PATH
and I could modify PATH so that it was picked first.

Don't feel obliged to do anything about that as the right solution is to
update makeinfo, but it may be quite difficult sometimes without admin rights
or whatever.
For example if some other binaries are in the same directory as the old
makeinfo and you don't have any right on this dir (ok, then you could compile
your own makeinfo and put it in PATH first, or just modify MPFR yourself...).

Best,
JP

NARS2000 Uses MPFR

Bob Smith — 2013-03-29T14:39:11

NARS2000 is an Experimental APL Interpreter released under GPLv3 that 
has datatypes for multi-precision floating point numbers (via MPFR) as 
well as multi-precision rational numbers (via MPIR).

For more details about our use of multi-precision numbers, see

http://wiki.nars2000.org/index.php?title=Rational_and_VFP_Numbers

For more details about the overall project, see

http://www.nars2000.org/

I would appreciate it if you would include a reference to this project 
as using your excellent library.

New Python bindings for MPFR

Case Van Horsen — 2013-03-25T16:00:04

Hi,

I'd like to announce the release of GMPY2 2.0.0 - a Python wrapper for
GMP, MPFR, and MPC.

The home page is:

https://code.google.com/p/gmpy/

Can the MPFR documentation be updated to include a reference to GMPY2?

Thanks for developing MPFR!

Regards,
Case Van Horsen

Re: mpfr-3.1.2 on Solaris 10 Sparc 19 of 160 tests failed

Dennis Clarke — 2013-03-25T12:36:56


Since gmp can only be built on Solaris with gcc I have usually setup both
CC and CFLAGS manually and then used Sun/Oracle Studio compilers with
mpfr and pretty much everything else. If I do not specify CC or CFLAGS
then mpfr will follow along behind gmp with the same compiler and flags. 

Sort of makes me wonder if the binaries produced by Oracle Studio 12.3 are 
in any measurable or qualitative way "better" than those produced by gcc?

That is a whole other mess of fish I could not be bothered with right now. I
do know that I have email the Studio/Compiler tools folks inside Sun/Oracle 
more than a few times over the years about libgmp.  Never did get very far
with that. 

Moving on .. nothing to see here. All is well.

Thank you, 
Dennis

Re: mpfr-3.1.2 on Solaris 10 Sparc 19 of 160 tests failed

Zimmermann Paul — 2013-03-25T11:51:49

       Dennis,


this explains your problem. If CC or CFLAGS is given to the configure script
(or in the user environment) then MPFR will use it, and not try to get CC and
CFLAGS from gmp.h. In that case it is the user responsibility to provide valid
values, which are compatible with the GMP setup.

Except needed, it is recommended to *not* define CC nor CFLAGS.

Best regards,
Paul

Re: mpfr-3.1.2 on Solaris 10 Sparc 19 of 160 tests failed

Dennis Clarke — 2013-03-25T11:36:17


----- Original Message -----
From: Zimmermann Paul <Paul.Zimmermann-MZpvjPyXg2s< at >public.gmane.org>
Date: Monday, March 25, 2013 5:28 am
Subject: Re: [MPFR] mpfr-3.1.2 on Solaris 10 Sparc 19 of 160 tests failed
To: Dennis Clarke <dclarke-W8DytltYgt3NLxjTenLetw< at >public.gmane.org>
Cc: mpfr-MZpvjPyXg2s< at >public.gmane.org



should be .. yes.


Well, let's take a look in /usr/local/build : 

bash-4.2$ ls -loptrb | grep mpfr 
drwxr-xr-x   9 dclarke       33 Jul  3  2012 mpfr-3.1.1.src/
drwxr-xr-x   9 dclarke       37 Oct 29 01:55 mpfr-3.1.1_sparcv9_001/
-rw-r--r--   1 dclarke     8361 Oct 29 02:21 mpfr-3.1.1_sparcv9_001.README
-rw-r--r--   1 dclarke     3126 Oct 29 02:21 mpfr-3.1.1_sparcv9_001.env
drwxr-xr-x   5 dclarke        9 Oct 29 02:22 mpfr-3.1.1_sparcv9_001.pkg/
-rw-r--r--   1 dclarke     2707 Nov 12 02:55 mpfr-3.1.1_SunOS5.10_sparcv9-for-gcc-4.7.2.env
drwxr-xr-x   2 dclarke        2 Nov 12 03:13 mpfr-3.1.1_SunOS5.10_sparcv9-for-gcc-4.7.2/
-rw-r--r--   1 dclarke     2645 Mar 23 05:03 mpfr-3.1.2_SunOS5.10_spar

Re: mpfr-3.1.2 on Solaris 10 Sparc 19 of 160 tests failed

Zimmermann Paul — 2013-03-25T09:27:57

       Dennis,


is it the config.log file of the run which failed?

What is strange is that there is no line like:

configure:3475: checking for CC and CFLAGS in gmp.h

Do you have CC or CFLAGS set in your environment?

Paul Zimmermann

Re: mpfr-3.1.2 on Solaris 10 Sparc 19 of 160 tests failed

Vincent Lefevre — 2013-03-25T00:27:50

So, one can assume that the TLS implementation on your platform is
correct.


So, the problem is related to the new configure line. But since the
compiler is completely different (GCC instead of Oracle Studio),
this may be the cause of the problems (quite often, the culprit is
the compiler).


If several tests fail, in particular with a segmentation fault, the
problems may come from buggy TLS support of the system and/or the
compiler (several bugs are known). So, it is worth trying. A part of
the TLS support is implemented by the compiler, and we don't know if
it is working.

Regards,