Multi precision floating point

[mathieu.dutour]

Dear all,

I want to do multiprecision floating point, i.e. I want
to go beyond single precision, double precision and have
quadruple precision, octuple precision and the like,
and possibly with high speed.

What would be the possible alternatives?
Thanks for any help

Mathieu

 

[jacob navia]

Dear all,

I want to do multiprecision floating point, i.e. I want
to go beyond single precision, double precision and have
quadruple precision, octuple precision and the like,
and possibly with high speed.

What would be the possible alternatives?
Thanks for any help

Mathieu

lcc-win proposes qfloat precision (352 bits, 107 digits)
and bignums, that can be arbitrarily big.

 

[Marc Boyer]

I want to do multiprecision floating point, i.e. I want
to go beyond single precision, double precision and have
quadruple precision, octuple precision and the like,
and possibly with high speed.

What would be the possible alternatives?

http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic

 

[Philip Potter]

lcc-win proposes qfloat precision (352 bits, 107 digits)
and bignums, that can be arbitrarily big.

A whole three minutes to advertise your compiler, jacob? You're getting
slow.

To the OP: jacob's compiler does indeed provide this feature. If you
simply want to use 352-bit floating point, and only ever envisage using
your code on a platform which jacob implements his compiler on, and are
happy with sticking with one compiler for the lifetime of your project,
then by all means go ahead.

If, on the other hand, you want to write multiple-precision
floating-point as a learning exercise, or you forsee ever needing to use
your code on an implementation other than jacob's, or you simply want to
keep the choice of switching vendors, then it is perfectly possible to
write multiple-precision floating-point in Standard C.

Philip

 

[jacob navia]

A whole three minutes to advertise your compiler, jacob? You're getting
slow.

To the OP: jacob's compiler does indeed provide this feature. If you
simply want to use 352-bit floating point, and only ever envisage using
your code on a platform which jacob implements his compiler on, and are
happy with sticking with one compiler for the lifetime of your project,
then by all means go ahead.

If, on the other hand, you want to write multiple-precision
floating-point as a learning exercise, or you forsee ever needing to use
your code on an implementation other than jacob's, or you simply want to
keep the choice of switching vendors, then it is perfectly possible to
write multiple-precision floating-point in Standard C.

Philip

If you are interested in portability of your code
you do

#ifdef __LCC__
typedef qfloat FLOAT_TYPE;
#else
typedef long double FLOAT_TYPE;
#endif

and you see that all your float types are declared accordingly.

Within lcc-win qfloat are just another floating point type:

qfloat a = 122333223332323.778887787766656544e7987Q;

Note the "Q" at the end.

In other libraries, the initialization of big numbers is done using
strings, and not at the global level. You may want to do that if you
use another library.

From all the other libraries, most do not fit well within C due to the
standard language lack of operator overloading.

lcc-win offers operator overloading, and it allows integrating
a large number of libraries within it to do what you want.

 

[Philip Potter]

If you are interested in portability of your code
you do

#ifdef __LCC__
typedef qfloat FLOAT_TYPE;
#else
typedef long double FLOAT_TYPE;
#endif

and you see that all your float types are declared accordingly.

This only provides portability to implementations where 'long double'
has the required precision. These are remarkably few.

Within lcc-win qfloat are just another floating point type:

qfloat a = 122333223332323.778887787766656544e7987Q;

Note the "Q" at the end.

In other libraries, the initialization of big numbers is done using
strings, and not at the global level. You may want to do that if you
use another library.

That is because those are libraries, whereas qfloat is a language
extension, which adds to the C syntax - something libraries cannot do.

From all the other libraries, most do not fit well within C due to the
standard language lack of operator overloading.

lcc-win offers operator overloading, and it allows integrating
a large number of libraries within it to do what you want.

And for this reason it may be difficult to port a qfloat program to
another platform.

I have to say, I actually agree that operator overloading provides a
nicer interface for dealing with floating-point numbers (or complex, or
fixed-point, or whatever); but C doesn't allow operator overloading, so
if you want your program to be C, you must eschew it.

 

[santosh]

Dear all,

I want to do multiprecision floating point, i.e. I want
to go beyond single precision, double precision and have
quadruple precision, octuple precision and the like,
and possibly with high speed.

