gmane.comp.lib.mpfr.general

Re: Quadruple precision converters mpfr_set_float128 and mpfr_get_float128

Pavel Holoborodko — 2012-05-18T12:19:49

Ah, I see, now it is clear. Thank you for the help!

Re: Quadruple precision converters mpfr_set_float128 and mpfr_get_float128

Vincent Lefevre — 2012-05-18T12:12:18

For the mpfr_t to __float128 conversion, yes, but one also needs
to reduce the exponent range, and to call mpfr_subnormalize.

For the __float128 to mpfr_t conversion, one needs mpfr_prec_round
with the target precision.

Re: Quadruple precision converters mpfr_set_float128 and mpfr_get_float128

Pavel Holoborodko — 2012-05-18T12:03:28

Thank you for your quick reply.




Basically this means we just have to add mpfr_prec_round(..,113,..) before
conversion to __float128 ?

Thanks,
Pavel Holoborodko.

Re: Quadruple precision converters mpfr_set_float128 and mpfr_get_float128

Vincent Lefevre — 2012-05-18T11:47:46

Thanks for the information. I've looked at the code

  http://gcc.gnu.org/ml/fortran/2011-02/msg00218/quad-mpfr.h

but it seems to assume that mpfr_t numbers have a 113-bit precision
like __float128 (thus with no rounding), probably because this is
the case with the numbers in gfortran.

It also uses C99 types, while we require MPFR to be C90-compatible.
Now, this isn't necessarily a problem here, because __float128 support
would be optional, and C implementations with __float128 support may
provide the C99 types (to be confirmed...).

Quadruple precision converters mpfr_set_float128 and mpfr_get_float128

Pavel Holoborodko — 2012-05-18T11:20:11

There is a growing interest for implementation of mpfr_t to __float128
converters.

This topic was discussed before:
http://comments.gmane.org/gmane.comp.lib.mpfr.general/764
And it is one of the questions for MPFR Workshop 2012.

I am not sure if this was already discussed but there are  mpfr_t to
__float128 converters created by libquadmath (__float128) developers
available here:
http://gcc.gnu.org/ml/fortran/2011-02/msg00218.html

I have no idea about the quality of the code, maybe it can be used until
final implementation in MPFR (or at least considered as a starting point).

It would be very helpful, if someone knowledgeable could provide feedback
for the code - is there are any obvious/hidden problems, suggestions for
improvement, etc.

Pavel Holoborodko.

Re: Re: mpfr_const_ problem

Vincent Lefevre — 2012-05-17T17:11:03

Great.


MPFR should normally use the same compiler as GMP, but the port may
override it if it sets CC or CFLAGS.

There are known problems with clang, so that failures are not
surprising with it.

Re: Re: mpfr_const_ problem

2012-05-17T14:11:59

Thanks for your help. Meanwhile the port works.

--disable-thread-safe was already on. I don't know what the problem was. The
MPFR configure CC= by default uses clang on this machine, whereas GMP always
uses gcc.

./configure --disable-shared --disable-thread-safe CC=/usr/bin/gcc CFLAGS=-O0
-g
works well.

Thanks again, vk

Re: mpfr_const_ problem

Vincent Lefevre — 2012-05-16T23:44:14

Hi,

On 2012-05-17 00:53:10 +0200, vk-ip8hFmXdfkpIrkc2zG8k/Q< at >public.gmane.org wrote:
[...]

I would say probably a bug in the compiler (or somewhere in the
system). Various such bugs are in the TLS support. In case MPFR
was built with TLS, you can explicitly disable it by giving the
--disable-thread-safe option when running the configure script.
If this doesn't solve the problem, you can try the -O0 compiler
option to disable optimizations, as they are also bugs related
to the optimizations.

If the problem still occurs with -O0, you can try to see what happens
with gdb.

I don't suggest logging, as it not supported on Mac OS X (it needs
GNU libc).

