[Scip] Design choices

[Timo Berthold]

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