What would be the possible alternatives?
Thanks for any help

If you can, think about using tested existing packages instead of
writing yet another implementation. Something like GMP is a good
candidate:

<http://gmplib.org/>

You compiler might also offer extended precision types as an extension.
Coding a MP library is not too difficult but coding a _good_ one is.
Often the low level arithmetic routines have to be done in optimised
assembler and rewritten for each target.

 

[jacob navia]

If you can, think about using tested existing packages instead of
writing yet another implementation. Something like GMP is a good
candidate:

<http://gmplib.org/>

You compiler might also offer extended precision types as an extension.
Coding a MP library is not too difficult but coding a _good_ one is.
Often the low level arithmetic routines have to be done in optimised
assembler and rewritten for each target.

GMP is without doubt one of the best around, if not the best period.

Its big problem (from a windows user perspective) is that well...
it is very difficult to build under windows. From the site where the
above link points, there is NO mention of windows, nor how to build it
under windows. It uses a lot of machinery available under linux,
specifically m4, autoconf, and all that stuff, and supposes a
gcc makefile, and the gcc toolchain.

I have heard that some people have gotten GMP to build under MSVC, but
there is no hint from that effort in the GMP pages, and as far as I
remember, the efforts are not supported by the GMP team.

 

[santosh]

GMP is without doubt one of the best around, if not the best period.

Its big problem (from a windows user perspective) is that well...
it is very difficult to build under windows. From the site where the
above link points, there is NO mention of windows, nor how to build it
under windows. It uses a lot of machinery available under linux,
specifically m4, autoconf, and all that stuff, and supposes a
gcc makefile, and the gcc toolchain.

I have heard that some people have gotten GMP to build under MSVC, but
there is no hint from that effort in the GMP pages, and as far as I
remember, the efforts are not supported by the GMP team.

MinGW and/or Cygwin might be better candidates for building GMP under
Windows.

The GMP manual has a small amount of information:

<http://gmplib.org/manual/Notes-for-Particular-Systems.html>

 

[Marco Manfredini]

GMP is without doubt one of the best around, if not the best period.

Its big problem (from a windows user perspective) is that well...
it is very difficult to build under windows. From the site where the
above link points, there is NO mention of windows, nor how to build it
under windows. It uses a lot of machinery available under linux,
specifically m4, autoconf, and all that stuff, and supposes a
gcc makefile, and the gcc toolchain.

The whole cruft to build libtoolized packages is available under windows
since *years*.
- mingw+msys, build a dll and use it with MSVC++.
- cygwin, passing "-mno-cygwin" as CFLAGS (to be true, I don't remember
exactly) to the configure script should also build a .dll which can be
used from MSVC++ or Borland C++ or Delphi...

I have heard that some people have gotten GMP to build under MSVC, but
there is no hint from that effort in the GMP pages, and as far as I
remember, the efforts are not supported by the GMP team.

A lot of people maintain diffs to allow gmp to build under various
versions of MSVC++. For example:
http://fp.gladman.plus.com/computing/gmp4win.htm

Given the the options in existance, it is understandable that the gmp
team isn't bothered with the lack of a configuration that builds right
out the box on MSVC.

 

[jacob navia]

The whole cruft to build libtoolized packages is available under windows
since *years*.
- mingw+msys, build a dll and use it with MSVC++.
- cygwin, passing "-mno-cygwin" as CFLAGS (to be true, I don't remember
exactly) to the configure script should also build a .dll which can be
used from MSVC++ or Borland C++ or Delphi...


A lot of people maintain diffs to allow gmp to build under various
versions of MSVC++. For example:
http://fp.gladman.plus.com/computing/gmp4win.htm

Given the the options in existance, it is understandable that the gmp
team isn't bothered with the lack of a configuration that builds right
out the box on MSVC.

Thats good information, but if you do not have it, it is difficult to find.

The problem with mingw is that it just doesn't work in 64 bit vista,
and I could not test it at all. There are big installation problems
under 32 bits too.

 

[Flash Gordon]

jacob navia wrote, On 28/11/07 18:50:

Thats good information, but if you do not have it, it is difficult to find.

