[Scip] Design choices

Thu Jun 27 18:15:02 MEST 2013

Hi Stephan,

There is an overhead in finding the right file... ;-) When you have a
powerful computer/cloud, most IDE find very quickly - even in huge files
- what you need, less so if you split the code in thousands of files...
not to mention collaboration troubles with lots of file.

But you're probably right, code (in general) could be more optimized for
readability and compiling times. ;-)

Best regards,

Nikolaj

On 06/27/2013 12:06 PM, Stefan Lörwald wrote:
> Hi Nikolaj,
> 
> thanks for your reply.
> 
> Concerning point 8, you said " Big functions and/or methods cannot be
> splitted". That's correct, but e.g. in scip.c there are 1118 functions
> (assuming that the style is consistent, I just searched for lines beginning
> with "{"). Each of this function could be (in theory) be compiled in its
> own compilation unit since it only needs to know the _headers_ of each
> function it uses. The point is not about splitting functions into smaller
> pieces, but about breaking apart huge files into smaller (still logical)
> units. There's no runtime overhead in having more compilation units. I
> don't say "use one file per function", but having such huge files isn't
> good either.
> 
> Yours,
> Stefan
> 
> 2013/6/27 Nikolaj van Omme <nikolaj at crt.umontreal.ca>
> 
>> 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
>>>
>> _______________________________________________
>> Scip mailing list
>> Scip at zib.de
>> http://listserv.zib.de/mailman/listinfo/scip
>>
> 