[Clp] large int (int64_t) overflow?

[Emerson]

Thanks Michael,
I think I just found where the problem is. Previously I used


* buildObj.addRow(folly::to<int>(indices.size()), indicesArr, coeffArr, 0,
0);*

It's very easy to return a "0" solution.
But after I modify this a bit, set the upper and lower bounds to 0.1, it
will return the right solution:

* buildObj.addRow(folly::to<int>(indices.size()), indicesArr, coeffArr,
0.1, 0.1);*

I think the reason behind this is "double" datatype precision. It's so hard
to find exact "0" but much easier to find a non-zero solution. Even I
changed 0 to a large number, say demand, the solver will still give me a
larger than 0 solution.
Since my problem setting is very large, this 0.1 factor won't impact the
result at all. But I'm wondering anyone can give an exactly detailed
explanation for this? Thanks

Best,
Emer

On Sun, Jul 19, 2015 at 9:42 AM, Michael Hennebry <
hennebry at web.cs.ndsu.nodak.edu> wrote:

> On Sat, 18 Jul 2015, Emerson wrote:
>
>  Since I use bps as the unit of demand, a typical value is at the magnitude
>> of 100,000,000,000, I use int64_t as its value type. But when the value is
>> at this order, Clp seems can't handle too many inequalities like this. Is
>> that because Clp uses type *double*? Or it will give up calculation and
>> return 0(if it's feasible) if the number is too large?
>> It's OK to lose some accuracy in my solution, *double* has 1.7e+308 range,
>> so it shouldn't be a problem, right?
>>
>
> ClpSimplex uses some constants related to how accurate
> its authors expect from a long series of calculations.
> One such number is considerably larger than DBL_EPS,
> probably 2**-53 .
>
>  Any way to tune the solver to manipulate larger number or I have to
>> decrease the number order when solving and enlarge it in the solution?
>>
>
> I think that there are options to handle just that,
> but do not remember what they are.
> If all else fails, you can alter the code.
>
> Since you seem to be using a generic simplex solver on a network problem,
> claiming more precision will probably work.
>
> --
> Michael   hennebry at web.cs.ndsu.NoDak.edu
> "SCSI is NOT magic. There are *fundamental technical
> reasons* why it is necessary to sacrifice a young
> goat to your SCSI chain now and then."   --   John Woods
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/clp/attachments/20150719/21e5e510/attachment.html>