[Scip] Design choices

[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
>