[Scip] Design choices

[Stefan Lörwald]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.zib.de/mailman/private/scip/attachments/20130701/40d4585a/attachment.html