Vincent Lefevre | 1 Aug 10:55 2010
Picon

Re: mpfr-3.0.0 on Solaris Intel and Mac OS X Intel

Hi,

On 2010-07-31 11:22:37 -0600, Nelson H. F. Beebe wrote:
> The symptoms on both are similar:  compilations produce warnings like
> this:
> 
> exceptions.c: In function `mpfr_set_emin':
> exceptions.c:43: warning: left shift count >= width of type
> [many more such]

If this is what I'm thinking of (I'm not sure since I thought
there were just a few of them), this happens in 32 bits only
(IIRC) and this is a known bug in GCC (just a warning, the
generated code is correct). FYI, the corresponding code is
there for 64-bit platforms, but is never executed in 32 bits,
or then other way round.

> Ideas for fixing this?  It sounds like 32-bit vs 64-bit confusion,
> or perhaps gmp-4 vs gmp-5 confusion.
> 
> I tried removing the previously-installed mpfr release on both
> failing systems, and doing fresh builds, but that had no effect.

What do you mean exactly?

--

-- 
Vincent Lefèvre <vincent@...> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

(Continue reading)

Vincent Lefevre | 1 Aug 22:01 2010
Picon

Re: mpfr-3.0.0 on Solaris Intel and Mac OS X Intel

On 2010-08-01 10:55:14 +0200, Vincent Lefevre wrote:
> Hi,
> 
> On 2010-07-31 11:22:37 -0600, Nelson H. F. Beebe wrote:
> > The symptoms on both are similar:  compilations produce warnings like
> > this:
> > 
> > exceptions.c: In function `mpfr_set_emin':
> > exceptions.c:43: warning: left shift count >= width of type
> > [many more such]
> 
> If this is what I'm thinking of (I'm not sure since I thought
> there were just a few of them), this happens in 32 bits only
> (IIRC) and this is a known bug in GCC (just a warning, the
> generated code is correct). FYI, the corresponding code is
> there for 64-bit platforms, but is never executed in 32 bits,
> or then other way round.

Actually it seems that these problems no longer occur.

If you are getting many such warnings, this is indeed a 32-bit vs
64-bit confusion. The above one comes from MPFR_EMIN_MIN and/or
MPFR_EMIN_MAX, which comes from MPFR_EXP_INVALID (in mpfr-impl.h).
One has:

  ((mpfr_exp_t) 1 << (GMP_NUMB_BITS*sizeof(mpfr_exp_t)/sizeof(mp_limb_t)-2))

where:

  typedef mp_exp_t     mpfr_exp_t;
(Continue reading)

Vincent Lefevre | 1 Aug 22:24 2010
Picon

dependency bug concerning mparam.h

FYI, there was a dependency bug concerning mparam.h, which I've fixed:

  https://gforge.inria.fr/tracker/index.php?func=detail&aid=10810&group_id=136&atid=619

--

-- 
Vincent Lefèvre <vincent@...> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Ricardo Martins | 3 Aug 15:04 2010
Picon

URGENT: exponent control in MPFR

Dear colleagues,


I am professor at Federal University of Pernambuco, PE, Brazil.
At moment, I am in my post-doc at AT&T Labs Research, NJ, USA.
I am implementing  the modified ellipsoid version of Grotschel, Lovasz, and Schrijver.

I realized that the exact precision offered by GNU MPFR library affects just the number of bits of the significant (or coefficient) in a floating-point representation.
But what I need exactly is to control the exponent in order to fix a denominator 2^p and approximate each number by a rational number with this denominator.
In other words, I want write a number in its binary representation and cut off after p digits behind the binary point, where p is to be specified.
So, how can I do this using GNU MPFR?

Thank you so much
--rmas   

Vincent Lefevre | 3 Aug 22:44 2010
Picon

Re: URGENT: exponent control in MPFR

Hi,

On 2010-08-03 10:04:39 -0300, Ricardo Martins wrote:
> I realized that the exact precision offered by GNU MPFR library affects just
> the number of bits of the significant (or coefficient) in a floating-point
> representation.
> But what I need exactly is to control the exponent in order to fix a
> denominator 2^p and approximate each number by a rational number with this
> denominator.
> In other words, I want write a number in its binary representation and cut
> off after p digits behind the binary point, where p is to be specified.
> So, how can I do this using GNU MPFR?

It isn't clear what you want exactly. If I've understood correctly,
you want a result in fixed point, or equivalently, to get the
exponent of the result in order to fix the precision.

You can compute the exponents of results (or bounds) by doing
computations in very low precision, then use these results to
fix the precisions of the variables and redo the computations
in these precisions.

--

-- 
Vincent Lefèvre <vincent@...> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Nelson H. F. Beebe | 4 Aug 00:50 2010
Picon

Re: mpfr-3.0.0 on Solaris Intel and Mac OS X Intel

[This posting is to both the mpfr and bug-gmp lists because of the content overlap.]

Thanks to clues from respondents to my problem report of Sat, 31 Jul
2010 11:22:37 -0600 (MDT) on the mpfr list, I've tracked down and
resolved the problems building mpfr-3.0.0 on Solaris Intel and Mac OS
X Intel.  I now have mpfr-3.0.0 passing all of its tests and
successfully installed on about 20 flavors of Unix.

The problem explanation is this: on those two systems, and also
Solaris SPARC, gmp by default builds with ABI=64, even though the
normal build environment in all three cases is the 32-bit world, with
64-bit companions being optional, but unusual.

