coin-or / abacus

coin-or

Repository for organization-wide discussions and other organization documents.

abacus's Issues

Abacus - Wishlist from M. Chimani - University of Dortmund

Issue created by migration from Trac.

Original creator: mark.sprenger

Original creation time: 2008-07-31 09:20:05

Assignee: mark.sprenger

Version: 1.0

Keywords: wishlist

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: sub.cc to Frank

(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: done

(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

(changed by mark.sprenger at 2008-08-20 16:15:55)