[Scip] Design choices

[Nikolaj van Omme]

Hello list and Stefan,

While I'm not a SCIP developer (just a happy user) I would like to
respond to your points 4. and 8. as these design choices occur
frequently in big optimization projects. Dear SCIP developers and other
developers don't hesitate to correct me if I'm wrong or inaccurate.

4. The choice to let the solver own the created objects is quite
frequently used in production code. It allows the users not to worry
about the memory resources and even permits to optimize their use
because the solver knows best when to release memory or not and what to
do with the objects.

8. This choice is also very frequent in real optimization libraries. Big
functions and/or methods cannot be spitted without incurring an
indirection cost, hence very big files... Remember that when you
optimize, you are more concerned about the running times than the
compile times...

Best regards,

Nikolaj

On 06/27/2013 11:13 AM, Stefan Lörwald wrote:
> Dear SCIP developers,
> 
> I've been using SCIP for a while now, mainly using it as branch-and-cut
> framework. There are a couple of oddities that have puzzled me and/or it
> took me a long time to remember how to use.
> 
> 1. Naming: why is it e.g. "SCIPsetObjlimit" with a lower case L?
> "objective" and "limit" are two words which should use camel case as your
> general naming convention implies.
> 
> 2. Why is "SCIPallocMemory" a macro while not written in upper case only?
> Without a surrounding "SCIP_CALL", this raises warnings, so this is not
> nice in functions that need to return something different than
> "SCIP_RETCODE", which is common in C++ code.
> 
> 3. With "SCIPgetSol(...)", why can one refer to the solution of a LP via
> "NULL"? My intuition says that with "NULL", there is no partial structure
> it is referring to, so I would expect to get the current _global_ solution.
> 
> 4. Concerning the C++ interface, it is mildly disturbing to have dynamic
> memory management in function calls, i.e. you have to construct objects
> with "new Object", without ever calling delete on them. This is considered
> bad practice in C++, which prefers the "RAII" idiom. "Whoever constructs an
> object,destroys it" should be obeyed. Why was this violated in SCIP? See
> your TSP example for reference. While it does not leak resources, it is not
> visible/obvious to the user since there is no "delete".
> 5. Why does "SCIPinfinity" take a "SCIP*" as argument? Shouldn't this be a
> compile time constant independent of any object?
> 
> Please do not take any of this as offensive, even if you are the
> responsible developer. It is meant as construct criticism and curiosity
> about design decision which I would have done otherwise. Personally, I
> would have implemented it in C++ right away, so here's my final question:
> 
> 6. What led to the decision developing in C?
> 
> And just to let you know (I wrote this in an earlier email which apparently
> wasn't submitted to the mailing list):
> 
> 7. Your code is not compliant with the C99 standard, since you use double
> underscores as prefix to identifiers (e.g. in your header include guards).
> Although it is unlikely to cause any trouble, they are reserved for the
> implementation of the C compiler. See section 7.1.3 "Reserved identifiers"
> from the 1999 C Standard or have a look at
> http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier(which
> ask about C++, but this applies to C as well, as mentioned in the
> best answer). I'd recommend either removing those double underscores or
> just use "#pragma once". it is widely supported and avoids name collision
> of include guards, but provides the same functionality.
> 
> Oh and just another small one coming to mind after browsing the source
> again:
> 
> 8. Why don't you split your source files into smaller ones? Incremental
> compilation time will drastically improve (especially for minor
> modifications). As a personal preference I try to keep the number of lines
> per file below 500, extreme cases have up to a thousand. Several thousand
> lines of code neither seems practical for compilation nor does it simplify
> coding.
> 
> Yours,
> Stefan
> 
> 
> 
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip
>