<div dir="ltr">Thanks Michael,<div>I think I just found where the problem is. Previously I used </div><div><br></div><div><b> buildObj.addRow(folly::to<int>(indices.size()), indicesArr, coeffArr, 0, 0);<br></b></div><div><br></div><div>It's very easy to return a "0" solution.</div><div>But after I modify this a bit, set the upper and lower bounds to 0.1, it will return the right solution:</div><div><br></div><div><b> buildObj.addRow(folly::to<int>(indices.size()), indicesArr, coeffArr, 0.1, 0.1);</b></div><div><b><br></b></div><div>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. </div><div>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</div><div><br></div><div>Best,</div><div>Emer</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 19, 2015 at 9:42 AM, Michael Hennebry <span dir="ltr"><<a href="mailto:hennebry@web.cs.ndsu.nodak.edu" target="_blank">hennebry@web.cs.ndsu.nodak.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, 18 Jul 2015, Emerson wrote:<br>
<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Since I use bps as the unit of demand, a typical value is at the magnitude<br>
of 100,000,000,000, I use int64_t as its value type. But when the value is<br>
at this order, Clp seems can't handle too many inequalities like this. Is<br></span>
that because Clp uses type *double*? Or it will give up calculation and<span class=""><br>
return 0(if it's feasible) if the number is too large?<br></span>
It's OK to lose some accuracy in my solution, *double* has 1.7e+308 range,<span class=""><br>
so it shouldn't be a problem, right?<br>
</span></blockquote>
<br>
ClpSimplex uses some constants related to how accurate<br>
its authors expect from a long series of calculations.<br>
One such number is considerably larger than DBL_EPS,<br>
probably 2**-53 .<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Any way to tune the solver to manipulate larger number or I have to<br>
decrease the number order when solving and enlarge it in the solution?<br>
</blockquote>
<br></span>
I think that there are options to handle just that,<br>
but do not remember what they are.<br>
If all else fails, you can alter the code.<br>
<br>
Since you seem to be using a generic simplex solver on a network problem,<br>
claiming more precision will probably work.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Michael <a href="mailto:hennebry@web.cs.ndsu.NoDak.edu" target="_blank">hennebry@web.cs.ndsu.NoDak.edu</a><br>
"SCSI is NOT magic. There are *fundamental technical<br>
reasons* why it is necessary to sacrifice a young<br>
goat to your SCSI chain now and then." -- John Woods<br>
</font></span></blockquote></div><br></div>