[ABACUS-tickets] [A Branch-And-CUt System] #1: Abacus - Wishlist from M. Chimani - University of Dortmund
A Branch-And-CUt System
coin-trac at coin-or.org
Wed Aug 13 07:56:23 EDT 2008
#1: Abacus - Wishlist from M. Chimani - University of Dortmund
----------------------------+-----------------------------------------------
Reporter: mark.sprenger | Owner: mark.sprenger
Type: enhancement | Status: new
Priority: major | Milestone: milestone1
Component: component1 | Version: 1.0
Resolution: | Keywords: wishlist
----------------------------+-----------------------------------------------
Old description:
> ABACUS - Flaws and Wishes
>
> ----
>
> Die Zahlen (X/Y) in Klammern vor den Eintraegen gegeben die Wichtigkeit
> und die
> Geschaetzte Schwierigkeit an:
> X=[1,..,5]; 1="unbedingt noetig" bis 5="waere schoen/sinnvoll"
> Y=[1,..,5]; 1="einfach und schnell machbar" bis 5="aufwaendig"
>
> (1/?) Windows/VisualC++ 7.x/8.x/9.x Support:
> Es ist wichtig, dass Abacus auch unter Windows mit Visual C++
> kompiliert (dabei gibt es erfahrungsgemaess keine echten
> Unterscheide
> zwische Version 7 und 8), da OGDF Linux&Windows unterstützt.
> Update: Carsten hat es mit ein paar änderungen wohl irgendwie ans
> Laufen gebracht. Details dazu weiss im Moment nur er ;-)
>
> ''status: contact''
>
> (1/1) GCC Makefiles:
> Erfahrungsgemaess ist -O3 bei GCC leider hoffnungslos. Sogar die
> eigenen
> Webseiten beschreiben es als "experimental" - und tatsaechlich
> entstehen
> dadurch in Abacus Bugs. Sogar bei "-O2" haben wir bei
> komplizierteren
> OGDF Algorithmen probleme, so dass wir nur -O1 einschalten.
>
> ''status: changed to -O2''
>
> (1/1) & (4/4) Exit & Exceptions:
> Abacus beendet sich bei jedem Fehler einfach mit exit. Das ist
> natürlich
> unschön, wenn Abacus als Teil einer anderen Bibliothek läuft, und
> das
> ganze programm beendet. Daher brauchen wir wohl oder übel
> Exception
> Handling notwendig (siehe auch schon im CWeb vorhandener alter
> Original-
> Kommentar)
> 1) (1/1) Einfache erste Version: statt mit "exit" einfach mit
> "throw"
> rausspringen. Am einfachsten in abacusroot::exit() das
> eigentliche
> exit auf throw aendern.
> 2) (4/4) Komplexere (spaetere?) Variante: Variante 1 ist
> unsauber, da
> der ganze Abacus-Speicher dann nicht freigegeben! - Darum
> muessten sich
> die Destruktoren der Abacus-Objekte am Stack kuemmern. Ich glaube
> nicht
> das sie das im Moment sauber tun, nachdem da froehliche
> Warnmeldungen
> kommen...
>
> ''status: working''
>
> (BUG/1) compress & expand (in ABA_CONVAR, convar.h) [A]:
> Die eigentlich privat gemeinten Funktionen _compress, _expand
> sind
> public. Besonders dringlich ist vorallem auch, dass die
> *virtuellen*
> Funktionen deletable(), expand() und compress() *private* sind.
> Diese dienen eigentlich dazu, dass diese Funktionalitaeten
> implementiert
> werden koennen (in dem man sie in seinen abgeleiteten Klassen
> ueberschreibt).
>
> ''status: done''
>
> (2/1) compress & expand (in ABA_CONVAR) [B]:
> verursachen zeitweise bei Pricing überflüssige Warnungsmeldungen
> (die
> dank automatischem flush auf cerr Laufzeit verbraten). Die
> Warnungsmeldungen kann man gefahrlos einfach streichen, da sie
> falsch
> sind (Abacus ruft faelschlicherweise compress auf komprimierten
> Objekten auf, etc.) -- zumal diese Funktionen derzeit ohnehin nie
> benutzt werden konnten wegen oberhalb beschriebenem Bug.
>
> ''status: done (durch den obrigen FIX)''
>
> (2/2) Namespace:
> Es wäre sauberer, wenn Abacus einfach einen eigenen Namespace
> "abacus"
> definieren würde, statt alle Klassen mit ABA_ starten zu
> lassen. (Als Abacus entwickelt wurde, hat das wohl noch nicht auf
> allen
> Compilern funktioniert). Darueber hinaus wär es homogener mit
> allen
> anderen "modernen" Bibliotheken, wenn die Klassen nicht in All-
> Caps
> bezeichnet wären. Also statt ABA_MASTER einfach abacus::Master,
> etc.
>
> ''status: later''
>
> (2/5) Const Correctness:
> war noch kein grosses Thema als Abacus damals zum ersten Mal
> geschrieben
> wurde. Inzwischen kennt man die Vorteile und quasi alle modernen
> Bibliotheken halten sich daran (mehr oder weniger). So auch OGDF.
> Das Problem ist, dass nicht const-corr Bibliotheken (wie Abacus)
> infektioes sind, bzw. "unconst"-casts. Das zerstoert dadurch auch
> die
> const-corr. unseres OGDF und zwingt uns zu unschoenem unsauberen
> Code.
>
> ''status: later''
>
> (3/1) Timeout funktioniert nicht richtig:
> Timeout bricht im Moment nur "hin und wieder" ab, naemlich nur
> wenn
> separate und pricing ohne etwas zu tun durchlaufen (zB beim
> Selektieren
> eines neuen Subproblems). Wenn er aber lange _innerhalb_ eines
> Subproblems arbeitet, nicht. Das fürht zB dazu dass ein Job mit
> 30min
> Beschraenkung auch mal ueber 800 Minuten läuft.
> Dies passiert weil in der while Schleife der Check zwar drin
> steht,
> aber vorher auch gerne immer mal wieder 'continue' aufgerufen
> wird...
> => der Zeitcheck muss also VOR dem solveLP Aufruf passieren,
> statt am
> Ende der Schleife
>
> ''status: working''
>
> (3/1) CpuTime-Limit-Setting:
> ist derzeit durch einen String gegeben. Sowas hätten wir gerne
> mit einem
> einfachen Aufruf der Art "set(int hour, int min, int sec)"
> gelöst.
> Der String ist einfach ineffizient und kompliziert, weil man
> selber
> immer integer zahlen in formatierte Strings umrechnen muss, und
> Abacus
> intern dann auch wieder den String umwandelt...
>
> ''status: working''
>
> (3/2) Speicher-Limit erreicht:
> Wenn CPLEX der Speicher ausgeht (zB bei CPXdualopt) wird derzeit
> nicht
> "normal" abgebrochen und das vorhandene Status-Flag gesetzt,
> sondern
> "exit" aufgerufen... -> siehe auch "Exit&Exceptions"
>
> ''status: later''
>
> (5/1) Make-settings:
> Es wird nur gcc3.3, 3.4, 4.1 unterstuetzt. Im Make-settings
> Unterverzeichnis gibt es aber noch settings füg uralte egcs, gcc,
> etc.
>
> ''status: done''
>
> (1/1) Preprocessor Flag ABAUCS_COMPILER_GCC, ABACUS_COMPILER_GCCxx:
> alle Versionsnummern verhalten sich gleich. Wozu?
> Das Flag ohne Versionsnummer funktioniert derzeit uebrigens nicht
> richtig, da dafuer ABACUS_NEW_TEMPLATE_SYNTAX nicht gesetzt
> wird...
>
> ''status: done''
>
> (1/1) Preprocessor Flag ABACUS_SYS_SOLARIS, ABACUS_SYS_LINUX:
> Es gibt nur diese beiden Systeme, und die werden nie
> unterschieden...
> Apropos: man kann das System und den Compiler (inkl. Version)
> direkt
> durch vom Compiler vordefinierte Preprocessor-Flags abfragen.
> "Eigene"
> Flags dafür sind nicht (mehr) nötig, und führen im Zweifelsfall
> nur zu
> falschen Settings.
>
> ''status: done''
>
> (4/2) Preprocessor Flag ABACUS_NO_FOR_SCOPE:
> Diese Dinge machen den Code leider sehr hässlich und
> fehleranfaellig.
> Einfacher und klarer ist es zB nach dem Muster:
> int i;
> for(i=0; i<..;++i) {}
> for(i=0; i<..;++i) {}
> for(i=0; i<..;++i) {}
> Das funktioniert mit jedem Compiler.
>
> ''status: done''
>
> (5/1) Preprocessor Flag ABACUS_PARALLEL:
> Ist das im Code noch wichtig, und funktioniert es richtig?
> (Vielleicht
> weiss Christoph oder Frauke das?). Auch vor dem Hintergrund:
> wenn's
> wiedereinmal jemand angreift, muss derjenige das ggf. ohnehin
> komplett
> neu machen?
>
> ''status: done''
>
> (5/1) Preprocessor Flag SUN-CC:
> ist der Cun-CC notwendig und getestet? Den benutzt ja
> niemand mehr, oder? Der Code wuerde uebersichtlicher werden
> ohne...
> Insbesondere koennte man sich ABACUS_NEW_TEMPLATE_SYNTAX dann
> ggf.
> sparen. (offiziell wird der Compiler eh nicht mehr supportet.)
>
> ''status: done''
>
> (5/1) Preprocessor Flag ABACUS_NO_BOOL:
> wird nur benutzt um den Typ ABACUS_BOOL zu definieren.
> Der wird dann nie verwendet.
>
> ''status: done''
>
> (5/1) Preprocessor Flag ABACUS_OLD_NEW:
> wird nur an 2 Stellen benutzt... und eine der beiden Varianten
> (die mit dem typedef) funktioniert immer. Flag schreichen und nur
> die
> eine Codevariante wäre übersichtlicher?
>
> ''status: done''
New description:
ABACUS - Flaws and Wishes
----
Die Zahlen (X/Y) in Klammern vor den Eintraegen gegeben die Wichtigkeit
und die
Geschaetzte Schwierigkeit an:
X=[1,..,5]; 1="unbedingt noetig" bis 5="waere schoen/sinnvoll"
Y=[1,..,5]; 1="einfach und schnell machbar" bis 5="aufwaendig"
(1/?) Windows/VisualC++ 7.x/8.x/9.x Support:
Es ist wichtig, dass Abacus auch unter Windows mit Visual C++
kompiliert (dabei gibt es erfahrungsgemaess keine echten
Unterscheide
zwische Version 7 und 8), da OGDF Linux&Windows unterstützt.
Update: Carsten hat es mit ein paar änderungen wohl irgendwie ans
Laufen gebracht. Details dazu weiss im Moment nur er ;-)
''status: contact''
(1/1) GCC Makefiles:
Erfahrungsgemaess ist -O3 bei GCC leider hoffnungslos. Sogar die
eigenen
Webseiten beschreiben es als "experimental" - und tatsaechlich
entstehen
dadurch in Abacus Bugs. Sogar bei "-O2" haben wir bei
komplizierteren
OGDF Algorithmen probleme, so dass wir nur -O1 einschalten.
''status: done (changed to -O2)''
(1/1) & (4/4) Exit & Exceptions:
Abacus beendet sich bei jedem Fehler einfach mit exit. Das ist
natürlich
unschön, wenn Abacus als Teil einer anderen Bibliothek läuft, und
das
ganze programm beendet. Daher brauchen wir wohl oder übel
Exception
Handling notwendig (siehe auch schon im CWeb vorhandener alter
Original-
Kommentar)
1) (1/1) Einfache erste Version: statt mit "exit" einfach mit
"throw"
rausspringen. Am einfachsten in abacusroot::exit() das eigentliche
exit auf throw aendern.
2) (4/4) Komplexere (spaetere?) Variante: Variante 1 ist unsauber,
da
der ganze Abacus-Speicher dann nicht freigegeben! - Darum muessten
sich
die Destruktoren der Abacus-Objekte am Stack kuemmern. Ich glaube
nicht
das sie das im Moment sauber tun, nachdem da froehliche
Warnmeldungen
kommen...
''status: working''
(BUG/1) compress & expand (in ABA_CONVAR, convar.h) [A]:
Die eigentlich privat gemeinten Funktionen _compress, _expand sind
public. Besonders dringlich ist vorallem auch, dass die
*virtuellen*
Funktionen deletable(), expand() und compress() *private* sind.
Diese dienen eigentlich dazu, dass diese Funktionalitaeten
implementiert
werden koennen (in dem man sie in seinen abgeleiteten Klassen
ueberschreibt).
''status: done''
(2/1) compress & expand (in ABA_CONVAR) [B]:
verursachen zeitweise bei Pricing überflüssige Warnungsmeldungen
(die
dank automatischem flush auf cerr Laufzeit verbraten). Die
Warnungsmeldungen kann man gefahrlos einfach streichen, da sie
falsch
sind (Abacus ruft faelschlicherweise compress auf komprimierten
Objekten auf, etc.) -- zumal diese Funktionen derzeit ohnehin nie
benutzt werden konnten wegen oberhalb beschriebenem Bug.
''status: done (durch den obrigen FIX)''
(2/2) Namespace:
Es wäre sauberer, wenn Abacus einfach einen eigenen Namespace
"abacus"
definieren würde, statt alle Klassen mit ABA_ starten zu
lassen. (Als Abacus entwickelt wurde, hat das wohl noch nicht auf
allen
Compilern funktioniert). Darueber hinaus wär es homogener mit
allen
anderen "modernen" Bibliotheken, wenn die Klassen nicht in All-
Caps
bezeichnet wären. Also statt ABA_MASTER einfach abacus::Master,
etc.
''status: later''
(2/5) Const Correctness:
war noch kein grosses Thema als Abacus damals zum ersten Mal
geschrieben
wurde. Inzwischen kennt man die Vorteile und quasi alle modernen
Bibliotheken halten sich daran (mehr oder weniger). So auch OGDF.
Das Problem ist, dass nicht const-corr Bibliotheken (wie Abacus)
infektioes sind, bzw. "unconst"-casts. Das zerstoert dadurch auch
die
const-corr. unseres OGDF und zwingt uns zu unschoenem unsauberen
Code.
''status: later''
(3/1) Timeout funktioniert nicht richtig:
Timeout bricht im Moment nur "hin und wieder" ab, naemlich nur
wenn
separate und pricing ohne etwas zu tun durchlaufen (zB beim
Selektieren
eines neuen Subproblems). Wenn er aber lange _innerhalb_ eines
Subproblems arbeitet, nicht. Das fürht zB dazu dass ein Job mit
30min
Beschraenkung auch mal ueber 800 Minuten läuft.
Dies passiert weil in der while Schleife der Check zwar drin
steht,
aber vorher auch gerne immer mal wieder 'continue' aufgerufen
wird...
=> der Zeitcheck muss also VOR dem solveLP Aufruf passieren, statt
am
Ende der Schleife
''status: working''
(3/1) CpuTime-Limit-Setting:
ist derzeit durch einen String gegeben. Sowas hätten wir gerne mit
einem
einfachen Aufruf der Art "set(int hour, int min, int sec)" gelöst.
Der String ist einfach ineffizient und kompliziert, weil man
selber
immer integer zahlen in formatierte Strings umrechnen muss, und
Abacus
intern dann auch wieder den String umwandelt...
''status: working''
(3/2) Speicher-Limit erreicht:
Wenn CPLEX der Speicher ausgeht (zB bei CPXdualopt) wird derzeit
nicht
"normal" abgebrochen und das vorhandene Status-Flag gesetzt,
sondern
"exit" aufgerufen... -> siehe auch "Exit&Exceptions"
''status: later''
(5/1) Make-settings:
Es wird nur gcc3.3, 3.4, 4.1 unterstuetzt. Im Make-settings
Unterverzeichnis gibt es aber noch settings füg uralte egcs, gcc,
etc.
''status: done''
(1/1) Preprocessor Flag ABAUCS_COMPILER_GCC, ABACUS_COMPILER_GCCxx:
alle Versionsnummern verhalten sich gleich. Wozu?
Das Flag ohne Versionsnummer funktioniert derzeit uebrigens nicht
richtig, da dafuer ABACUS_NEW_TEMPLATE_SYNTAX nicht gesetzt
wird...
''status: done''
(1/1) Preprocessor Flag ABACUS_SYS_SOLARIS, ABACUS_SYS_LINUX:
Es gibt nur diese beiden Systeme, und die werden nie
unterschieden...
Apropos: man kann das System und den Compiler (inkl. Version)
direkt
durch vom Compiler vordefinierte Preprocessor-Flags abfragen.
"Eigene"
Flags dafür sind nicht (mehr) nötig, und führen im Zweifelsfall
nur zu
falschen Settings.
''status: done''
(4/2) Preprocessor Flag ABACUS_NO_FOR_SCOPE:
Diese Dinge machen den Code leider sehr hässlich und
fehleranfaellig.
Einfacher und klarer ist es zB nach dem Muster:
int i;
for(i=0; i<..;++i) {}
for(i=0; i<..;++i) {}
for(i=0; i<..;++i) {}
Das funktioniert mit jedem Compiler.
''status: done''
(5/1) Preprocessor Flag ABACUS_PARALLEL:
Ist das im Code noch wichtig, und funktioniert es richtig?
(Vielleicht
weiss Christoph oder Frauke das?). Auch vor dem Hintergrund:
wenn's
wiedereinmal jemand angreift, muss derjenige das ggf. ohnehin
komplett
neu machen?
''status: done''
(5/1) Preprocessor Flag SUN-CC:
ist der Cun-CC notwendig und getestet? Den benutzt ja
niemand mehr, oder? Der Code wuerde uebersichtlicher werden
ohne...
Insbesondere koennte man sich ABACUS_NEW_TEMPLATE_SYNTAX dann ggf.
sparen. (offiziell wird der Compiler eh nicht mehr supportet.)
''status: done''
(5/1) Preprocessor Flag ABACUS_NO_BOOL:
wird nur benutzt um den Typ ABACUS_BOOL zu definieren.
Der wird dann nie verwendet.
''status: done''
(5/1) Preprocessor Flag ABACUS_OLD_NEW:
wird nur an 2 Stellen benutzt... und eine der beiden Varianten
(die mit dem typedef) funktioniert immer. Flag schreichen und nur
die
eine Codevariante wäre übersichtlicher?
''status: done''
--
Ticket URL: <https://projects.coin-or.org/ABACUS/ticket/1#comment:3>
A Branch-And-CUt System <https://projects.coin-or.org/ABACUS>
ABACUS - A Branch-And-CUt System
More information about the ABACUS-tickets
mailing list