[Scip] Design choices

[Stefan Lörwald]

Hi,

I do understand that using INFINITY (the IEEE 754 float number)  is not
suitable because we want actual comparisons and -INFINITY as well. But why
not just DBL_MAX (or FLT_MAX)?

Yours,
Stefan

2013/6/27 Felipe Serrano <fserranom5 at gmail.com>

> Hi
>
> Just on the infinity (point 5). It is of course handy to be able to change
> the infinity value. Nobody says that 1e+20 is the best value for infinity,
> you may find that another one is better for your particular problem.
> If, for any reason, your instance is generating very big numbers and you
> want to try changing the 1e+20 to, say, 1e+21 then it is naturally better
> just to set a parameter than to change a number from the scip code.
>
>
> Best
>
> Felipe
>
>
> On Thu, Jun 27, 2013 at 8:27 PM, Stefan Lörwald <stefan.loerwald at gmail.com
> > wrote:
>
>> Hi Marc,
>>
>> 2013/6/27 Marc Pfetsch <pfetsch at mathematik.tu-darmstadt.de>
>>
>>>
>>>
>>> Hi Stefan!
>>>
>>> > 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.
>>>
>>> You are right - the naming convention would suggest SCIPsetObjLimit(),
>>> which is probably better. However, we considered objlimit as a single
>>> word here (this also happens for several other names) and I do not think
>>> it makes sense to change it.
>>>
>>
>> Well, consistency would be the keyword here. And it wouldn't harm if
>> SCIPsetObjlimit (and similar methods) are deprecated but still usable.
>>
>>>
>>> > 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.
>>>
>>> These are two questions. First, according to the coding rules, it should
>>> be SCIPALLOCMEMORY. Since memory functionality is used at many places, I
>>> suppose that it just looked ugly, so the lower case was used.
>>>
>>
>> Why not make it a function then? With a good compiler it would be inlined
>> anyway, so no overhead whatsoever.
>>
>>
>>>
>>> Second, SCIP_CALL is used for the SCIP internal error passing. If you do
>>> not like it, you do not have to use it (but at the loss of having a
>>> backtrace of SCIP functions). See also the SCIP introduction by
>>> Cornelius Schwarz (http://scip.zib.de/further.shtml), which provides a
>>> macro to use exceptions.
>>>
>>> Moreover, returning more than one argument is always complicated in
>>> C/C++. The price you have to pay for the SCIP error passing is that you
>>> need to return values via pointers.
>>>
>>
>> FYI, it's not in C++, just use a std::pair or std::tuple.
>>
>>
>>>
>>> > 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.
>>>
>>> Well, you would need two functions otherwise, so it was just easier to
>>> use NULL. It also comes in handy at several places in the code.
>>>
>>> But in principle, two different things get mixed up here: LP solutions
>>> (relaxations) and primal solutions.
>>>
>>
>> Can you please clarify? I don't see why two functions would be necessary.
>>
>>
>>>
>>> > 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".
>>>
>>> I am not sure whether I understand you correctly. If you want to delete
>>> the objects yourself, you can do so: See for example
>>> SCIPincludeObjConshdlr() - set deleteobject to TRUE.
>>>
>>
>> Ah, well i should have looked into the documentation for that one. That's
>> the reason I dislike boolean values in function calls by the way: The
>> purpose is not clear at all, better use enum.
>>
>>
>>>
>>> > 5. Why does "SCIPinfinity" take a "SCIP*" as argument? Shouldn't this
>>> be
>>> > a compile time constant independent of any object?
>>>
>>> The infinity value can in principle be changed, so it is not a compile
>>>  time value.
>>>
>>
>> What for?
>>
>>
>>>  > 6. What led to the decision developing in C?
>>>
>>> First, the predecessor SIP of SCIP was written in C. Second, the C++
>>> standard rapidly changed when the SCIP project started (2002), while C
>>> is quite stable (there is hardly any problem with SCIP and compilers).
>>>  Third, C can be compiled faster.
>>>
>>
>> "C can be compiled faster" I seriously doubt that ;-) Have you tried? I
>> just did with scip.c and it turns out it needs 11s with gcc and exactly the
>> same time with g++. Execution time is identical if the SCIP source code is
>> compiled as c++, so no downside from that perspective.
>> C++ did not change in 2002, in fact there was no change between 1999 and
>> 2011.
>>
>>
>> All the best,
>> Stefan
>>
>> _______________________________________________
>> Scip mailing list
>> Scip at zib.de
>> http://listserv.zib.de/mailman/listinfo/scip
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.zib.de/mailman/private/scip/attachments/20130627/928c8af2/attachment.html