I've therefore often built both 32-bit and 64-bit gmp installations on
those machines, but the problem that turned up with mpfr this time has
to do with the installation order: if the 64-bit version is installed
last, then /usr/local/include/gmp.h contains

	#define GMP_LIMB_BITS                      64

instead of

	#define GMP_LIMB_BITS                      32

The result is that the default libraries in /usr/local/lib are 32-bit
(the 64-bit ones reside in /usr/local/lib64 on Mac OS X, and
/usr/local/lib/64 on Solaris), and they get used in the mpfr build
with the 64-bit gmp.h header file, causing the massive confusion,
compilation warnings, and test failures that I reported.

It would be nice if the gmp folks could get their configure script to
pick the default nn-bit world correctly on all systems, but it is also
important to be able have both 32-bit and 64-bit software installed in
parallel directories on those many platforms that support dual worlds.

While separate 32-bit and 64-bit library paths are well-understood on
those platforms, as far as I can tell, there is no good convention for
handling such a dependence in header files, since the GNU standards
for "make install" have only ${prefix}/include for the location.

Ideally, one would like the installed header files to be
ABI-size-independent, with the desired size chosen at compile time by
an ABI option, or, perhaps better, by the kind of link library found,
such as this pair on Mac OS X Intel:

% file /usr/local/lib64/libgmp.3.5.0.dylib
/usr/local/lib64/libgmp.3.5.0.dylib: Mach-O 64-bit dynamically linked shared library x86_64

% file /usr/local/lib/libgmp.3.5.0.dylib
/usr/local/lib/libgmp.3.5.0.dylib: Mach-O dynamically linked shared library i386

Comments?

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail:
beebe@...  -
- 155 S 1400 E RM 233                       beebe@... 
beebe@... -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

Vincent Lefevre | 4 Aug 11:20 2010
Picon

Re: mpfr-3.0.0 on Solaris Intel and Mac OS X Intel

On 2010-08-03 16:50:51 -0600, Nelson H. F. Beebe wrote:
> It would be nice if the gmp folks could get their configure script to
> pick the default nn-bit world correctly on all systems, but it is also

This is what I requested in the past.

> important to be able have both 32-bit and 64-bit software installed in
> parallel directories on those many platforms that support dual worlds.
> 
> While separate 32-bit and 64-bit library paths are well-understood on
> those platforms, as far as I can tell, there is no good convention for
> handling such a dependence in header files, since the GNU standards
> for "make install" have only ${prefix}/include for the location.

GMP uses ${exec_prefix}/include for gmp.h.

> Ideally, one would like the installed header files to be
> ABI-size-independent, with the desired size chosen at compile time by
> an ABI option,

This would mean that GMP could no longer support nails or alternative
ABI's (such as mode32). But are they used in practice?

> or, perhaps better, by the kind of link library found,
> such as this pair on Mac OS X Intel:
> 
> % file /usr/local/lib64/libgmp.3.5.0.dylib
> /usr/local/lib64/libgmp.3.5.0.dylib: Mach-O 64-bit dynamically linked shared library x86_64
> 
> % file /usr/local/lib/libgmp.3.5.0.dylib
> /usr/local/lib/libgmp.3.5.0.dylib: Mach-O dynamically linked shared library i386

I don't understand.

--

-- 
Vincent Lefèvre <vincent@...> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Vincent Lefevre | 6 Aug 16:25 2010
Picon

MPFR repository format upgraded

Hi,

I've upgraded the MPFR repository, as described on

  http://subversion.apache.org/docs/release-notes/1.5.html#repos-upgrades

Everything worked well, and the new dump compares equal to the
old dump (as expected).

This means that we now benefit from all the features present in
Subversion 1.5, in particular merge tracking.

--

-- 
Vincent Lefèvre <vincent@...> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

roycstannard | 12 Aug 16:10 2010
Picon

./configure and make problem on installation

Hi,
This is my first post. I'm not sure that I'm posting to the right place,
perhaps the moderators can redirect this post if necessary.  

I have downloaded mpfr-3.0.0 and extracted it to a tmp folder. My OS is Ubuntu
10.04 on an Intel machine. 

Following the instructions in INSTALL:

 /~/tmp/mpfr-3.0.0 $ ./configure
. . . . .
. . . . .
checking for gmp.h... no
configure: error: gmp.h can't be found, or is unusable.

From my reading of INSTALL, gmp is optional

/~/tmp/mpfr-3.0.0 $ make
make: *** No targets specified and no makefile found.  Stop.

Any help would be most welcome

Vincent Lefevre | 12 Aug 16:34 2010
Picon

Re: ./configure and make problem on installation

Hi,

On 2010-08-12 16:10:13 +0200, roycstannard@... wrote:
> This is my first post. I'm not sure that I'm posting to the right place,
> perhaps the moderators can redirect this post if necessary.  

Yes, this is the right place.

> Following the instructions in INSTALL:
> 
>  /~/tmp/mpfr-3.0.0 $ ./configure
> . . . . .
> . . . . .
> checking for gmp.h... no
> configure: error: gmp.h can't be found, or is unusable.
> 
> From my reading of INSTALL, gmp is optional

Optional? The INSTALL file says:

0. You first need to install GMP. See <http://www.gnu.org/software/gmp/>.
   MPFR requires GMP version 4.1 or later.

This step is optional only if GMP is already installed. Note that
you need a full GMP installation, i.e. with the development files
(provided by a package like libgmp3-dev).

Regards,

--

-- 
Vincent Lefèvre <vincent@...> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


Gmane