[Scip] Design choices

[Stefan Lörwald]

Hi Michael,

>>>> [Concerning SCIPinfinity]
>>> It might be, that you really need such huge values, and this SCIP
 >>> parameter is really changed in some projects. DBL_MAX or something
 >>> similar
 >>> cannot be exceeded and also therefore makes computations much harder.
 >>> Also, you will lose accuracy and even get wrong results when working
 >>> with
 >>> really big values, meaning it does not really make sense to increase
the
 >>> infinity value to the maximal possible value.
 >>
 >> I do not understand how this could happen. Can you please demonstrate
this
 >> behaviour?
>
> For example adding 1 to 1e20 will result in 1e20.

Yeah, I do understand floats, but why should you calculate inf + 1 anyway?
That's a rather useless "example". What about real world (SCIP!) code where
it actually makes a difference between 1e20 or a constant closer to (or)
DBL_MAX and 1e20 is better.
>>> [Concerning the choice of programming language]
> > I agree, Assembler is just insane. Marcs statement was "C compiles
faster
> > than C++". I did check that this is wrong by compiling SCIP as C++. If
you
> > insist on this being true, please demonstrate.
>
> The statement that C code will compile faster than C++ cannot be falsified
> by compiling only C code with gcc or g++ and also not by only using these
> compilers once and only on one test case.
>

Well, again, let's just try and compare to values. This time for the
_whole_ SCIP suite.

Time compiling SCIP as C: 3min42s

Time compiling SCIP as C++: 3min43s

So in case of the whole SCIP source, C has a negligible advantage, probably
not reproducible. That doesn't prove anything concerning which language
compiles faster, but I didn't even try to. I just showed that this _general
statement_ about C being faster at compile time is wrong. Maybe this was
true in connection with some C++ compilers in the dark ages of 2002, but it
certainly isn't valid reasoning today.

Compilation time mostly depends on code size. As idiomatic C++ code is
usually drastically shorter...

>> 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 still need to distinguish between the LP/pseudo solution and
 > primal solutions or everytime working with the LP/pseudo solution you
need
 > to distinguish youself and ask for these solutions to pass them to the
 > above method. And as Marc already wrote, it comes in handy in the SCIP
 > core that NULL is pointing to the LP/pseudo solution.

There are _many_ nodes and just _one_ currently best global solution. This
immediately suggest using the one value NULL as global, and specific ones,
namely connecting to a node, for the LP.

It might be handy in the SCIP core _now_, but I doubt this will be good for
the future. In our area, practically every problem is so difficult that
sequential algorithms are doomed to fail terribly without hope since the
next generation of hardware may be vastly improved, but it still only
suffices for a tiny improvement in terms of practically solvable problem
instances. The need for parallelization is outrageously evident although
still this is limited.

But what if we can develop an efficient way of parallelizing
branch-and-cut? I know that this is extremely difficult, but let's just
imagine. So you probably solve two cleverly picked nodes at the same time.
Which solution does the currently working method refer to? Sure, NULL as in
"the current LP solution". Failure. There are two current LP solutions.
NULL is never a good value to refer to a specific construct.


 > Using enums for a really long list of boolean parameters that have
 > something in common as in the example above might be useful. I think, as
 > Benjamin has already written, the parameter list increased during the
 > development of SCIP.

Here's an idea: Provide both options and deprecate the list of boolean
values.

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