[Cbc] CoinModel Equality?
John Forrest
john.forrest at fastercoin.com
Mon Feb 17 11:01:11 EST 2014
Matthew,
Seemed simpler just to write an OsiSolverInterface::differentModel.
Lacking energy, I could not be bothered to check names being same.
Only in Osi/trunk but you can safely copy OsiSolverInterface.?pp over to
stable as no recent changes.
John Forrest
On 16/02/14 20:24, Matthew Gidden wrote:
> Hi John, all,
>
> I've finally got my testing plumbing finished and am actually trying
> to compare Models. I'm running into the problem that
> a) there is no member function for OsiSolverInterface to return access
> to a CoinModel
> b) Models don't actually from CoinModel (e.g.,
> ClpSimplex->ClpModel-/>CoinModel)
>
> I'll do my best to explain my problem and wait for
> advice/clarification from the list.
>
> I have a factory method that returns a pointer to an
> OsiSolverInterface. I then create an instance of a problem using the
> interface, solve it, and interpret the solution. My goal is to unit
> test the model creation process.
>
> In the following example, the interface is named iface,
> CoinPackedMatrix (m), and the associated upper/lower bounds are
> vectors. Is this the best way to try to compare models? (FYI -- I
> assume not, because it results in a seg fault)
>
> CoinModel model(nrows, ncols, &m, &row_lbs[0], &row_ubs[0],
> &col_lbs[0], &col_ubs[0], &obj_coeffs[0]);
> ClpSimplex* compare =
> dynamic_cast<OsiClpSolverInterface*>(iface)->getModelPtr();
> EXPECT_EQ(0, model.differentModel(*compare->createCoinModel(),
> true));
>
>
> You can see the entire (long) testing process here:
> https://github.com/gidden/cyclus/blob/lpsolver/tests/prog_translator_tests.cc
>
> Thank you very much in advance!
>
>
>
> On Thu, Feb 13, 2014 at 11:44 AM, Matthew Gidden <gidden at wisc.edu
> <mailto:gidden at wisc.edu>> wrote:
>
> Awesome, thank you, John.
>
>
> On Thu, Feb 13, 2014 at 11:43 AM, John Forrest
> <john.forrest at fastercoin.com <mailto:john.forrest at fastercoin.com>>
> wrote:
>
> Matthew,
>
> There is a CoinModel::differentModel which should do what you
> want. There is a default tolerance test for two values being
> same - if this isn't good enough then it would be easy to pass
> in a tolerance test to one of the CoinModels.
>
> John Forrest
>
> On 06/02/14 19:42, Matthew Gidden wrote:
>> Great, thanks for your response, Miles!
>>
>>
>> On Thu, Feb 6, 2014 at 12:27 PM, Miles Lubin
>> <miles.lubin at gmail.com <mailto:miles.lubin at gmail.com>> wrote:
>>
>> Hi Matthew,
>>
>> CoinModel can be used to store an LP/MIP instance, but I
>> don't believe there are any comparison methods. You'll
>> likely have to manually iterate through the problem data
>> to compare entry by entry, using whatever floating-point
>> comparison tolerance is appropriate. I would also suggest
>> building your infrastructure around a solver-independent
>> interface like OSI, because it's always valuable to be
>> able to compare the performance of different solvers. Any
>> academic publication would be remiss to only use one
>> open-source MIP solver when making claims about time to
>> solve a particular problem.
>>
>> Best,
>> Miles
>>
>>
>> On Thu, Feb 6, 2014 at 12:51 PM, Matthew Gidden
>> <gidden at wisc.edu <mailto:gidden at wisc.edu>> wrote:
>>
>> Hi all,
>>
>> First time caller, long time listener. I'm gearing up
>> the portion of my research in which I'll be using and
>> comparing simplex and branch-and-cut solvers versus
>> some naive solvers in our simulation environment [1].
>> We require a permissive, open source license (for
>> compatibility with our own - BSD 3-clause), so the
>> COIN suite was a natural fit.
>>
>> To the meat of my question:
>> I've written a high-level API for myself and other
>> devs to use to describe an problem instance in part
>> of our simulation framework. I would like to be able
>> to unit test it such that a problem instance it
>> describes is equivalent to some known problem
>> instance (read in through MPS, for example). My
>> initial thought was to compare configured CoinModels
>> (i.e., builders). Is there an easy way to compare
>> them? Is this the best approach?
>>
>> I look forward to your response, thanks!
>>
>> [1] http://fuelcycle.org/
>>
>> --
>> Matthew Gidden
>> Ph.D. Candidate, Nuclear Engineering
>> The University of Wisconsin -- Madison
>> Ph. 225.892.3192 <tel:225.892.3192>
>>
>> _______________________________________________
>> Cbc mailing list
>> Cbc at list.coin-or.org <mailto:Cbc at list.coin-or.org>
>> http://list.coin-or.org/mailman/listinfo/cbc
>>
>>
>>
>>
>>
>> --
>> Matthew Gidden
>> Ph.D. Candidate, Nuclear Engineering
>> The University of Wisconsin -- Madison
>> Ph. 225.892.3192 <tel:225.892.3192>
>>
>>
>> _______________________________________________
>> Cbc mailing list
>> Cbc at list.coin-or.org <mailto:Cbc at list.coin-or.org>
>> http://list.coin-or.org/mailman/listinfo/cbc
>
>
> _______________________________________________
> Cbc mailing list
> Cbc at list.coin-or.org <mailto:Cbc at list.coin-or.org>
> http://list.coin-or.org/mailman/listinfo/cbc
>
>
>
>
> --
> Matthew Gidden
> Ph.D. Candidate, Nuclear Engineering
> The University of Wisconsin -- Madison
> Ph. 225.892.3192 <tel:225.892.3192>
>
>
>
>
> --
> Matthew Gidden
> Ph.D. Candidate, Nuclear Engineering
> The University of Wisconsin -- Madison
> Ph. 225.892.3192
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/cbc/attachments/20140217/d33324b0/attachment-0001.html>
More information about the Cbc
mailing list