http://blog.gmane.org/gmane.comp.lib.mpfr.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.lib.mpfr.general/1651 <pre>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. </pre> Pavel Holoborodko 2012-05-18T11:20:11 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1647 <pre>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</pre> vk-ip8hFmXdfkpIrkc2zG8k/Q< at >public.gmane.org 2012-05-16T22:53:10 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1642 <pre> Attached patch fixes build of mpfr with automake 1.12 </pre> Nitin A Kamble 2012-05-08T17:12:14 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1641 <pre>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. </pre> Vincent Lefevre 2012-05-07T21:31:10 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1637 <pre>I all mpfr_get_flt to process for overflow, denormal, &amp;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. </pre> John P. Hartmann 2012-05-03T14:27:07 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1633 <pre>This example seems to round towards infinity regardless of sign. That is, the result is correct, when compared to IBM's HLASM, for a positive decimal value, but not for a negative one. The numbers are hexadecimal floating point. Precision in this case is 21 bits. - 000001F0 C612D684 155 dc eh'-1234564.51r6' + 000001F0 C612D685 155 dc eh'-1234564.51r6' I checked the round raw generic function and it does not to test for MPFR_RNDU (or MPFR_RNDD), but something it call might well do. (But my test cases for rounding mode 7 [MPFR_RNDD] pass.) I use mpfr_strtofr() to convert and round. I can supply trace data if desired. More failing tests: 236c236 &lt; 000001C8 C612D684 145 dc eh'-1234564.01r6' --- 241c241 &lt; 000001DC C612D684 150 dc eh'-1234564.50r6' --- 246c246 &lt; 000001F0 C612D684 155 dc eh'-1234564.51r6' --- 256c256 &lt; 00000218 C612D685 </pre> John P. Hartmann 2012-05-02T14:05:22 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1627 <pre>Hello, I'm cross building mpfr-3.1.0-p9 (all patches applied) in 32 bits on an amd64 machine. Configure line: CC="gcc -m32" CXX="g++ -m32" ./configure --prefix=/usr \ --enable-shared --libdir=/usr/lib32 ABI=32 gcc version 4.6.3 (Debian 4.6.3-4). I have GMP installed from the debian packages (version 2:5.0.4+dfsg-1). "make" builds fine, "make check" tests fine until tgamma which is stuck forever. There is no such problem when trying the unpatched version, or just building the 64 bits version with "./configure &amp;&amp; make &amp;&amp; make check". config.log attached. Laurent. </pre> Laurent Fousse 2012-04-28T21:04:37 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1623 <pre>I just installed mpfr-devel-2.4.1-6.el6.x86_64 on a CentOS system. mpfr_get_flt used to return a float, just as mpfr_get_d returns a double. Truncating a double to float is not always exact, right? Any suggestions for a workaround? (Or is this just a case of a missing declaration in the h file?) </pre> John P. Hartmann 2012-04-27T13:52:29 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1619 <pre>Hi, I'm trying to emulate binary64 while calculating mpfr_gamma. I did something like below mpfr_init2(xa,53); mpfr_init2(xb,53); // set value of xb using mpfr_set_d(xb, -168.5, MPFR_RNDN); mpfr_set_emin (-1073); mpfr_set_emax (1024); i = mpfr_gamma (xa, xb, MPFR_RNDN); i = mpfr_subnormalize (xa, i, MPFR_RNDN); /* new ternary value */ when xb = -168.5 I'm getting -0.0 as result where as the actual result should be close to -9.57373... × 10^-304 http://www.wolframalpha.com/input/?i=gamma(-168.5) Is there a problem with what I'm doing? or is there a problem with mpfr_gamma() I'm using mpfr3.1.0 Please help on this. Thank you. Regards, Giridhar </pre> Giridhar Tammana 2012-04-26T15:07:45 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1617 <pre>After some discussion with Paul, I've implemented operations on groups of flags in a MPFR flags branch. This is a bit like what the IEEE 754-2008 and ISO C99 standards specify. Before I reintegrate this feature in the trunk, are there any comments? I've attached the corresponding patch generated from the merge. </pre> Vincent Lefevre 2012-04-26T11:38:47 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1616 <pre> Hi, on Thursday May 3, from 9:30 AM to about 11:30 AM (CEST), the mpfr-/zGXu1G9BXs&lt; at &gt;public.gmane.org list will be temporarily unavailable. Messages posted to the list will be queued and transmitted afterwards. After the move, the archives will still be available, but probably at a different address. The same will hold for the mpfr-announce mailing list, but I don't think any announce will be posted during those two hours :-) There are currently 115 subscribers on mpfr-/zGXu1G9BXvhvxM+mQhndA&lt; at &gt;public.gmane.org We thank all subscribers for keeping the high quality of this list. Best regards, Paul Zimmermann (acting as list administrator) </pre> Zimmermann Paul 2012-04-25T13:32:12 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1614 <pre>There's a problem with huge macro expansions in assertions, which currently occurs in the trunk: when the checked expression is stringized in the ASSERT_FAIL macro, one can get a large string, whose size may be longer than the ISO C90 string length limitation (509 characters). For instance, in ai.c: wprec = MPFR_ADD_PREC (prec, MPFR_INT_CEIL_LOG2 (prec) + 5 + cond + assumed_exponent); where #define MPFR_ADD_PREC(P,X) \ (MPFR_ASSERTN ((X) &lt;= MPFR_PREC_MAX - (P)), (P) + (X)) and for GCC (even when using "-ansi -pedantic-errors"): # define MPFR_INT_CEIL_LOG2(x) \ (MPFR_UNLIKELY ((x) == 1) ? 0 : \ __extension__ ({ int _b; mp_limb_t _limb; \ MPFR_ASSERTN ((x) &gt; 1); \ _limb = (x) - 1; \ MPFR_ASSERTN (_limb == (x) - 1); \ count_leading_zeros (_b, _limb); \ (GMP_NUMB_BITS - _b); })) Un</pre> Vincent Lefevre 2012-04-23T12:43:52 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1609 <pre>Hello. I wonder if there is a easy way to generate C code from an given arithmetic expression that uses MPFR-calls for each operation? For example, I have text like "(a*b-c*cos(d+e)/2)". Is there any automated way to transform such expressions into, at least a valid series, of MPFR-calls? Best Regards Robin Geyer </pre> robin.geyer-AK4bM3bY4sL4ajHJ1XSv27NAH6kLmebB< at >public.gmane.org 2012-04-23T10:08:40 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1608 <pre>Following the success of the 2011 meeting, we plan to hold another joint Mpfr/Mpc developer meeting. Date 25 June 2012, 14:00 to 27 June 2012, 12:00 Venue Institut de Mathématiques de Bordeaux, University of Bordeaux, France The goal of this meeting is to discuss future developments of the Gnu Mpfr and Gnu Mpc libraries. It is open to everyone interested in contributing to Gnu Mpfr and/or Gnu Mpc, be it by writing new code or by contributing new ideas. There is no registration fee, but please inform andreas.enge-MZpvjPyXg2s&lt; at &gt;public.gmane.org if you intend to participate, and indicate whether you agree that your name be mentioned on our website. If you are unable to come, but wish to contribute ideas or suggestions for topics we should treat, please feel free to voice them on our mailing list. Some travel support will be available upon request. More details to come at http://www.multiprecision.org/index.php?prog=mpc&amp;page=workshop2012 Andreas </pre> Andreas Enge 2012-04-19T15:11:18 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1606 <pre>Hi, I'm trying to use mpfr on ARM platform. I could get mpfr 3.0 but I need 3.1. How can I build mpfr (cross compile) for ARM platform? I tried building from svn://scm.gforge.inria.fr/svn/mpfr/branches/3.1 but there is no configure script. Please guide me how can I build for ARM platform? Regards, Giri </pre> giridhar.t-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org 2012-04-10T15:18:08 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1600 <pre>Hi there, I am new to MPFR and probably someone came up with the following issue. I am currently defining and using without problems this: int N = 1024, M=1024; mpfr_t matrix[N][M]; for(int r=0; r&lt;N; r++) for(int c=0; c&lt;M; c++) mpfr_init(matrix[r][c]); and was wondering which is the correct way of defining an equivalent using malloc. For instance, i tried with: mpfr_t** matrix = (mpfr_t**)malloc(sizeof(mpfr_t*) * N); for(int i=0; i&lt;N; i++) matrix[i] = (mpfr_t*)malloc(sizeof(mpfr_t) * M); for(int r=0; r&lt;N; r++) for(int c=0; c&lt;M; c++) mpfr_init(matrix[r][c]); which compiles errors free. However, the algorithm does not work as with first definition. Definitely, there is a mistake when using mallocs here. Since mpfr_t is a hidden type, i am stuck on this. Any help out there will be much appreciated. Thanks in advance. g </pre> German 2012-03-24T00:10:07 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1596 <pre>When building outside srcdir the tfpif test fails. Andreas. [tests/Makefile.am] Define SRCDIR as "$(srcdir)" [tests/tfpif.c] Use it to find input file --- tests/Makefile.am | 2 ++ tests/tfpif.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index 4ca3e2f..c7dab0c 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am &lt; at &gt;&lt; at &gt; -40,6 +40,8 &lt; at &gt;&lt; at &gt; check_PROGRAMS = tversion tinternals tinits tisqrt tsgn tcheck \ ttanh ttrunc tui_div tui_pow tui_sub turandom \ tvalist ty0 ty1 tyn tzeta tzeta_ui tversion +AM_CPPFLAGS = -DSRCDIR='"$(srcdir)"' + EXTRA_DIST = tgeneric.c tgeneric_ui.c mpf_compat.h inp_str.data tmul.dat \ mpfrtest.dat diff --git a/tests/tfpif.c b/tests/tfpif.c index 60118f8..1f41833 100644 --- a/tests/tfpif.c +++ b/tests/tfpif.c &lt; at &gt;&lt; at &gt; -23,7 +23,7 &lt; at &gt;&lt; at &gt; http://www.gnu.org/licenses/ or write to the Free Software Foundation, Inc., #include "mpfr-test.h" #define FILE_NAME_RW "mpfrtest.txt" /* temporary name (written t</pre> Andreas Schwab 2012-03-20T12:33:45 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1595 <pre>This patch adds the function mpfr_fmod2 which is like mpfr_fmod, but also returns the low bits of the quotient. Background: I have written an emulation for the MC68882 FPU (as part of ARAnyM, see &lt;http://aranym.org&gt;) using mpfr as the backend. The MC68882 insn FMOD computes the modulo remainder in RZ mode and also returns the low 7 bits of the quotient. In order to emulate this insn I had to reimplement the internal function mpfr_rem1, since mpfr_fmod discards the quotient value. The mpfr_fmod2 function would make that unnecessary. Andreas. [src/rem1.c,src/mpfr.h] Add mpfr_fmod2 [doc/mpfr.texi] Document it --- doc/mpfr.texi | 7 ++++--- src/mpfr.h | 2 ++ src/rem1.c | 9 ++++++++- 3 files changed, 14 insertions(+), 4 deletions(-) diff --git a/doc/mpfr.texi b/doc/mpfr.texi index 619b53d..4ff6ed8 100644 --- a/doc/mpfr.texi +++ b/doc/mpfr.texi &lt; at &gt;&lt; at &gt; -2525,13 +2525,14 &lt; at &gt;&lt; at &gt; corresponding precision of &lt; at &gt;var{iop} and &lt; at &gt;var{fop} (equivalent to &lt; at &gt;end deftypefun &lt; at &gt;deftypefun int mpfr_fmod (mpfr_t &lt; at &gt;v</pre> Andreas Schwab 2012-03-20T11:51:06 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1592 <pre>Hi, I am trying to build MPFR 3.1.0 so that I can build a newer version of gcc. I am getting an error in the tests when doing a make check. Any help would be appreciated. $ ./configure checking for a BSD-compatible install... ./install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking whether to disable maintainer-specific portions of Makefiles... yes checking build system type... powerpc-ibm-aix7.1.0.0 checking host system type... powerpc-ibm-aix7.1.0.0 checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for a sed that does not truncate output... /usr/bin/sed checking for CC and CFLAGS in gmp.h... yes CC=/usr/vacpp/bin/xlc_r -O2 CFLAGS=-O2 checking for CC=/usr/vacpp/bin/xlc_r -O2 and CFLAGS=-O2... yes checking for gcc... /usr/vacpp/bin/xlc_r -O2 checking wh</pre> timothy.grunewald-qs4m+OjfQoH+fug3k4jHmNBPR1lH4CV8< at >public.gmane.org 2012-03-07T16:47:30 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1579 <pre>Hi, I've been trying to build an Android NDK with a fresher toolchain, and I tried to use the latest mpfr release for that. The build was failing during mpc linkage because libmpfr.lai had broken dependency_libs, which, in turn, seems due to libtool (using a different libtool script did create a non broken libmpfr.lai). Cheers, Mike </pre> Mike Hommey 2012-03-05T12:19:39 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1575 <pre>Hi, I experience a problem with mpfr_exp(rop,op,MPFR_RNDU). Typically mpfr_exp() gets the desired result within milli-seconds which is great! But if the result is a (positive) integer power of 2 then mpfr_exp() can hang for a long time, before coming up with the correct answer. For instance, computing mpfr_exp(rop,op,MPFR_RNDU) at 10000 digits of precision with op set to the value of log(17) is done instantaneously, but with op set to the value of log(16) it takes more than a minute on my 2.6 GHz machine. As a test case you may run the program 'mpfr_exp-timings.c' given below and see whether you can reproduce the results listed below. Best wishes, Holger $ cat mpfr_exp-timings.c #include&lt;stdio.h&gt; #include&lt;time.h&gt; #include&lt;gmp.h&gt; #include&lt;mpfr.h&gt; int main() { unsigned long i; double t; time_t t1,t2; mpfr_t op,rop; printf("GMP version %s\n",gmp_version); printf("MPFR version %s\n",mpfr_get_version()); printf("Some timings for mpfr_exp(rop,op,MPFR_RNDU):\n"); mpfr_init</pre> Holger Then 2012-03-02T16:42:00 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.mpfr.general