Opened 12 years ago

Closed 6 weeks ago

#1 closed enhancement (migrated)

Abacus - Wishlist from M. Chimani - University of Dortmund

Reported by: mark.sprenger Owned by: mark.sprenger
Priority: major Milestone: milestone1
Component: component1 Version: 1.0
Keywords: wishlist Cc:

Description (last modified by mark.sprenger)

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

Attachments (1)

Abacus-Wishlist.txt (6.7 KB) - added by mark.sprenger 12 years ago.
ABACUS Wishlist as plain text

Download all attachments as: .zip

Change History (6)

Changed 12 years ago by mark.sprenger

ABACUS Wishlist as plain text

comment:1 Changed 12 years ago by mark.sprenger

  • Description modified (diff)

comment:2 Changed 12 years ago by mark.sprenger

  • Description modified (diff)

comment:3 Changed 12 years ago by mark.sprenger

  • Description modified (diff)

comment:4 Changed 12 years ago by mark.sprenger

  • Description modified (diff)

comment:5 Changed 6 weeks ago by stefan

  • Resolution set to migrated
  • Status changed from new to closed

This issue has been migrated to GitHub and will be resolved there: https://github.com/coin-or/ABACUS/issues/1

Note: See TracTickets for help on using tickets.