[Scip] Design choices

[Stefan Lörwald]

Hi Domenico and list,

first of all, thanks for this well-written resume about C vs C++, Domenico!
Two short last comments: C does not have data encapsulation, just because
there's no concept of private in C.
It would be a mistake to reimplement SCIP in C++. There are things in SCIP
that are well-justified in C, but don't translate into C++ such that it
feels comfortable. Only the algorithmic ideas can survive such a transition.

This discussion surely escalated quickly. It was never my plan to convince
you of the superiority of C++. However I simply can't accept all together
wrong statements as justification for the choice of programming language
(independent on the language, I wouldn't accept "C++ is great at processing
strings" as well). There may be good reasons for that, but neither "C
compiles faster" nor "C++ was changing too much in 2002" are valid
statements. I was generally looking for answers on a scientific level (to
all of my questions), not for personal opinions.

@Thorsten You're still welcome to answer the programming challenge, but
maybe we should do this off the list as this probably isn't of general
interest. After all, you probably want those 50€ from Timo, don't you? ;-)

Back to topics!

One of the two last topics still in discussion seems to be "int vs unsigned
int". There hasn't been an answer for that yet (recall, this is related to
methods such as SCIPgetN..., not for integer parameters or configurations
of constrainthandlers etc.).

Concerning inferinfo (the in my opinion second open topic)

> I do strongly disagree though on the claim that inferinfo is useless.
> The idea here is to have sizeof(int) many bits in which the constraint
handler/propagator can encode whatever information it
> needs to reconstruct what it did on the corresponding propagation step.
This can be an int, but does not need to, it can of
> course be casted back and forth. The reason to not wrap this is in any
bigger object is memory efficiency: There can be
> dozens or hundreds of bound changes at each node, and hundreds of
thousands of nodes in the whole B&B tree. You
> literally want so save every byte that you can.

Minor correction: you have sizeof(int) many bytes, not bits. But I'm sure
that's a typo.

Issues with that: it's int, so a _natural_ representation of indices is out
of question.
"it can of course be casted back and forth" this is one of the major
weaknesses of C (again). You have no type safety in that. Furthermore,
you're restricted to sizeof(int) wide data types which doesn't give an
advantage.
The question basically is "why not size_t?". size_t has the huge advantage
of being portable. You can always fit a pointer into it (maybe some more
information must be passed), yes with an ugly cast. This would enable the
user to pass lot's of information (again, you don't have to, but you're
able to) without any problems on 64bit machines. You also could have used a
void* instead. Same difference to int: Usable in infinite ways, capable of
at least the same.

Yes 2^32 (the usual number of distinct values in int) is a lot. If you have
a problem of size >= 85 and a family of constraint that uses 5 indices (not
_that_ uncommon) you have a unique representation that doesn't fit into
int. With 4 indices (even more common), you force a barrier at 256. And
surely we want to solve these problems as well and not just capitulate
because there's a missing byte in the encoding which the machine otherwise
provides. int does not scale.



I know that I've brought up several things most of you don't bother
thinking about. It is important to me, because I want to understand design
decisions for huge projects, just because there's always something to learn
from this. I think that this discussion lead to several things one can
easily change in SCIP _without_ breaking it, that improve some little
things. E.g. the naming conventions and enum replacing bool parameter
lists. This is easily added without the necessity of removing the stuff
you're already familiar with (though I'd recommend deprecating these).

Yours,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.zib.de/mailman/private/scip/attachments/20130702/e3c5e07c/attachment.html