[Clp] high precision floating point numbers

Michael Hennebry hennebry at web.cs.ndsu.nodak.edu
Tue May 12 12:11:13 EDT 2009


On Tue, 12 May 2009, Alexey Lvov wrote:
> Is it possible to substitute "double" by a 128 bit floating point class in
> CLP?

Probably.
If you do so, I'd recommend not allowing
automatic conversion to double.
>
>
> I really admire how CLP can solve 50000 variable linear systems having just
> 15 decimal digits available (my own "brute force" simplex can not handle a
> system with more than 300 variables with the standard 64-bit double type).
> But when it comes to 600,000 variables, handling it with just 15 decimal
> digits, I think,  becomes impossible... I tried different combinations of
> tolerances in both primal and dual simplex of CLP but always got a
> segmentation fault after 24-48 hours.

A segmentation fault suggests another issue.
Perhaps it is running out of memory and dereferencing a null pointer.
Track down the segmentation fault.

> If someone knows the answer, please let me know... If it is not
> implemented, I would volunteer to write a 128 bit floating point class

The tidiest solution would be to find a compiler
for which double is more than 64 bits.
Otherwise, to start with, I'd suggest making it a wrapper for long double.
On many systems, long double is at least 80 bits.
If that is not enough go for triple precision before quadruple.
The value represented is the sum of the two stored doubles.
The high order one will only use half its significant bits.
It won't be fast, but other things will be slower.

Another thing you might do is to edit CLP,
e.g. use long double or Kahan's algorithm to do sums.
Kahan's algorithm will give you the effect of quadruple precison in a sum,
though not in the generation of its terms.
On some systems, the sums will be done in
long double whether you tell it to or not.

> (unless it already exists in COIN).... Of course it will be much slower
> than "double" but for someone who really needs a solution of a large
> problem and has a lot of patience this would help....

-- 
Michael   hennebry at web.cs.ndsu.NoDak.edu
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."




More information about the Clp mailing list