Progress Kroeker
From CRCG-Wiki
Hinweise zum Centerfocus-Projekt:
siehe Centerfocus FAQ
Todo- Liste
siehe ToDo Kroeker
Fortschritt:
24.12.2011
Schnittstelle in GAP zur Polynomsuche mit vorgegebener Multiplizitätsstruktur fertiggestellt
27.10.2011
Polynomsuche mit vorgegebener Multiplizitätsstruktur:
Alle Schritte automatisiert.
Normalisierung für Fälle mit mehr als drei Verzweigungspunkten evtl. noch nicht korrekt.
18.10.2011
Polynomsuche mit vorgegebener Multiplizitätsstruktur:
Basistransformation implementiert
17.10.2011
Polynomsuche mit vorgegebener Multiplizitätsstruktur:
-Für Parallelisierung vorbereitet
-Sonderfälle bei der Suche behandelt
14.10.2011
Projekt "Schnelle lineare Algebra in Macaulay2"
5.10.2011
GPU Programming Tutorial in Jena besucht
14.9.
Schreib dir das hinter die Ohren: sage befindet sich auf den Gaussrechnern unter /opt, Macaulay2 unter /usr/local
1.8.2011
p-adischen Lift-Algorithmus (bei vorgegebenem System von Gleichungen) in Magma programmiert.
29.7.2011
Polynom mit vorgegebener Multiplizitätsstruktur in Charakteristik 11 nach Charakteristik 0 geliftet
1.7.2011
README und Link auf stud-hannover server zu centerfocus doku korrigiert
fehlerhafte charakteristik 61 Ergebnisse aus der DB entfernt
Herausgefunden, wie man fuer Givaro::Extension das mod Polynom angibt http://wiki.macaulay2.com/Macaulay2/index.php?title=Givaro_interface
21.06.2011 Neue Magma version installiert, damit die Magma-Entwickler in der Lage sind die eventuell gefundenen Fehler nachzuvollziehen.
17.06.2011 Das Checkpointing System DMTCP wurde auf den Gaussservern installiert.
15.06.2011 Linbox-Team und FFPACK-Team auf ein Problem mit der Lizensierung LGPL 2.0 (1991) hingewiesen. (Kompatibilitätsmatrix; statisches Linken und Code-Nutzung nicht möglich)
12.04.2011 Erkenntniss: 'magma.exe' startet schneller als 'magma', weil 'magma' ein bash script ist.
31.03.2011
Zwei kleine Fehler in Macaulay2 gefunden und auf http://groups.google.com/group/macaulay2/topics gepostet.
29.03.2011
Erste Sitzung betreffend der Integration von FFPACK in Macaulay2
25.03.2011
Schnittstelle zur Korrektur der Kodimension auch zu Macaulay2.
23.03.2011
Adjazensmatrix fuer NestedCanalizingFunctions aus '.dot' -Datei unter Verwendung von PyGraphviz
16.03.2011
Fehler bei der Ausgabe der ersten Quadrik der Quadriklisten behoben
14.03.2011
Fragen zum C-Code von Student von Prof. Mihailescu geklärt.
16.02.2011
Die ersten Datensätze mit der Korrektur der Kodimension purzeln in die TestDatenbank. Die Arbeit ist aber noch nicht ganz getan
14.02.2011
Den maximalen Speicherverbrauch eines Prozesses unter Linux ist gar nicht so einfach festzustellen.
Nach einer längeren Recherche hatte ich dann das Glück auf das Tool 'tstime' zu stoßen.
24-27.01.2011
-Betriebssystem-timeout für Programmaufrufe zur Berechnung der Kodimension-Korrektur angewendet
-Ausgabeformat zur Kodimension-Korrektur festgelegt
-Magma-Aufruf aus Macaulay heraus
-MagmaAPI 'decomposeCone': Idealzerlegung , Zeitmessung , maximaler Speicherverbrauch
17-21.01.2011
-Eintragen von Ergebnissen im neuen Format.
-Anzeigen in der DB gespeicherter Punkte bei Statistikabfragen.
-Wrapper um Eintrageskript wird atomar ausgeführt.
-Version des Eintrageskripts wird jetzt in der DB mitgespeichert.
-centerfocusWiki-Login über SSL eingerichtet(nicht sichtbar, da das Login-Fenster im Frame geöffnet wird.)
-installierte phpMyAdmin-Version aktualisiert
-Webseite für die Auflistung von Abschlussarbeiten vorbereitet
10-14.01.2011
-Server auf Ubuntu 8 aktualisiert/Migration abgeschlossen
-Im centerfocus-Wiki kann man jetzt auch techen.
7.1.2011
test target im Makefile erstellt
Ordner mit Testroutinen verschoben
Gegenzählung bei Anzahl verschwundener Strudelgrößen in der Statistikabfrage hinzugefügt.
Dezember 2010
Zählung normalisierter Differentialformen programmiert.
-WWW-Server Update vorbereitet(partielle Datensicherung erstellt)
-Preprint korrekturgelesen
-Einstieg in Magma und Singular
-Performance der Primärzerlegung von Singular, Magma und Macaulay exemplarisch verglichen
30.11.2010
Für Punkte auf der Hamilton-Komponente und für Punkte mit Quadriklisten wird der Glattheitstest jetzt implizit (viel schneller) durchgeführt.
29.11.2010
Die Funktion sum() in Mysql 4.1.12 rechnet mit double statt mit Int_64. Damit korrekt gerechnet wird und eine Konvertierung nach DECIMAL funktioniert, muss die Server-Software aktualisiert werden.
19.11.2010 centerfocus.de IE8-kompatibel gestaltet (kein const-Schlüsselwort in JavaScript)
18.11.2010 centerfocus.de Safari3-kompatibel gestaltet.
17.11.2010 centerfocus.de Firefox-3.6-kompatibel.
11.11.2010
Fehler in Statistikabfragen korrigiert (wenn man im abfrageformular 'VanishedFocalValues' < maxFocalValues setzt), waren Abfragen bisher falsch.
Seiten für 'www.centerfocus.de' entworfen.
5.11.2010
Ab jetzt werden nicht nur Punkte mit jacobiRang>9, sondern auch Punkte von jeder Art (Rang Jacobi-Matrix, ) anteilmäßig gespeichert und zwar derart dass die Datenbank nicht überfüllt wird
2.11.2010
Kurzvortrag über CodeCoverage-Tools vorbereitet
Punktfilter wurde getestet.
18.10.2010
neuen Punkt-Filter implementiert, Dokumentation und Regressionstest stehen aus
27.09.2010
Starte Arbeit am Installer
22.09.2010
Punkte aus regulären Experimenten lassen sich jetzt aus der Datenbank abfragen
21.09.2010
Habe die ComboBox-Komponente für die Punkt- und Statistikabfrage aus dem Netz repariert/angepasst.
14.09.2010
Kurzvortrag für den Singular-Workshop in Kaiserslautern (15-17 Sep) vorbereitet
20.08.2010
16.08.2010
SSQL Abfrage wird jetzt in einem scrollbaren Fenster angezeigt.
12. 08.2010
Lift-Statistik Formular erstellt. Bei den Statistikabfragen Hinweise hinzugefuegt.
11. 08.2010
Im Punktabfrageformular den Glattheitsfilter aktualisiert.
09.08.2010
Die Treppe im Nebengebäude wird saniert. Dann arbeite ich halt von zu Hause aus.
4.8.2010
Hamiltonkomponentenfilter dokumentiert. Onlinedokumentation aktualisiert.
02.08.2010 Timer funktioniert jetzt auch mit MTCP-Checkpointing. Allerdings liefert der Valgrind-Test von mtcp_restart einige Warnungen. Da haben die Leute von DMTCP doch nicht ganz ordentlich gearbeitet...ob BLCR besser ist?
30.07.2010 Datenbank gesichert
29.07.2010
Test für cfList geschrieben
An der Dokumentation für Checkpointing und atomares Erzeugen der Ausgabedateien gearbeitet.
Tabelle zum Dokumentationsstatus erzeugt.
27.07.2010 Atomares erzeugen der Ausgabedateien funktioniert jetzt Dateisystemweit für einen Benutzer, was für die Projekterfordernisse ausreichend ist.
26.07.2010
Glattheitsinformation für alle Punkte in der DB berechnet und in DB eingetragen
21.07.2010
Korrektur der Statistik bei Verwendung des Filters für Hamiltonkomponenten implementiert.
20.07.2010
Struktur für Integralkurvenstatistik-Tabelle entworfen
19.07.2010
Programm um Checkpointing erweitert
16.07.2010
interne Gattheistatistik kann jetzt für jede Kodimension der Punkte getrennt geführt werden.
14.07.2010
Statistik kann für Punkte auf der Hamiltonkomponente bzw. für Punkte nicht auf der Hamiltonkomponente abgefragt werden.
09.07.2010
Sonderfall Integralkurvenberechnung implementiert.
07.07.2010
Beim Überprüfen von Punkten mit Glattheitstest (maxLift=14, liftTrials=4, minVanishedFocalValues=9, minJacobianRank=0) ergibt sich auf einem CPU-Kern( Gauss-Rechner) aktuell ein virtuellen Durchsatz von
- 1220 Mio. Punkte /sek. ohne Glattheitstest
- 65 Mio. Punkte /sek. mit Glattheistest
- 630 Mio. Punkte /sek. mit Glattheistest, wenn Punkte auf der
Hamilton-Komponente ausgenommen werden.
Dies bedeutet, dass auf 56 CPU-Kernen das Testen
-aller Punkte ohne Glattheitstest _2 Monate_
-aller Punkte mit Glattheitstest _37 Monate_
-aller Punkte, die nicht auf der Hamilton-Komponente liegen, mit
Glattheitstest _4 Monate_
dauern würde.
23.06.2010
Einlesen der Parameter für den Integralkurven-Algorithmus funktionsfähig, allerdings noch nicht perfekt.
22.06.2010
Das Einlesen der Parameter für den Integralkurven-Algorithmus muss als nächstes programmiert werden. Kofaktoren können naturlich vorerst nur in Macaulay berechnet werden.
18.06.2010
Arbeite am Integralkurven-Algorithmus.
Glattheitstests kosten etwa doppelt so viel Zeit als am 25.05. gemessen - die Messung am 25.05. war leider nicht korrekt.
10.06.2010
Ausarbeiten der ersten Stufe des Frommer-Algorithmus brachte dann tzotz Wegfall von mehreren Rechenoperationen keinen Vorteil. Die erste Beobachtung basuerte auf einem Programmierfehler.
Fazit Optimierung: die Laufzeit des Frommer-Algorithmus konnte ohne Einsatz von OpenCL nochmals um 30 Prozent verbessert werden.
Auf Lange Sicht kann eine wesentliche Verbesserung der Laufzeit (Größenordnungen) nur durch Einsatz von Grafikkarten erreicht werden.
09.06.2010
Verschiebung der Division brachte eine Laufzeitverbesserung von 15 Prozent.
3.06.2010
Zeitmessung fuer Version 249:
bei 4 Mio Formel23-Versuchen eine Dauer von 104 Sekunden
73 Sek. Formel23-Anteil,
davon kostet
- die Berechnung der a-Koeffizienten 30%
- die Berechnung der b-Koeffizienten fuer a1 nicht Null 55%
von den 73 Sekunden Formel23-Anteil fallen 47 Sek. auf den Frommer-Algorithmus.
Die normale Punktprüfung dauert nochmal 26 Sekunden.
Insgesamt fallen auf den Frommer-Algorithmus c.a. 73 Sekunden.
Unter der Annahme, dass sich die Laufzeit des Frommer-Algorithmus durch die Verwendung der Multimedia-Register um 1/3,1/2, 2/3 oder 3/4 reduzieren lässt,
wäre die Gesamtverbesserung 32, 56, 90 oder 115 Prozent.
25.05.2010
Berechnungen pro Sekunde:
| c.a. | _1500_ | Jacobi-Matrizen |
| c.a. | _65_ | Quadriklisten |
| c.a. | _14_ | Glattheitstests |
21.05.2010
SSE-Optimierung an der Glattheitsberechnung ausprobiert. Merkbare Verbesserung tritt erst bei großen maxLift-Werten auf .
In einer Sekunde können etwa drei Punkte überprüft werden. Für Punkte mit Kodimension >=7 könnte die Glattheitsstatistik noch erfasst werden, ohne großen Performanceverlust in Kauf zu nehmen (c.a. 5 %).
( In einem Monat beträgt das Aufkommen von Punkten mit Kodimension>=7 c.a. 20 Mio. Diese auf 56 Rechnern auf Glattheit zu überprüfen würde etwa 30 Stunden dauern. )
05.05.2010
Die Ausgabedatei kann jetzt wiederum als Eingabe dienen.
Manuelle Messung der Dauer des Glattheitstests durchgeführt:
der Glattheitstest mit optimalen Parametern dauert für drei Punkte etwa eine Sekunde.
Damit kann man mit der gegenwärtigen Performance die Idee verwerfen, für alle Punkte den Glattheitstest durchzuführen.
Für alle Punkte mit allen Strudelgrößen gleich Null würde der Test auf 56 Rechnern ebenfalls 3-6 Jahre dauern.
Lässt man Punkte mit Kodimension <6 weg, ist der Test allerdings realistisch durchführbar.
04.05.
Weitere automatisch wiederholbare Tests vorbereitet. Zwei kleine Fehler durch Tests gefunden; diese hatten auf die Ergebnisse keinen Einfluß.
03.05.2010
Ausgabe eines Punkts samt Eigenschaften von dem restlichen Ablauf getrennt. Neuen Parameter 'minComponentsCodim' eingeführt
27.04.2010
Fragen zum Integralkurvenprojekt geklärt.
22.04.2010
Frommer Basis-Algorithmus in Macaulay implementiert, allerdings noch nicht als Paket bereitgestellt.
12.04.2010
Neues Formular für die Statistikabfragen fertiggestellt.
Dies muss noch dokumentiert werden, bevor ich mit der Implementierung des
Frommer-Algorithmus in Macaulay beginnen kann.
15.03.2010
Habe bit dem Entwurf zum Auslesen von Punkten aus der Datenbank begonnen.
01.03.2010
Glattheitstest-Algorthmus ist implementiert (bis auf die Ausgabe und Eintrag in die DB).
25.02.2010
Eintrage-Skript in crontab auf dem Datenserver eingetragen.
18.02.2010
Die Ursache, warum die Prozesse nichts taten ist wahrscheinlich ausgemacht:
ein Puffer in python-Skript (welcher das Programm startete) lief höchstwahrscheinlich nach einer Weile voll.
Danke an Sven für konstruktive Beiträge zur Problemlösung.
16.02.2010
Statistikunterschied ab der 5. Strudelgröße war auf eine unterschiedliche Initialisierungsreihenfolge der Strudelgrößen zurückzuführen.
Dennoch gab es immer noch einen Unterschied zu den Ergebnissen des alten sucheElfer-Versuchs. Hier muss aber festgestellt werden,
dass die alte Formel2-Implementierung nicht alle Fälle abdeckt, was vermutlich zur fehlerhaften Statistik führt. (TODO: diese Theorie prüfen)
Was hätten wir nur ohne Versionsmanagement gemacht? Vermutlich dumm aus der Wäsche geschaut.
15.02.2010
Eine Fehlersuche und das Schreiben von Tests halten mich derzeit davon ab, die Implementierung des 'nicht'-Glattheitstests abzuschließen.
(Die neue Statistik unterscheidet sich ab der 5. Strudelgröße von der früheren Statistik, sowohl in der optimierten als auch in der Nichtoptimierten Variante.)
28.01.2010
export BLASLAPACK_LIBS=-lblas
Jetzt wird es spannend:
Ein Versuch auf den gauss-Rechnern ist gestartet!
Das musste manuell geschehen, da die Sun Grid Engine noch nicht läuft.
Jetzt weiss ich auch wieder, warum ich unbedingt 'file locking' aktivieren wollte (und es leider nicht gemacht habe):
beim gleichzeitigen Start ist der 'initialSeed' auch gleich. Da sich der automatisch generierte Name
der Ausgabedatei nur um den InitialSeed unterscheidet, geht's in diesem Fall ohne atomare Operationen auf dem Dateisystem nicht
fehlerfrei zu!
21.01.2010
Test für Statistik in Kombination mit der Formel23 implementiert.
Statistik wird jetzt auch wieder korrekt geführt.
20.01.2010
Anpassung der Statistik vorbereitet.
19.01.2010
Formel23 bis auf Statistik implementiert. Erster Test wird auch schon bestanden.
Die ersten Versuche rücken in greifbare Nähe!
16.01.2010
mmmh, ein Blick auf den aktuellen GCC-Compiler 4.4.2 bringt zu Tage, dass es neue Optimierungsflags gibt.
Die neuen Flags haetten mir einen Teil der manuellen Optimierung beim nxnxn-Projekt erspart !
11.01.2010
Arbeite an der Implementierung der Formel um Koeffizienten der Poincaré Differentialform derart zu bestimmen, dass die ersten drei Strudelgroessen verschwinden.
07.01.2010
Wiederholberkeit und Nachvollziehbarkeit eines Versuchs verbessert:
Die Erstellung eines Programms wird in der DB protokolliert.
Dabei werden Erstellungsparameter und einige der relevanten Umgebungsvariablen gespeichert.
Das Programm bekommt außerdem eine ID.
23.12.2009
Logik fuer die Verwaltung der Ergebnisdateien fertiggestellt.
Hinzufügen der Ergebnisdateien in die Versionverwaltung (svn) muss noch manuell erfolgen.
Ein paar Fehler beim Eintragen der Ergebnisse in die DB beseitigt.
19.12.2009
Eintragen in die DB klappt.
Naechstes Etappenziel:
Logik fuer die Verwaltung der Ergebnisdateien.
Danach oder davor sind Tests und Dokumentation dran...Ob es dann noch mit Formel23 vor Sylvester was wird?
18.12.2009
Hmm, MySQL (auch Version 5) unterstützt nicht 'Check Constraints'.
Auf dem Server ist MySQL Version 4.1.13 installiert.
Diese unterstützt noch keine Trigger.
Datenkonsistenz kann somit nur durch Anwendungslogik sichergestellt werden.
Allternativen:
-wechsle zu MySQL Version 5.1, was wieder Installationsarbeiten am Server bedeutet, (OS-upgrage?)
-verwende PostGreSQL, bedeutet Installationsarbeiten und Programm umschreiben
-wähle anderen Server (welchen)
17.12.2009 Das (Python)-Skript zum Eintragen der Ergebnisse in die Datenbank muss ersmal doch nicht als daemon laufen, da (über file locks) sichergestellt werden kann, dass immer nur eine Instanz ausgeführt wird.
16.12.2009 Formel zur Berechnung der 3. Strudelgröße besprochen.
15.12.2009
Prüfen der Ausgabeparameter auf Vollständigkeit.
Uberlegungen zum Verhindern von gleichen Einträgen in der Datenbank.
14.12.2009
Recherche zur Homotopie-Verfahren
Zerlegen der Statistikdaten aus der Ergebnisdatei.
11.12.2009
Die Ausgabedateien können nun mit Python gelesen und in einzelne Variablen zerlegt werden.
Dateien mit Mehrfachergebnissen und nicht erfolgreich abgeschlossenen Versuchen werden herausgefiltert.
Nächste Etappe:
Statistikdaten in einzelne Einträge zerlegen.
Aus den Datenschnipseln die MySQL-Abfrage zusammenbauen und die Daten in die DB eintragen.
07.12.2009
Der erste Entwurf der Datenbankstruktur ist fertig.
Konzept für die automatische Übertragung der Ergebnisse ist überlegt.
Nächstes Ziel: PHP-Skripte zum Einlesen der Versuchsergebnisse in die DB.
Das Programm 'centerfocus' muss dazu noch Zusatzinformationen ausgeben.
02.12.2009
Die Webseiten von unserem Hosteurope-Server lassen sich vielleicht via Plesk (somit nur mit den domain-Zugangsdaten) oder manuell korrekt konfigurieren,
aber das ist nicht glücklicherweise notwendig, da es eine minimale Standardkonfiguration gibt.
Die Dateien für den manuellen Datenbankzugriff werden sich unter
87.230.76.194/centerfocus
einfinden, mit welchen man Versuchsergebnisse in die noch zu erstellende
Datenbank eintragen kann. Die Datenbank selbst kann über phpAdmin verwaltet werden.
01.12.2009
Statistik für die Quadriken wird ausgegeben.
ab 17.11 wird die Wiki-Seite für einen Umzug vorbereitet und das Editieren ist gesperrt.
16.11.2009
Erster kleiner Test fast implementiert. (Werden die Parameter richtig eingelesen?)
In modernen Entwicklungsmethoden heisst es oft 'test first',
aber wenn ich mich daran (noch) nicht gehalten habe,
werden Tests auch geschrieben, damit sich keine neuen Fehler einschleichen!
14.11.2009
Brrrr. Geschwindigkeisproblem wurde durch eine falsche Initialisierung in der neuen Programmversion verursacht.
Der Spuk ist vorbei und einige Stunden sind ins Land gegangen...
13.11.2009
Geschwindigkeit: Version 135 ist noch schnell. Revision 136 nicht mehr.
Es scheint alles auf das neue Einlesen der Parameter hinzudeuten. Grund noch unklar
Das Einlesen der Parameter wurde am Montag umgeschrieben.
12.11.2009
Die ToDo-Liste weiter reduziert.
Geschwindigkeit seit Revision 128( ? ) stark eingebrochen. Wir haben gerade Revision 136.
Da muss ich bei Gelegenheit mal die Ursache suchen.
Gut, das Zwischenversionen eingecheckt wurden. Man sollte das wohl jeden Tag kontrollieren...
11.11.2009
Test durchgeführt. Der erste Test wird noch nicht bestanden.
09.11.2009
Ein Teil der Eingaberoutine umgeschrieben.
Dies war schon lange auf der TODO-Liste und jetzt wurde es unumgänglich.
06.11.2009
Ein paar ausstehende Aufgaben erledigt.
Die mit ausgegebene Information ueber die Datenstruktur sieht noch nicht ansprechend aus.
Vielleicht den Text in einer Datei vorformatieren und dann die Datei ausgeben, oder auf die Dokumentation verlinken, da dort beliebig schoen formatiert werden kann.
Bei der Ausgabe fehlt noch ConeStatistics.
Bin gespannt auf Tests naechste Woche.
05.11.2009
Erstes Resume: c.a. 1.500 Zeilen neuer Code, c.a 2.000 Zeilen überarbeitet und einige ausstehende Aufgaben.
-Ein Beispiel mit nichtverschwindenden Quadriken gefunden. Ein paar Fehler entdeckt.
-Einige Warnings beseitigt
Dann wollen wir mal endlich die Ausgabe erzeugen.
04.11.2009
Die Linksinverse von Ker(Jacobi ( Strudelgroessen) ) ist ermittelt.
Problem mit der Berechnung des Komplements von Spaltenvektoren aufgetaucht, aber inzwischen auf einem anderen Weg geloest.
03.11.2009
Bin an der Berechnung der inversen Matrix mittels FFPACK dran. Programm kompiliert, aber tut noch nicht was es soll.
OK. mindestens ein Parameter der Invert-Funktion ist falsch dokumentiert, oder es ist ein anderer Fehler...
Es ist auch nicht dokumentiert, dass man den Speicherplatz fuer die inverse Matrix selbst reservieren muss,
aber trozt allem : Die Invert-Funktion von FFPACK liefert offensichtlich die linksinverse Matrix, zumindest fuer quadratische Matrizen.
Fuer nichtquadratische Matrizen kommt man hier nicht weiter, also muss eine quadratische Matrix bereitgestellt werden.
02.11.2009
Bin heute erst am späten Nachmittag im Büro.
30.10.2009
3DMatrix-Struktur implementiert, so weit es notwendig war
CoeffQuadricSmall (linear unabh. R_i) wird berechnet.
Als naechstes muss die Basistransformation nach CoeffQuadricBig und die Ausgabe implementiert werden.
29.10.2009
Die größeren Probleme bei der Berechnung der Quadriken in C++ sind überwunden.
Nun gilt es noch ein paar passende Tests zu implementieren,
die restliche Programmierarbeit zu erledigen
und das wichtigste in einer Dokumentation festzuhalten.
28.10.2009
Heute wurde noch mal der praktische Beweis dafür geliefert, dass ein fehlerhaftes Programm ein richtiges Ergebnis liefern kann!
Die Ausgabestruktur wurde heute festgelegt.
26.10.2009
Status: Berechnung des quadratischen Anteils in Arbeit.
23.10.2009
18:50 Die Standardversion 'centerfocus' kompiliert und laeuft scheinbar wieder nach der Umstellung.
Ohne valgrind wäre das (bei mir) nicht so schnell gegangen!
Von der Umstellung waren c.a. 1.000 lines of code betroffen.
Bei kompilieren der optimierten Version gibt es noch ein paar Fehlermeldungen.
Gibt es eigentlich Entwicklungsumgebungen, welche Template-Fehlermeldungen in eine lesbare Form (verschachtelt) verwandeln?
00:03 Die optimierte Variante laeuft wieder, auch im DEBUG und im SAFE Modus.
Nachdem die Aenderungen dokumentiert sind, koennte man sich an die Berechnung des Tangentialkegels (?) machen...
22.10.2009
Template-Fehlermeldungen sind doch was schönes (Ironie), aber man gewöhnt sich daran.
Ein paar sind noch uebrig aber es ist schon spät und heute geht nichts mehr.
Wenn das Programm (hoffentlich morgen früh) wieder läuft, ist alles fuer die Implementierung der Quadrics-Berechnungen vorbereitet.
20-21.10.2009
Arbeit an der Umstrukturierung, so dass die Variante fuer EpsPrecision 0,1 zusammen mit der generischen fuer hoehere Eps-Genauigkeit verwendet werden kann.
Stand: Struktur steht, Implementierungsfehler muessen noch beseitigt werden.
19.10.2009
Die Designaenderungen im Hinblick auf die InfEps-Rechnung brachten (unbeabsichtigt) 35% Geschwindigkeitssteigerung.
Der Effekt konnte genausogut auf einen Fehler hinweisen, und so musste dem nachgegangen werden.
Die Ursache der Leistungsstteigerung (kein Fehler) wurde lokalisiert und für später dokumentiert.
Ob die Leistungssteigerung nach der anstehenden Umstrukturierung noch vorhanden sein wird, bleibt abzuwarten.
Die Version (126, bzw. 127) wurde aber bei sourceforge eingecheckt.
18.10.2009 (Sonntag !)
Die InfEps-Rechnung funktioniert jetzt wieder
und zwar ohne einer dafür speziell ausgelegten Implementation des Frommer-Algorithmus (wie bisher).
Allerdings kann das Programm nur entweder fuer die InfEps-Rechnung oder fuer die optimierte Berechnung
ueber F_p[e] (?) erstellt werden. Beides zusammen geht nicht. Dies wird das nächste Etappenziel.
Das EpsPrecision-Problem
Man kann am Typ des Ringelements noch lange nicht die Zugehoerigkeit zu einem Ring erkennen. Die Eps-Genauigkeit muss (abgesehen von den speziallfaellen EPSPrec=0,1) i.A. allgemein gehalten werden, (anderenfalls müsste dynamisch zur Laufzeit ein Datentyp generiert werden. Wie das geht, weiss ich nicht). Die Angabe erfolgt also über den Konstruktor oder ueber einen Factory-Aufruf (in unserem Fall würde dann ein Ring ein neues Ringelement liefern). Bei der zweiten Variante sieht man einem Element allerdings immer noch nicht, zu _welchem_ Ring dieses denn nun gehört, es sei denn man speichert einen Zeiger auf den Ring, oder speichert die Charakteristik und epsPrecision. Beides verbietet sich fuer die spezialfälle EPSPrec=0,1 aus Performansgründen. Über den Factory-Aufruf (oder der expliziten Angabe der EpsPrecision) kann man aber mehr oder weniger sicherstellen (wenn nur 1 oder 2 Ringe im Spiel sind), dass ein Ringelement mit der korrekten EpsPrecision erstellt wird.
Variante A: EpsGenauigkeit immer beim erstellen eines Elements angeben
Wenn die EpsGenauigkeit immer angegeben werden soll,
muessen an vielen Stellen im Quelltext die Variablendeklarationen geaendert werden,
und einige bisher vorhandenen Konstuktorvarianten verboten werden (private). Die Stellen im
Quelltext findet man dann anhand der Fehlermeldungen, nachdem man die bisherigen Konstruktoren
verbietet. Sollte dann schliesslich im Programm an einen konservativ implementierten Ringoperator
ein Element mit der falschen EpsPrecision uebergeben werden, kommt es dann zum Fehler.
Variante A koennte zu einem Performance-Verlust fuehren, da an den Konstruktor ein weiterer Parameter
uebergeben wird (und Elemente werden sehr oft konstruiert). Vielleicht kann der Kompiler aber
in den Spezialfaellen PSPrec=0,1 den Parameter wegoptimieren, da dieser in der Scharfen Version
einfach nicht abgefragt werden braucht.
Die Variante B (wurde umgesetzt ):
wird ein EpsNumber zugewiesen, erhoeht sich sein epsPrecision entsprechend. Wird in einem epsRing mit epsPrecision(Ring) gerechnet (Addition, etc.), mit epsPrecision(Ring) < epsPrecision(Parameter) , wird epsPrecision(Ergebnis) abgeschnitten (setze epsPrecision(Ergebnis) = epsPrecision(Ring) ). Löse Fehlermeldung aus , wenn das Ergebnis wieder in einem der Parameter gespeichert wird mit epsPrecision(Parameter)> epsPrecision(Ring) und in den hoeheren Eps-Koeffizienten etwas ungleich Null eingetragen ist.
Falls epsPrecision(Parameter)< epsPrecision(Ring), setzte epsPrecision(Ergebnis)=epsPrecision(Ring).
SAFE-Modus: Wird in einem Ring mit epsPrecision gerechnet, welches kleiner als das epsPrecision eines Parameters ist, gibt es eine Fehlermeldung.
EPSPrecision optimaler Fall
EPS-Precision der Parameter bei Ringoperationen immer korrekt, so dass Pruefung und Abschneiden wegfallen kann, bzw. nur im SAFE-Modus stattfindet.
14.10.2009
Eine fruehere (von mir undokumentierte) Aenderung der Initialisierungsreihenfolge der Koeffizienten
der Poincaré-Differentialform fuehrte zum nichtbestehen eines (manuellen) Routinentests.
Die Suche des (nichtexistenten) Fehlers hat einige Stunden gekostet.
13.10.2009
Das Überschreiten meines (geringen) Quotas verursacht zweimal einen
Fehler bei der Datensicherung. Mindestens eine Stunde lang geht im Institut mit den Rechnern nichts.
Werde mein Verzeichnis zukuenftig klein halten;
der Zielordner fuer die generierte Projektdokumentation ist ab jetzt /tmp.
9.10.2009
Notwendige Infrastruktur:
Entwicklungsumgebung fuer C++ ist jetzt auch am CRCG verfuegbar.
Durch einen alten Account an der Uni Hannover, (welcher noch nicht gesperrt ist),
konnte ich glücklicherweise auch schon vor dem 9.10. ganz passabel arbeiten,
der ultraschnellen Internetanbindung des CRCG sei Dank.
5.10.2009
Mein Rechneraccount ist jetzt da, es kann auch am Rechner losgehen.