That's strange, I typed in "GMP Windows" in Google and got loads of hits
with pre-build versions for Windows (including headers for use with
MSVC++) and build instructions for Windows. The only reason I can think
of for considering it hard to find is to not be aware of Google or the
many other web search engines.

The problem with mingw is that it just doesn't work in 64 bit vista,
and I could not test it at all. There are big installation problems
under 32 bits too.

I've not tried 64 bit Vista, but Cygwin runs fine under 32 bit Vista
(I'm using it on my company notebook a lot) and can build a dll
compatible with MSVC++.

 

[user923005]

Dear all,

I want to do multiprecision floating point, i.e. I want
to go beyond single precision, double precision and have
quadruple precision, octuple precision and the like,
and possibly with high speed.

What would be the possible alternatives?

http://pari.math.u-bordeaux.fr/benchs/timings-mpfr.html

 

[Dik T. Winter]

....
> If you are interested in portability of your code
> you do
>
> #ifdef __LCC__
> typedef qfloat FLOAT_TYPE;
> #else
> typedef long double FLOAT_TYPE;
> #endif

And what do you do with the octuple precision and so on?

 

[jacob navia]

And what do you do with the octuple precision and so on?

You typedef your FLOAT_TYPE to the type you are using in the external
library you are linking with, what else?

 

[Dik T. Winter]

> Dik T. Winter wrote: ....
>
> You typedef your FLOAT_TYPE to the type you are using in the external
> library you are linking with, what else?

And that single typedef solves all discrepancies?

 

[mathieu.dutour]

This only provides portability to implementations where 'long double'

has the required precision. These are remarkably few.

Yes that is somewhat more what I had in mind.
Actually, the intel fortran compiler version 10 has support for
quadruple precision of IEEE754r.

Does there exist some C compiler supporting quadruple precision?
The wikipedia page says that "long double" can be the 80-bits of
the x86 or sometimes the 128 bits of quadruple precision. What are
those "remarkably few" compilers? Also, how could we interface
fortran and C for quadruple precision?

That's the extend of my problem. I have an existing C library
depending on lapack/blas, which I need to extend to computing
in higher precision, and quadruple might not be enough.

Otherwise, thanks to all and to Jacob for lcc-win, which I did
not knew about. But this work is supposed to be on linux x86
computers.

 

[santosh]

Yes that is somewhat more what I had in mind.
Actually, the intel fortran compiler version 10 has support for
quadruple precision of IEEE754r.

Does there exist some C compiler supporting quadruple precision?
The wikipedia page says that "long double" can be the 80-bits of
the x86 or sometimes the 128 bits of quadruple precision. What are
those "remarkably few" compilers? Also, how could we interface
fortran and C for quadruple precision?

Have you investigated the excellent Intel C/C++ compilers? They should
provide 128 bit floating point support.

That's the extend of my problem. I have an existing C library
depending on lapack/blas, which I need to extend to computing
in higher precision, and quadruple might not be enough.

Then you need something like MPFR.

<http://en.wikipedia.org/wiki/MPFR>

Otherwise, thanks to all and to Jacob for lcc-win, which I did
not knew about. But this work is supposed to be on linux x86
computers.

jacob was part way through implementing his lcc-win32 for Linux (x86)
when licensing restrictions forced him to freeze the effort. But he may
be able to still help you out if you can establish a commercial license
with him.

 

[Philip Potter]

You typedef your FLOAT_TYPE to the type you are using in the external
library you are linking with, what else?

Doesn't help with libraries which don't overload operators. So, in fact,
all libraries.

 

[Philip Potter]

Yes that is somewhat more what I had in mind.
Actually, the intel fortran compiler version 10 has support for
quadruple precision of IEEE754r.

Does there exist some C compiler supporting quadruple precision?
The wikipedia page says that "long double" can be the 80-bits of
the x86 or sometimes the 128 bits of quadruple precision. What are
those "remarkably few" compilers? Also, how could we interface
fortran and C for quadruple precision?

I was specifically referring to jacob's qfloat precision which he claims
is 352-bits. I presume this is mantissa bits, including the hidden bit,
but I'm not sure. I doubt there are many compilers which provide long
double of this size.

Phil