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/709 <pre>I've been trying to download MPFR 2.4.2 but am not getting through to the site http://www.mpfr.org/. Is there a problem with the site and is there another place where I can download this? Regards Chris Saunders</pre> Chris Saunders 2010-03-14T22:32:52 http://comments.gmane.org/gmane.comp.lib.mpfr.general/708 <pre>I had downloaded MPFR 2.4.2 a few days ago and was having some problems. I decided to delete it and try again and now I find that I cannot access the site http://www.mpfr.org/mpfr-current/ or even http://www.mpfr.org/. I have been having this problem for a couple of days now and am wondering if anyone knows what the problem is? Regards Chris Saunders</pre> Chris Saunders 2010-03-15T08:12:46 http://comments.gmane.org/gmane.comp.lib.mpfr.general/704 <pre>I had asked about this problem before and did receive some help. I became too busy with other things and was unable to continue to pursue the problem. I have time again to work on my Eiffel interface to GMP, MPFR and MPC so I'm asking about this problem again. I just tried to configure MPFR using MSYS on Windows 7. I configured GMP using "./configure --disable-static --disable-alloca ABI=32" and configured MPFR with "./configure --with-gmp-build=/home/chris/gmp-5.0.1". At the end of configure for MPFR I get this message: checking for valid BITS_PER_MP_LIMB and BYTES_PER_MP_LIMB... no configure: error: BITS_PER_MP_LIMB or BYTES_PER_MP_LIMB are incorrect. You probably need to change some of the GMP or MPFR compile options I was hoping this might have been resolved by now but apparently not. Any ideas on how to resolve this:? Regards Chris Saunders</pre> Chris Saunders 2010-03-13T07:14:15 http://comments.gmane.org/gmane.comp.lib.mpfr.general/703 <pre>Due to the INRIAGforge upgrade, the existing links to the MPFR repository (e.g. from the MPFR web pages) are now invalid. I've reported a bug to the INRIAGforge admins[*]. I'm waiting for an answer before changing anything. Note: some other users have reported similar problems. [*] https://gforge.inria.fr/tracker/index.php?func=detail&amp;aid=9799&amp;group_id=1&amp;atid=110 </pre> Vincent Lefevre 2010-03-11T12:50:37 http://comments.gmane.org/gmane.comp.lib.mpfr.general/700 <pre>In tsqrt.c, test_property1() claims with a comment (line 497): /* check that -1 &lt;= x/sqrt(x^2+y^2) &lt;= 1 for rounding to nearest or up */ However, the code neglects to use y (except to increment the random number generator): 508 mpfr_urandomb (x, RANDS); 509 mpfr_urandomb (y, RANDS); 510 mpfr_mul (z, x, x, r); 511 mpfr_mul (t, x, x, r); 512 mpfr_add (z, z, t, r); 513 mpfr_sqrt (z, z, r); 514 mpfr_div (z, x, z, r); I think that line 511 is meant to read mpfr_mul(t, y, y, r); Aside: I am only looking at this code in trying to adopt tests for the Ruby bindings for MPFR. </pre> Sam Rawlins 2010-03-10T02:18:18 http://comments.gmane.org/gmane.comp.lib.mpfr.general/696 <pre></pre> Shelley Nation 2010-03-03T04:36:37 http://comments.gmane.org/gmane.comp.lib.mpfr.general/695 <pre>INRIAGforge, which hosts the MPFR repository, will be updated on March 8: https://gforge.inria.fr/forum/forum.php?forum_id=7388 In short, due to this migration, the web pages on INRIAGforge will be unavailable on March 8 from 13:30 to 16:30 CET (12:30 to 15:30 UTC), and access to the Subversion repository will be unavailable from 16:30 to 17:30 CET (15:30 to 16:30 UTC). The MPFR web site www.mpfr.org and mailing-list are not hosted on INRIAGforge, thus will not be affected. Regards, </pre> Vincent Lefevre 2010-03-02T08:32:10 http://comments.gmane.org/gmane.comp.lib.mpfr.general/692 <pre>Hi, I recently installed the mpfr2.4.2 package from the source code.everything while compiling and installing mpfr went well,but after the installation, the libmpfr.so.1 link directing to libmpfr.so.1.2.2 is broken. so every other software which uses libmpfr.so.1 to compile, fails. I also tried recompiling and installing it,but didn't help. Is there any fix for this problem. Thanks in advance. </pre> sirish s 2010-03-01T13:09:00 http://comments.gmane.org/gmane.comp.lib.mpfr.general/691 <pre>As part of the task https://gforge.inria.fr/pm/task.php?func=detailtask&amp;project_task_id=3965&amp;group_id=136&amp;group_project_id=279 I tried to modify the MPFR configure script to reliably recognize long double on PowerPC (with tests on my Mac OS X 10.4.11 machine), which is implemented as a double-double arithmetic. However, due to a bug in GCC (Apple's, but also GCC 4.2.4 and 4.3.4 that are currently installed on my machine), this doesn't work. More precisely, compiling the following program makes cc1 output: tst.c:18: error: initializer for floating value is not a floating constant tst.c:18: confused by earlier errors, bailing out then crash (KERN_PROTECTION_FAILURE). #include &lt;stdio.h&gt; #define E1 (123456789.0L) #define E2 (E1 + 1.0e-60L) long double x = E2; int main (void) { long double y, z; y = E2 - E1; z = x - E1; printf ("%.20g\n", (double) y); printf ("%.20g\n", (double) z); return 0; } I wonder whether it is worth to try to recognize the double-double format as this probably won</pre> Vincent Lefevre 2010-02-22T00:48:35 http://comments.gmane.org/gmane.comp.lib.mpfr.general/687 <pre>In reading the MPFR manual, I've noticed that there appears to be no companion function for mpfr_get_z_exp(). mpz_t s; mp_exp_t p; mpfr_t x; p = mpfr_get_z_exp(s, x); for (i = 25; i &lt; 75; i++) mpz_clrbit(s, i); mpfr_set_z_exp(x, s, p, RND); The intent is to manipulate individual bits in the significand. Is there a way to do this that I missed in manual? </pre> Steve Kargl 2010-02-17T23:37:06 http://comments.gmane.org/gmane.comp.lib.mpfr.general/669 <pre>Hello, in the CGAL project, someone recently tried using boost 1.42 and mpfr and noticed compiler errors related to intmax_t. It appears that boost now defines the macros like INTMAX_C when they are not already provided by stdint.h, although it does not add typedefs for intmax_t (not in the global namespace at least). This breaks the intmax_t detection logic of mpfr.h. The platform tested was windows with the microsoft C++ compiler, ie a platform without stdint.h (it looks like version 2010 may finally have it though). Would you consider updating the test in mpfr.h? For instance, you could assume that when _MSC_VER &lt; 1600 there is no intmax_t. I don't know what other platforms may suffer from this. I don't even really know how far mpfr is supporting visual studio (a link to a 3rd party project file?). Last, note that I am posting this following a report by some other user, but I don't have MSVC, so my analysis is questionable. </pre> Marc Glisse 2010-02-14T23:20:03 http://comments.gmane.org/gmane.comp.lib.mpfr.general/664 <pre>I'm working on a Yellowdog Linux Powerstation, trying to upgrade gcc from version 4.1 to the current version. I says I need to upgrade gmp, mpfr, and mpc. The gmp upgrade went fine ( version 4.3.2, not 5.0 ) but, the mpfr configure hangs on this: checking for gfortran... gfortran checking whether we are using the GNU Fortran 77 compiler... this is the configure command output: [root&lt; at &gt;ns1 mpfr-2.4.2]# ./configure --with-gmp-build=/home/danny/Projects/gmp-4.3.2 --prefix=/usr checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to disable maintainer-specific portions of Makefiles... yes checking build system type... powerpc64-unknown-linux-gnu checking host system type... powerpc64-unknown-linux-gnu checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for a sed </pre> hembreed 2010-02-04T23:44:21 http://comments.gmane.org/gmane.comp.lib.mpfr.general/659 <pre>Dear Sir, I have a question. Why the addition is not exact? Please see the following codes. x=12388.9, y=12388999, but z=x+y is not 12401387.9. mpfr_t x,y,z; char t[7]={'1','2','3','8','8','.','9'}; char *s=t; char t2[30]={'1','2','3','8','8','9','9','9'}; char *s2=t2; char t1[30]={}; mpfr_init( x); mpfr_set_str(x, s, 10, GMP_RNDN); mpfr_init( y); mpfr_set_str(y, s2, 10, GMP_RNDN); mpfr_init2(z,29); mpfr_add(z,x,y,GMP_RNDN); mp_exp_t exp; mp_exp_t *ex; ex=&amp;exp; mpfr_get_str(t1,ex,10,6,x,GMP_RNDN); cout&lt;&lt;t1&lt;&lt;endl; cout&lt;&lt;*ex&lt;&lt;endl; mpfr_get_str(t1,ex,10,8,y,GMP_RNDN); cout&lt;&lt;t1&lt;&lt;endl; cout&lt;&lt;*ex&lt;&lt;endl; mpfr_get_str(t1,ex,10,10,z,GMP_RNDN); cout&lt;&lt;t1&lt;&lt;endl; cout&lt;&lt;*ex&lt;&lt;endl; mpfr_clear(x); mpfr_clear(y); mpfr_clear(z); mpfr_free_cache(); Sincerely, Shizhong Zhao </pre> zaim-Xb2Y1Dfb9CI< at >public.gmane.org 2010-02-02T19:13:45 http://comments.gmane.org/gmane.comp.lib.mpfr.general/658 <pre>We received the following announce concerning the mpfr.org web site and the MPFR mailing-list: - Common computer equipment and services will be down: from Friday February 5, 5:00 PM to Sunday February 7, 7:00 PM Note: these are CET times, so it would be February 5, 16:00 UTC to February 7, 18:00 UTC. Sorry for the inconvenience, </pre> Vincent Lefevre 2010-01-28T23:55:02 http://comments.gmane.org/gmane.comp.lib.mpfr.general/657 <pre>I've renamed the cumulative patches file "patches" as "allpatches" on the MPFR 2.4.2 page. If you have a link to this file, please update it. This was necessary to avoid a filename clash (yielding an obscure build failure) in case the user downloaded this file into the MPFR source directory under a case-insensitive file system (e.g. under Windows or Mac OS X). Indeed the MPFR source already has a file named "PATCHES". Sorry for the inconvenience, </pre> Vincent Lefevre 2010-01-26T09:50:09 http://comments.gmane.org/gmane.comp.lib.mpfr.general/647 <pre>I just tried running configure on mpfr-2.4.2 using Cygwin. I have installed GMP 5.0.0 using Cygwin. I ran configure with this "./configure --with-gmp-build=/home/chris/gmp-5.0.0". I get this error from configure: "configure: error: BITS_PER_MP_LIMB or BYTES_PER_MP_LIMB are incorrect. You probably need to change some of the GMP or MPFR compile options." I don't understand why I should get this error. Regards Chris Saunders </pre> Chris Saunders 2010-01-24T05:06:03 http://comments.gmane.org/gmane.comp.lib.mpfr.general/641 <pre>I'm trying to build mpfr on a Sun Ultra 27 which is running Open Solaris as the main operating system, but Solaris 10 as a guest operating system inside VirtualBox. bash-3.00$ cat /etc/release Solaris 10 10/09 s10x_u8wos_08a X86 Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 16 September 2009 GMP is installed in /usr/local. I found it necessary to set LDFLAGS to -R /usr/local/lib otherwise the configure script complains that versions of the gmp header and library are different. This is despite the fact I'd used: $ ./configure --with-gmp-lib=/usr/local/lib --with-gmp-include=/usr/local/include Anyway, after I run configure, I can build mpfr with 'make'. However, 'make check' soon fails bash-3.00$ make check Making check in tests make[1]: Entering directory `/export/home/drkirkby/mpfr-2.4.2/tests' make libfrtests.la tversion tinternals tinits tisqrt tsgn</pre> Dr. David Kirkby 2010-01-20T13:09:39 http://comments.gmane.org/gmane.comp.lib.mpfr.general/640 <pre>In the repository I was appearing under two usernames: lefevre (which came from the old CVS repository) and vlefevre. I've changed all the "lefevre" into "vlefevre". If you use a mirror (e.g. with svnsync), these revision properties won't necessarily be updated (for instance, you probably need svnsync copy-revprops ... to update them). </pre> Vincent Lefevre 2010-01-19T02:17:41 http://comments.gmane.org/gmane.comp.lib.mpfr.general/620 <pre> I'm trying to build mpfr 2.4.2 but I get the error in 'make check' that is described in http://www.mpfr.org/faq.html#undef_ref1 I've configured my env as recommended to point to /usr/local/include and /usr/local/lib # export C_INCLUDE_PATH=/usr/local/include # export LD_LIBRARY_PATH=/usr/local/lib # export LIBRARY_PATH=/usr/local/lib # export LD_RUN_PATH=/usr/local/lib # ls $C_INCLUDE_PATH gmp.h # ls $LD_LIBRARY_PATH libgmp.a libgmp.la* libgmp.so&lt; at &gt; libgmp.so.3&lt; at &gt; libgmp.so.3.5.2* # ls $LIBRARY_PATH libgmp.a libgmp.la* libgmp.so&lt; at &gt; libgmp.so.3&lt; at &gt; libgmp.so.3.5.2* this looks OK. 'make clean &amp;&amp; make' works (I get a clean build) but 'make check' still reports a problem: Making check in tests make[1]: Entering directory `/r/sanyo.unx.sas.com/vol/vol220/u22/sasdjb/dev/openmp/gomp/mpfr-2.4.2/tests' make libfrtests.la tversion tinternals tinits tisqrt tsgn tcheck tisnan texceptions tset_exp tset tabs tset_d tset_f tset_q tset_si tset_str tset_z tset_ld tset_sj tswap tcop</pre> David J. Biesack 2010-01-12T20:04:08 http://comments.gmane.org/gmane.comp.lib.mpfr.general/615 <pre> Hi, with GMP 5.0.0 and MPFR, it is possible to compute 10^9 bits of Pi in less than one hour on a 2.83Ghz Core 2: patate% time ./tconst_pi 1000000000 0 0 Seed GMP_CHECK_RANDOMIZE=1263667646 (include this in bug reports) 2885.349u 192.229s 52:16.55 98.1% 0+0k 280+16io 3pf+0w Paul Zimmermann </pre> Paul Zimmermann 2010-01-12T14:34:21 http://comments.gmane.org/gmane.comp.lib.mpfr.general/614 <pre>What would it take to implement random distributions according to the philosophy of MPFR? Consider sampling from a Gaussian with mean mu and variance sigma^2: It would be nice if this were equivalent to sampling from the exact (continuous) distribution and rounding the result (according to the rounding direction) to the closest representable number. We would stipulate, of course, a source of random bits (which in practise would come from some high-quality random number generator). I've attempted to follow this philosophy in RandomLib http://randomlib.sourceforge.net as applied to the standard floating data types. In particular, this offers "exact" implementations of the uniform distribution in [0,1] and [-1,1] and the outcome of Bernoulli trials. (Here "exact" assumes a source of random bits.) Some observations: * In addition to rounding to the nearest representable number, it's probably useful to offer a mode where the result is rounded to a multiple of a fixed interval. (This may make the a</pre> Karney, Charles 2010-01-12T02:29:46 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.mpfr.general