[Scip] Design choices

[Nikolaj van Omme]

Hi Timo,

I don't want to relaunch a discussion about the difference between
Branch, Cut and Price (which is available in Scip) and Branch, Price and
cut (which is *NOT* available IMHO in Scip). The difference between the
two is *huge* (both in the implementation and results).

Parallelization is a (very) difficult topic but non-the-less it's the
short term future. ;-)

MINLP and global optimization are also (very) difficult challenges!

Lots of entertaining debugging sessions in sight! re ;-)

Best regards,

Nikolaj




On 07/01/2013 10:50 AM, Timo Berthold wrote:
> Hi Nikolaj,
> 
> I can add a third point to this list: MINLP and global optimization.
> This has been a major direction for SCIP in the last two or three years,
> and it still is.
> 
> The UG framework is available for download, still in a pre-1.0 version,
> though, and under active further development by Yuji Shinano. It is a
> good question if and when we will implement internal parallelization in
> SCIP. I do agree that this is one of the biggest open points for SCIP -
> unfortunately, it is not an easy topic to conduct research in
> Mathematics on. Remember that most of our team members are PhD students
> who need material for their dissertation. ;-) This is the simple and
> unsatisfying reason that kept us, so far, from spending time on that topic.
> 
> I do not really get the point on B,C&P. It is possible in SCIP to
> generate rows and columns at one node, simultaneously. Maybe I'm missing
> out on some previous discussion about some specific features missing.
> 
> Cheers,
> Timo
> 
> Am 01.07.2013 16:36, schrieb Nikolaj van Omme:
>> Hi "Scipers",
>>
>> Sorry to jump in for what might seem "obvious" or non-constructive (?).
>>
>> Stefan, there are very good reasons why to use int instead of unsigned
>> int. Just search "int vs unsigned int".
>>
>> Now that I've jumped in, I would like to add a comment on the future of
>> Scip. There are, IMHO, two avenues that need to be explored by Scip if
>> it wants to stay put with the state-of-the-art solvers:
>>
>> - parallelization (what happened to paraScip? or Ubiquity Generator
>> framework?);
>> - the possibility to do *real* Branch, Price and Cut, i.e. to generate
>> columns AND cuts at every node of the search tree.
>>
>> That said, Scip is a wonderful tool and I take his opportunity to thank
>> the whole team!
>>
>> Regards,
>>
>> Nikolaj
>>
>> On 07/01/2013 04:57 AM, Stefan Lörwald wrote:
>>> Hi again,
>>>
>>> one more thing that I forgot to ask in the first mail:
>>>
>>> Why do some functions return an int, where there can't ever be a negative
>>> result?
>>>
>>> Take e.g. int SCIPgetNConshdlrs(SCIP*). It is obvious that the number of
>>> Conshdlrs (or any other SCIPgetN...) can only return a natural number,
>>> because there can't be any negative numbers of conshdlrs.
>>>
>>> Why not return an unsigned int? Is some special value like -1 needed for
>>> passing an error status? If so, shouldn't this be caught by SCIP_RETCODE /
>>> SCIP_CALL?
>>>
>>> Personally I thought that the oddest place to use an int is in
>>> SCIPinferVarUbCons and related methods. Why pass the inferinfo as int? In
>>> your LOP example, this get's used to pass some information about indices.
>>> However as indices are again inherently unsigned, int is not a good match.
>>> Furthermore, since the encoding of this information needs to do something
>>> like i * n * n * n + j * n * n + k * n + l, this will fail for instances
>>> with n >= 256 This worsens if (as in the LOP example) more than one
>>> constraint has to be encoded (e.g. with n^8 + n^4 + i * n * n * n + ...).
>>> So inferinfo remains unusable for most applications.
>>>
>>> The most useful way to pass information is with a custom struct InferInfo
>>> containing fields for the indices (staying with this example, there are
>>> certainly other ways to use this).
>>> But this can't be done safely (i.e. platform independent) because we'd have
>>> to use a pointer to the struct which doesn't necessarily have the same
>>> number of bytes as the int (e.g. with int usually having 4 bytes and
>>> pointers using 8bytes on 64bit platforms).
>>>
>>> So what's the rationale behind integers returning for functions returning
>>> sizes and what's the reason for using an integer to encode information
>>> about constraints rather than a struct pointer?
>>>
>>> Yours,
>>> Stefan
>>>
>>>
>>>
>>> _______________________________________________
>>> Scip mailing list
>>> Scip at zib.de
>>> http://listserv.zib.de/mailman/listinfo/scip
>>>
>> _______________________________________________
>> Scip mailing list
>> Scip at zib.de
>> http://listserv.zib.de/mailman/listinfo/scip
> 
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip
>