<div>A bit of a tangent, but the reason the model is "not well scaled" is because I have two variables:<br></div><div><br></div><div>change_amount (a number saying how much change will be created)<br></div><div>has_change (a binary 0 or 1, saying if there's change)<br></div><div><br></div><div>and I need to constrain these two things together. The only way I could think of was by creating two different constraints:<br></div><div><br></div><div>c0: + change_amount - has_change >= 0<br></div><div>c1: + 2100000000000000 has_change - change_amount >= 0<br></div><div><br></div><div><br></div><div>Which in a high level language would be:<br></div><div><br></div><div>let has_change = change_amount > 0<br></div><div><br></div><div>(the reason I use 2.1e14 is because it's a max theoretical amount change could ever be. Although in practice, it's several orders of magnitude less).<br></div><div><br></div><div>Is there a smarter way of doing what I'm trying to do?</div><div><br></div><div>---</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div class="protonmail_signature_block"><div class="protonmail_signature_block-user"><div>-Ryan<br></div></div><div class="protonmail_signature_block-proton protonmail_signature_block-empty"><br></div></div><div><br></div><blockquote type="cite" class="protonmail_quote"><div>-------- Original Message --------<br></div><div>Subject: Re: [Cbc] Suboptimal solution as optimal?<br></div><div>Local Time: December 29, 2017 4:39 AM<br></div><div>UTC Time: December 29, 2017 10:39 AM<br></div><div>From: john.forrest@fastercoin.com<br></div><div>To: cbc@list.coin-or.org<br></div><div><br></div><div><br></div><div class="moz-cite-prefix"><div>Fixed hopefully - stable and trunk.<br></div><div><br></div><div>The original model is not well scaled - one element was 2.1e14 and
even after preprocessing the problem had to be solved applying
scaling factors. The small fast branch and bound is deliberately
a bit forgiving on this. When the code thinks it has got a
solution it double checks. In this case it did that and threw
that solution out - but it had left some variables fixed when they
should not have been.<br></div><div><br></div><div>John Forrest<br></div><div><br></div><div>On 28/12/17 18:30, John Forrest wrote:<br></div></div><blockquote type="cite"><div class="moz-cite-prefix"><div>Ryan,<br></div><div><br></div><div>Bug in Cbc. My first try gave correct result, but I managed to
get error. For small problems, Cbc will do a simpler faster
branch and bound on a portion of the tree. This is returning
infeasible - I will look into it.<br></div><div><br></div><div>If you add -depth -100 (which means only go into this simpler
version at depth 100) then all looked fine.<br></div><div><br></div><div>John Forrest<br></div><div>On 27/12/17 18:37, Rhavar wrote:<br></div></div><blockquote type="cite"><div>I have a problem:<br></div><div><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_RHavar_dfb9de631363ecb9e1c326fff5ebd09b&d=DwMDaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=js2M0T-3OIMIVDvokcKjokJbk0F8QOCd0mT4FsVFE88&m=S4VZrfTJ9vrNsPyEyqDoTZUqb0eG9rdZ8l7-jr8EA9Y&s=dWErV9QjwaNhpQZZkV1ZmdJ_Ofpqgb80lh0-5ORAiSU&e=">https://gist.github.com/RHavar/dfb9de631363ecb9e1c326fff5ebd09b</a><br></div><div><br></div><div>(lp file and solution file attached)<br></div><div><br></div><div>In the solution it says: "Optimal - objective value" but I
think I have found a superior solution by hand:<br></div><div><br></div><div><span class="s1"><span class="Apple-converted-space"> </span>o6
= 1</span><br></div><div>i22 = 1<br></div><div><br></div><div>Which gives a better objective (<span class="s1">70 instead
of </span>825)<br></div><div><br></div><div>--<br></div><div><br></div><div>So I guess my question is, does "Optimal - objective
value" mean that it's guaranteed to be the optimal solution?
Or am I doing something wrong? Or is there a bug in cbc? <br></div><div><br></div><div><br></div><div class="protonmail_signature_block"><div class="protonmail_signature_block-user"><div>-Ryan<br></div></div><div class="protonmail_signature_block-proton
protonmail_signature_block-empty"><br></div></div><div><br></div><div><br></div><div><br></div><pre wrap="">_______________________________________________
Cbc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cbc@list.coin-or.org">Cbc@list.coin-or.org</a>
<a class="moz-txt-link-freetext" href="https://urldefense.proofpoint.com/v2/url?u=https-3A__list.coin-2Dor.org_mailman_listinfo_cbc&d=DwMDaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=js2M0T-3OIMIVDvokcKjokJbk0F8QOCd0mT4FsVFE88&m=S4VZrfTJ9vrNsPyEyqDoTZUqb0eG9rdZ8l7-jr8EA9Y&s=SVcz-BvCf0RgvZrRQQxyV89AGoSkVGhfQhv4tx1JKV4&e=">https://list.coin-or.org/mailman/listinfo/cbc</a>
<br></pre></blockquote><p><br></p><div><br></div><div><br></div><pre wrap="">_______________________________________________
Cbc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cbc@list.coin-or.org">Cbc@list.coin-or.org</a>
<a class="moz-txt-link-freetext" href="https://urldefense.proofpoint.com/v2/url?u=https-3A__list.coin-2Dor.org_mailman_listinfo_cbc&d=DwICAg&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=js2M0T-3OIMIVDvokcKjokJbk0F8QOCd0mT4FsVFE88&m=S4VZrfTJ9vrNsPyEyqDoTZUqb0eG9rdZ8l7-jr8EA9Y&s=SVcz-BvCf0RgvZrRQQxyV89AGoSkVGhfQhv4tx1JKV4&e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__list.coin-2Dor.org_mailman_listinfo_cbc&d=DwICAg&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=js2M0T-3OIMIVDvokcKjokJbk0F8QOCd0mT4FsVFE88&m=S4VZrfTJ9vrNsPyEyqDoTZUqb0eG9rdZ8l7-jr8EA9Y&s=SVcz-BvCf0RgvZrRQQxyV89AGoSkVGhfQhv4tx1JKV4&e=</a>
<br></pre></blockquote><p><br></p></blockquote><div><br></div>