If this is a bug in the compiler, the best solution would be to use
another compiler (e.g. official instead of Apple's, more recent...).

mpfr_const_ problem

2012-05-16T22:53:10

Hi

I'm using the MPFR on a Mac PPC platform (OSX 10.4) and everything works well.

Now I'm trying to port the application to a Mac Intel platform (OSX 10.7.3)
and the "mpfr_const_" functions fail.

A simple test program for mpfr_const_euler() and mpfr_const_pi() on the PPC
machine gives correct results like:

Last login: Wed May 16 23:32:01 on ttyp1
Welcome to Darwin!
84-75-166-14:~ vk$ cc -o tconst ~/Desktop/tconst.c -lmpfr -lgmp
84-75-166-14:~ vk$ ~/tconst
GMP version 5.0.4
MPFR version 3.1.0-p10

gamma at 32 =        5.7721566479e-01
cached gamma at 32 = 5.7721566479e-01

pi at 32 =        3.1415926535e+00
cached pi at 32 = 3.1415926535e+00

gamma at 66 =        5.77215664901532860603e-01
cached gamma at 66 = 5.77215664901532860603e-01

pi at 66 =        3.14159265358979323846e+00
cached pi at 66 = 3.14159265358979323846e+00

gamma at 100 =        5.7721566490153286060651209008234e-01
cached gamma at 100 = 5.7721566490153286060651209008234e-01

pi at 100 =        3.1415926535897932384626433832793e+00
cac

Re: MPFR internals: huge macro expansions in assertions

Patrick Pelissier — 2012-05-13T10:10:24

 As far as I know, GMP still needs only a C89 compiler: if inline is not
 available, a work around is used by GMP configure.

--
 Patrick Pélissier

Re: MPFR internals: huge macro expansions in assertions

Marc Glisse — 2012-05-12T17:42:43


As long as mpfr depends on gmp, there is little point being more strict 
than gmp...

Re: MPFR internals: huge macro expansions in assertions

Patrick Pelissier — 2012-05-12T15:51:39

My comments:
 I think it will be better to keep strict C89 compatibility. I don't
see any reason (except laziness) for not doing so.
 I haven't seen any compiler which doesn't support string bigger than 509.
 The string itself is not really needed since we have the file name
and the line number of the failure: we can get the error with these
information.So maybe adding a configure option to check the string
limitation of the system, and if it is not enough (4095 ?), set a flag
for not embedding and not displaying theses strings in MPFR library.
 The C99 limit is 4095. Does MPFR exceed such limit?

--
 Patrick Pélissier

On Mon, Apr 23, 2012 at 2:43 PM, Vincent Lefevre <vincent-buymaDBGzMOsTnJN9+BGXg< at >public.gmane.org> wrote:

Re: fix build of mpfr with automake 1.12

Zimmermann Paul — 2012-05-08T19:10:33

       Dear Nitin,


thanks. Applied to the trunk.

Best regards,
Paul Zimmermann

fix build of mpfr with automake 1.12

Nitin A Kamble — 2012-05-08T17:12:14

Attached patch fixes build of mpfr with automake 1.12

Patch 10 for GNU MPFR 3.1.0 is available

Vincent Lefevre — 2012-05-07T21:31:10

Patch 10 for GNU MPFR 3.1.0 is available on the MPFR web site:

  http://www.mpfr.org/mpfr-3.1.0/#bugs

It fixes the mpfr_gamma function around the overflow/underflow
thresholds in the extended exponent range. Without this patch,
MPFR can freeze on some particular inputs of mpfr_gamma.

Re: mpfr_get_flt question

Vincent Lefevre — 2012-05-03T17:45:05

Sorry, this is normal, as mpfr_get_flt() returns a float, not a mpfr_t
number. In this case, we should raise the overflow flag with the C99+
function feraiseexcept(), when supported, but this is not currently
done.

Re: mpfr_get_flt question

John P. Hartmann — 2012-05-03T15:44:49

As always, you read my mind!

Doesn't look like mpfr_get_flt() sets the overflow flag when it stores
the infinite value.  At least mpfr_overflow_p() returns 0.  However,
testing the exponent for max value is good enough for me.

On 3 May 2012 17:11, Vincent Lefevre <vincent-buymaDBGzMOsTnJN9+BGXg< at >public.gmane.org> wrote:

Re: mpfr_get_flt question

Vincent Lefevre — 2012-05-03T15:11:08

If I understand correctly, you get the maximum finite representable
number (encoded 0x7f7fffff) instead of the positive infinity (encoded
0x7f800000). If you used rounding toward zero, then yes, this is
intentional, as the rounding of 0.53976e40 toward zero is the largest
number <= 0.53976e40, thus the maximum finite representable number.

If the goal is to check overflow in this rounding mode, you should
test the overflow flag (you may need to clear it before the call,
as it is sticky).

mpfr_get_flt question

John P. Hartmann — 2012-05-03T14:27:07

I all mpfr_get_flt to process for overflow, denormal, &c; the number
is already rounded and I don't wish any further rounding.

So I decided to specify round to zero rather than the rounding mode
already employed in conversion, but this changed the value stored on
overflow to be 0x7f7fffff rather than 7f800000, which I get with round
to nearest.  Is this intentional?

The number in question is 0.53976e40, which has an exponent of 132,
quite way off the scale.

Re: What happened to mpfr_get_flt

Vincent Lefevre — 2012-05-02T16:08:45

Thanks. I've added the reference to the TODO. I hope that we will
discuss about it during our meeting in June.

Re: Rounding to plus infinity for negative numbers (MPFR_RNDU)

John P. Hartmann — 2012-05-02T14:49:22

I take that back about MPFR_RNDU; I had missed the sign.  So MPFR_RNDU
does what I expect (or want), but I get differences with truncate and
round to -Inf for negative numbers.  The part of the program that uses
mpfr is just:

         mpfr_set_prec(fp, nprec);
         rv1 = mpfr_strtofr(fp, bfr, NULL, 10, round);
         rv = mpfr_subnormalize(fp, rv1, round);

Looking at the raw rounding code, it looks like it tests for MPFR_RNDN
and MPFR_RNDZ and assumes away for the rest, but I haven't completely
grokked the rounding mode macros from line 819 of mpfr_impl.h.

I'll do my homework and then report back.  One hopes with egg on my face.