Bugtracking für eine Person

WICHTIG: Der Betrieb von goMatlab.de wird privat finanziert fortgesetzt. - Mehr Infos...

Partner:

Forum

Option

[Erweitert]

• Diese Seite per Mail weiterempfehlen

Gehe zu:

Seban

Forum-Meister


	Beiträge: 600

	Anmeldedatum: 19.01.12

	Wohnort: ---

	Version: ab R2014b

Verfasst am: 27.08.2012, 13:53 Titel: Bugtracking für eine Person

Hallo,

Ich teste momentan in meinem HiWi-Job eine von jemand anders erstellte in MATLAB programmierte Anwendung. Meine Aufgabe ist es ua. Fehler zu finden (ohne bisher in den Quellcode geschaut zu haben) und anschließend diese Fehler zu beseitigen.

Bisher habe ich Fehler einfach in einem Wod-Dokument festgehalten, allerdings ist mir dies heute, am 2. Tag, bereits zu unübersichtlich.

Ich suche nun also ein Programm, mit dem ich Fehler erfassen kann, dh. was habe ich gemacht, dass der Fehler aufgetreten ist, welche Fehler/Hinweise wurden ausgegeben. Zudem möchte ich dann weiteres Vorgehen erfassen. trittd er Fehler auch auf wenn ich dies und jenes mache oder dies und das ändere. Und hier wird es in einem Word-Dokument schnell unübersichtlich, ein Dokument pro Fehler ist allerdings auch nicht das Wahre.

Ich hab mir jetzt bereits einige Bugtracker angeschaut, aber die scheinen mir alle zu vield es Guten zu sein und übersteigen bei weitem die Anforderungen die ich habe.

Hat von euch jemand einen guten Tipp? Wie erfasst ihre eure Bugs?

Grüße & danke,
Seb

PS: Ich war mir nicht sicher, in welches Unterforum das am besten passt. Wenn es woanders hingehört, bitte einfach verschieben.

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 27.08.2012, 18:39 Titel: Re: Bugtracking für eine Person

Hallo Seban,

Bugs sind tückisch. Im Normalfall, also im schlimmsten anzunehmenden, erzeugt ein Bugfix andere Bugs an weit entfernten Stellen im Programm. Das Erkennen des Zusammenhangs ist dabei im Allgemeinen schwer und ab einer gewissen Programmgröße (100'000 Zeilen) ist dies aus theoretischen Überlegungen heraus für einen Menschen gar nicht mehr möglich.
Wie wir alle wissen, ist die Lage in der Realität schlimmer.

Eine sinnvolle Strategie zum Testen ist die hierarchische Aufteilung des Programms. Zunächst kann man die Unterprogramme testen. Macht z.B. der String-Vergleich genau das, was erwartet wird? Reagiert er sinnvoll bei falschen Inputs wie Zahlen oder leeren Strings? Dies nennt man Unit-Testing und die Erstellung umfassender Tests nimmt etwa soviel Zeit in anspruch, wie die eigentliche Programmierung. Es gibt Programmier-Strategien, die mit der Erstellung der Tests beginnen.
Da die Unit-Tests (größtenteils) unabhängig von einander sind, lassen sich Bugs und Fixes hier sinnvoll in einzelnen Files dokumentieren. Ich mach dies als Kommentar unterhalb der Help-Section, weil sie im Source-Code absolut sicher wiederzufinden sind. Falls es später mal Rätsel gibt, wann sich die Arbeitsweise einer Funktion geändert hat, ist die Funktion selbst der beste Ort für eine Dokumentation und Version-History.

Danach benötigt man eine Analyse, ob die Tools von den anderen Programm-Teilen mit den erwarteten Daten aufgerufen werden. Es kann durchaus sein, dass eine Tool-Funktion zur Stringbearbeitung zufällig auch mit Cell-Strings funktioniert, aber unerwartete Ergebnisse zurückliefert.

Schließlich muss auch das Hauptprogramm getestet werden. Dazu werden Standard-Inputs mit bekannten Outputs benötigt. Wenn ein Bug gefixed wurde und danach die Ergebnisse substantiell anders sind, muss man noch mal genauer nachschauen, ob es vorher einen anderen Bug gab, der von dem gefixten verdeckt wurde, oder ob man aus Versehen einen neuen Bug erzeugt hat.
Wenn es nicht schon beim Programm-design vorgesehen ist, wird es sehr schwierig sein automatisierte Tests mit GUIs durchzuführen. Dann muss man leider die UICONTROLs manuell betätigen um die Tests durchzuführen. Dies ist aber Fehleranfällig und kaum dokumentiertbar.

Die Bugs, die in den Integration-Tests, also beim Testen der Hauptprogramme, gefunden werden, werden in dem entsprechenden M-File und im jeweiligen Hauptprogramm dokumentiert. Dabei enthält jeder Eintrag Dateum, Uhrzeit, Person, Problembeschreibung und Erklärung der Lösung, bei Bedarf auch eine Abschätzung, ob andere Programmteile betroffen sind.

Das Speichern der Version-History und Bug-Lists in den M-Files hat natürlich den Nachteil, dass man nicht mehr ohne weiteres heraus bekommt, was z.B. im vergangenen November alles verändert wurde. Hier hilft eine möglichst Strenge Syntax der Einträge. Ich verwende:

Code:

% $Version: 009
% $File: MFiles\Tools\String\StrCmpIgnoreSpace.m
% $History:
% 001: 2012-31-08 13:45, JSimon, Bugfix: There was an A, now it's a B.
% 002: 2012-31-08 14:10, JSimon, Bugfix: I need a C also, but plotting might fail
... Bis 009.

Funktion ohne Link?

Um nun bestimmt Einträge zu finden habe ich ein Tool geschrieben, dass die alle M-Files durchsucht und die jeweiligen Einträge findet.

Zudem muss jede Änderung sich sehr zeitnah in der Dokumentation wiederfinden. Nicht (ordentlich) dokumentierte Änderungen machen ein Programm sehr schnell sehr unbrauchbar. Und wenn die Benutzer sich mal an einen Bug gewöhnt haben und einen Workaround gefunden haben, sind sie von einer "Lösung" manchmal nicht begeistert, wenn man sie nicht schriftlich überzeugt, dass es nun besser geht.

Nun können auch Benutzer Bugs finden. Dann habe ich ein Tool, das zunächst die Versionen von Matlab, Betriesbsystem, Java und dem Programm dokumentiert. Dann wird DIARY gestartet und der Benutzer kann den Fehler nochmals produzieren. Danach wird nochmals der freie Speicher, offene Files und Fenster etc dokumentiert. Schließlich kann er den Report an eine bestimmte Mail-Adresse schicken und ich sammele die Reports lokal bei mir.

Ich habe ein größeres Programm geschrieben (200'000 Zeilen Matlab und C Code plus Kommentare), welches in mehreren Labors eingesetzt wird. Die oben genannte Strategie funktioniert sehr zuverlässig und auch die Benutzer müssen nicht lange suchen, um zu verstehen, wo, wann und warum welche Änderungen durchgeführt wurden.
Allerdings steht und fällt die Methode mit dem Vorhandensein der Unit- und Integration-Tests. Wenn hier der Programmierer geschlampt hat, gibt es kaum Möglichkeiten im Nachhinein das korrekte Funktionieren eines Tools zu testen. Dann ist das Dokumentieren eines Bugs zwar möglich, aber wie soll man nachweisen, dass ein Bugfix wirklich hilfreich ist - und wozu sollte man ihn dann dokumentieren?! Solche "Brownfield"-Szenarios sind leider häufig zu finden, siehe http://www.heise.de/developer/artik.....eld-Projekten-855114.html, weitere Links kennt Google zum Stichwort "Brownfield".

Gruß, Jan

flashpixx

Forum-Guru


	Beiträge: 355

	Anmeldedatum: 19.04.08

	Wohnort: ---

	Version: ---

Verfasst am: 27.08.2012, 20:25 Titel:

Was man evtl noch machen kann ist, dass man ein Bugsystem wie z.B. Bugzilla ( http://de.wikipedia.org/wiki/Bugzilla ) verwendet und das mit dem Repository kombiniert, d.h. wenn ein Source File wieder eingecheckt wird, dann wird bevor die Transaktion abgeschlossen wird, welche Bugs gefixed wurden und diese Information wird dann in das Bugzilla übertragen.

Zusätzlich kann durch Hooks auch prüfen, ob die eingecheckten Quellcodes syntaktisch korrekt sind und ggf. direkt einen Unittest veranlassen. Wenn das alles nicht Fehler frei ist, dann wird der Quellcode nicht eingecheckt.

Bei gewachsenem Sourcecode muss man sich überlegen, auch wenn es hart klingt, ob sich eben eine Pflege lohnt oder ob evtl ein komplettes / teilweises Redesign sinnvoller ist. In manchen Fällen lohnt auch ein Redesign, sofern bekannt ist, was der Code macht.

Seban

Themenstarter

Forum-Meister


	Beiträge: 600

	Anmeldedatum: 19.01.12

	Wohnort: ---

	Version: ab R2014b

Verfasst am: 27.08.2012, 21:33 Titel:

Wow, vielen Dank für die ausführlichen Antworten.

Bin aber gerade erst zur Tür rein, werde ich mir morgen direkt als erstes zu Gemüte führen.

Grüße

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 28.08.2012, 12:24 Titel:

Hallo flashpixx,

Dies direkt mit einem Revisions-System zu koppeln, ist natürlich der sinnvollste nächste Schritt. Was nützt einem die Information, dass bis zum 17.03.2012 alles richtig lief, danach aber alles falsch, wenn man dann nicht die jeweilige Version wieder herstellen kann? Da hast triffst Du also einen sehr wichtigen Punkt.
Eine Schwierigkeit für eines meiner Projekt war, dass ich die Software für mehrere Labore entwickelt habe, die teilweise wegen der Patientendaten keinen Internetanschluß hatten. Zudem müssen die Programme 10 Jahre lang in der Lage sein, die gleichen Ergebnisse zu reproduzieren. Deshalb fiel die Nutzung externer Revisions- und Bugtrack-Systeme flach, obwohl die eigentlich die weit professioneller Wahl gewesen wären. Zu allem Überfluss wird Matlab 2022a nicht mehr unter WindowsXP laufen, welches zudem auch nicht auf den dann modernen Rechnern laufen wird. Also muss das Programm in eine virtuelle Maschine abgeschoben werden - und deren Änderungen müssen wieder akribisch Dokumentiert werden... Deshalb blieb ich bei der eigentlich recht dämlichen Methode, die reports direkt in den Source-Code zu schreiben. Das ist nicht unbedingt empfehlenswert, aber von jedem Laien auch in 10 oder 20 Jahren noch mit einem Text-Editor nachzuvollziehen.

Saubere Programmierung, Bug-Tracking, Dokumentation, Revisionssystem und standardisiertes User-Feedback spielen also Hand in Hand. Leider bietet Matlab selbst dafür nur sehr rudimentäre Tools an.

Gruß, Jan

flashpixx

Forum-Guru


	Beiträge: 355

	Anmeldedatum: 19.04.08

	Wohnort: ---

	Version: ---

Verfasst am: 28.08.2012, 15:33 Titel:

Jan S hat Folgendes geschrieben:

Eine Schwierigkeit für eines meiner Projekt war, dass ich die Software für mehrere Labore entwickelt habe, die teilweise wegen der Patientendaten keinen Internetanschluß hatten. Zudem müssen die Programme 10 Jahre lang in der Lage sein, die gleichen Ergebnisse zu reproduzieren. Deshalb fiel die Nutzung externer Revisions- und Bugtrack-Systeme flach, obwohl die eigentlich die weit professioneller Wahl gewesen wären.

Warum Git würde auch lokal laufen, nur muss man dann die Daten via USB Stick o.ä. hin und her tragen !?
Nutze git für lokale Sachen ganz gerne und man kann es ja auch per EMail oder anderen Protokollen austauschen

Jan S hat Folgendes geschrieben:

Zu allem Überfluss wird Matlab 2022a nicht mehr unter WindowsXP laufen, welches zudem auch nicht auf den dann modernen Rechnern laufen wird. Also muss das Programm in eine virtuelle Maschine abgeschoben werden - und deren Änderungen müssen wieder akribisch Dokumentiert werden...

Waurm !? Ich meine eine Änderung der Umgebung hat nichts mit dem Code zu tun !? Natürlich wenn man eine andere Umgebung hat, dann müssen ggf die Codes angepasst werden, aber das ist eine Codeänderung => Fork oder Branche des Codes bzw. reguläre Revision.
Ich sag jetzt mal ketzterisch, ob der Admin seine Systemkonfiguration dokumentiert, spielt ja für den Code und dessen Doku keine Rolle.

Zusätzlich sollte Windows XP sowieso nicht mehr verwendet werden, denn der Support ist meines Wissens dieses Jahr ausgelaufen, d.h. es gibt keine Updates mehr. Sorry, dass ich das so hart sage, aber wer jetzt noch XP einsetzt, macht definitiv was falsch, es war lange genug Zeit da, die Software zu portieren und außerdem ist Matlab an sich ja recht cross-plattform und wenn man was externes nutzt wie z.B. Mex, dann sollte man eine API so designen, dass sie auch ohne viel Aufwand veränderbar ist, d.h. OOP, also C++, denn dann kann ich einfach die Klasse ändern und mache die Anpassen für das neue OS dort. Sprichwörtlich habe ich dann für jedes OS eine passende Klasse, die ich anbinde.

Jan S hat Folgendes geschrieben:

Das ist nicht unbedingt empfehlenswert, aber von jedem Laien auch in 10 oder 20 Jahren noch mit einem Text-Editor nachzuvollziehen.

Kann ich mit SVN & Git auch, einfach ein Dump ziehen, das ist blanker Text

Jan S hat Folgendes geschrieben:

Saubere Programmierung, Bug-Tracking, Dokumentation, Revisionssystem und standardisiertes User-Feedback spielen also Hand in Hand. Leider bietet Matlab selbst dafür nur sehr rudimentäre Tools an.

Das leider, da stimme ich Dir zu und das verstehe ich nicht. Das Argument was ja hier schon mal kam "wurde bisher nicht von vielen gefordert" kann ich mir nicht wirklich vorstellen.
Ich habe z.B. angefangen via Datenbank Simulink zu kapseln, also dass man die Simulink MDL Daten in eine Datenbank inkl Revision ablegt, zu dem Simulink werden dann auch alle benötigten m Files mit gespeichert. Userverwaltung dazu. Das ganze via OOP gekapselt, so dass man mehre Modell laden und diese dann via CLI starten kann. Ist zwar noch in der Entwicklung, aber mich hat es genervt, dass ich irgendwie mal in einem Netz flott sagen kann "da Modell, lass mal laufen"

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 28.08.2012, 19:04 Titel:

Hallo flashpixx,

Zitat:

Warum Git würde auch lokal laufen, nur muss man dann die Daten via USB Stick o.ä. hin und her tragen !?

Ich habe das Programm seit 1999 entwickelt. Und die Daten von damals müssen 2022 reproduzierbar sein. Jedes weitere externe Programm erhöht die Gefahr von Inkompatibilitäten. Welche Versions-Systeme von 1999 laufen denn heute noch?

Jan S hat Folgendes geschrieben:

Zu allem Überfluss wird Matlab 2022a nicht mehr unter WindowsXP laufen, welches zudem auch nicht auf den dann modernen Rechnern laufen wird.

flashpixx hat Folgendes geschrieben:

Waurm !? Ich meine eine Änderung der Umgebung hat nichts mit dem Code zu tun !?

Das wäre schön. Matlab 6.5 hat die Floating-Point-Einheit beim Rücksprung aus einem MEX per mexErrMsgTxt nicht zurückgesetzt. Deshalb konnte die Rundungsrichtung und die Nutzung der 80-Bit-Register nach einem gecrashten MEX anders sein als davor. Damit wurden die Resultate abhängig von den Programmen die Vorher gelaufen sind. Dies betraf aber nur Windows-Rechner, die auf Intel-Prozessoren liefen und MEX-Funktionen, die mit nicht MSVC übersetzt wurden. Heute spielt es auch eine Rolle, ob eine Virtuelle Maschine die Floating-Point-Berechnungen per SSE emuliert oder nicht. Natürlich macht es einen Unterschied ob die Lineare Algebra von LAPACK, ATLAS oder MKL berechnet wird.
Das Ergebnis von z.B. SUM hängt von der Anzahl der Cores ab und für manche Matlab-Versionen sogar von der aktuellen Belastung der Maschine. FSEEK muss z.B. auf einer Multi-Core-Maschine nicht erfolgreich sein und ein Scheitern ist nicht mal ein Fehler. Der Programmierer muss den Fall abfangen, dass die gewünschte Position noch gar nicht erreicht wurde. Bei Tests im Virtual-XP unter Windows 7 tritt das Problem nie auf, da dies nur einen Core emuliert. Ein echtes XP kann aber anders reagieren.

Auch ob ein Matlab-Programm unter Linux genauso läuft wie unter Windows hängt von sehr vielen Details ab. Da sind die File-Separatoren noch die harmlosesten.

Wenn ich dann einen Code als "stabil und getestet" klassifizieren möchte, benötige ich deshalb eine exakt definierte Umgebung und der Admin darf nicht beliebig dazwischen funken. Ein Test ist nur dann zuverlässig, wenn er auch die verwendete Maschine betrifft. Man findet ja auch in der Dokumentation auf der Packung belieber Software Erklärungen wie "läuft unter WinXP/SP3/32Bit mit > 500 MB RAM und DirectX10 Graphik" etc.

[qoute]Zusätzlich sollte Windows XP sowieso nicht mehr verwendet werden, denn der Support ist meines Wissens dieses Jahr ausgelaufen, d.h. es gibt keine Updates mehr. Sorry, dass ich das so hart sage, aber wer jetzt noch XP einsetzt, macht definitiv was falsch, ...[/quote]
Nein, dem widerspreche ich nachdrücklich. Wir müssen um die DFG-Richtlinien einzuhalten unsere Ergebnisse 10 Jahre lang exakt reproduzieren können. Da die Daten mit Matlab6.5/WinXP32 erstellt wurden, muss genau diese Konfiguration auch weiter laufen. Matlab 6.5 läuft unter Win7 nämlich gar nicht.
Um den Code auch unter modernen Betriebssystemen und Matlab-Versionen laufen zu lassen waren Änderungen an über 9000 Zeilen nötig, darunter auch neue Fälle für die Unit-Tests, wobei auch bestehende Bugs gefixed wurden. Diese Verbesserungen dürfen dann natürlich auf keinen Fall in die alten Versionen eingefügt werden, weil dann wieder eine neue Zertifizierung nötig wäre, was etwa 2 Monate dauert.

Das Auslaufen der Updates ist dabei vollkommen belanglos, da auf der Maschine, mit der die alten Ergebnisse reproduziert werden können, natürlich keine Updates eingespielt werden. Wenn in 10 Jahren ein Patient die Klinik verklagt, weil er meint falsch operiert worden zu sein, kann ich mich kaum herausreden, dass das Programm heute eine andere Einschätzung der Messdaten gibt, weil Microsoft inzwischen ein Update der API-Funktionen eingespielt hat, dass Vergleiche zwischen leeren ANSI und Unicode-Strings unterschiedlich beantwortet, oder irgend ein vergleichbaren Unfug.

Matlab ist zwar "recht cross-plattform", das reicht aber nicht aus, wenn die Ergebnisse sicherheitskritisch sind - also z.B. Flugzeuge, Chirurgie an kleinen Kindern, etc.
Beim MEX-Interface ist der verwendete Compiler immer ein großes Problem. So ist das Ergebnis einfacher Operationen wie "0.5 < NaN" per IEEE754 zwar wohl definiert. Nur halten sich z.B. die MSVC-Compiler nicht so genau daran. Unter MSVC2008/32 ist das Ergebnis FLASE, wie jeder Vergleich mit NaN. MSVC2010/32 berechnet das je nach Compiler-Flags korrekt in der FPU oder falsch per SSE. MSVC2010/64 schiebt das immer in die SSE-Einheit, so dass man trotz IEEE754 NaNs explizit abfangen muss. Supi.

Zitat:

... es war lange genug Zeit da, die Software zu portieren ...

Nein, das trifft nicht mein Problem: Eine portierte Version gibt nicht mehr garantiert das gleiche Ergebnis. Natürlich portieren wir, aber das betrifft dann nur die neuen Messungen. Und für einen Vergleich mit den alten benötigen wir ein nicht-portieretes Programm.

Zitat:

Sprichwörtlich habe ich dann für jedes OS eine passende Klasse, die ich anbinde.

Wenn Du passende Klassen für 8 Matlab-Versionen unter 6 Betriebssystemen warten kannst, ist das kein Problem. Wenn ein umfassender Test aber schon 2 Monate benötigt, ist das nicht machbar.

Jan S hat Folgendes geschrieben:

Das ist nicht unbedingt empfehlenswert, aber von jedem Laien auch in 10 oder 20 Jahren noch mit einem Text-Editor nachzuvollziehen.

flashpixx hat Folgendes geschrieben:

Kann ich mit SVN & Git auch, einfach ein Dump ziehen, das ist blanker Text

Ja, klar. Aber wenn Du einen blanken Text hast, ist dann die Versions-Information noch erreichbar? Das Einfügen der Versione-Informationen in den Source-Code ist in manchen Punkten unschlagbar (hohe Zuverlässigkeit, ohne externe Software lesbar -z.B. in meinen FileExchange-Programmen kann jeder Laie nachlesen, was warum geändert wurde), aber natürlich auch massive Nachteile: Wirklich große Projekte mit vielen Mitarbeitern wie z.B. Linux lassen sich so nicht managen und an Git etc führt kein Weg vorbei.

Gruß, Jan

flashpixx

Forum-Guru


	Beiträge: 355

	Anmeldedatum: 19.04.08

	Wohnort: ---

	Version: ---

Verfasst am: 28.08.2012, 20:08 Titel:

Jan S hat Folgendes geschrieben:

Zitat:

Warum Git würde auch lokal laufen, nur muss man dann die Daten via USB Stick o.ä. hin und her tragen !?

Jain, kommt auf die Software an bzw. eigentlich auf die Kommunikation der einzelnen Hersteller, wenn die APIs ordentlich definiert und kommuniziert wurden, dann kann man das schon bewerkstelligen.

Jan S hat Folgendes geschrieben:

Matlab 6.5 hat die Floating-Point-Einheit beim Rücksprung aus einem MEX per mexErrMsgTxt nicht zurückgesetzt. Deshalb konnte die Rundungsrichtung und die Nutzung der 80-Bit-Register nach einem gecrashten MEX anders sein als davor.

?? Verstehe ich das richtig, dass Mex ein externes Programm aufruft !? Weil in diesem Fall muss ich als der Aufrufende sicherstellen, dass da was "sinnvolles" ankommt, d.h. ich muss dedektieren ob es Probleme gab.
Im Normfall würde ich sagen, ich stelle beim Einsprung in die Mexfunktion fest, wie es aussieht und rufe dann das Programm auf, anhand der Rückgabe kann ich entscheiden was ich mit den Daten mache und eigentlich würde man ja eine Exception bei einem Fehler werfen, die kann man ja abfangen.... (bei C halt über die Rückgabeflags).

Jan S hat Folgendes geschrieben:

Damit wurden die Resultate abhängig von den Programmen die Vorher gelaufen sind.

Ein Crash macht eigentlich jede Weiterverarbeitung sinnlos, denn ein Crash heisst "undefinierter Zustand" und das kann man sicherlich nicht zur Laufzeit fixen, also abbrechen und Fehlermeldung für den User erzeugen.

Jan S hat Folgendes geschrieben:

Dies betraf aber nur Windows-Rechner, die auf Intel-Prozessoren liefen und MEX-Funktionen, die mit nicht MSVC übersetzt wurden. Heute spielt es auch eine Rolle, ob eine Virtuelle Maschine die Floating-Point-Berechnungen per SSE emuliert oder nicht. Natürlich macht es einen Unterschied ob die Lineare Algebra von LAPACK, ATLAS oder MKL berechnet wird.

Das Problem kenne ich, ist aber bei anderen OS ähnlich. Aber wo ist das Problem !? Einmal definieren welche Compiler zu verwenden ist bzw. im Code entsprechend auf den Compiler prüfen wie z.B. wenn kein VS Studio verwendet wird, einfach via Präprozessor einen Fehler erzeugen.

Jan S hat Folgendes geschrieben:

Das Ergebnis von z.B. SUM hängt von der Anzahl der Cores ab und für manche Matlab-Versionen sogar von der aktuellen Belastung der Maschine.

Also bei integralen Datentypen ist definiert was bei einer Summe raus kommen soll. Bei Floatingpoints kann das natürlich anders definiert sein, aber es sollte letztendlich auf die Maschinengenauigkeit exakt sein.

Jan S hat Folgendes geschrieben:

FSEEK muss z.B. auf einer Multi-Core-Maschine nicht erfolgreich sein und ein Scheitern ist nicht mal ein Fehler.

?? Auch das klingt nicht logisch, denn wenn ich einen Dateizeiger positionieren, dann steckt nach der Positionierung der Zeiger an dieser Position (oder es wird ein Fehler geliefert). Bei Multicoresystemen ist das nicht anders. Wenn ich natürlich auch unterschiedlichen Thread versuche die Datei zu schreiben, wird da natürlich was undefiniertes heraus kommen, d.h. Schreiben sollte man immer thread-safe machen. Lesen sollte heute gehen, denn die heutigen Dateisysteme unterstützen paralleles lesen, wobei ich dann eben nur selbst Sorge tragen muss, wohin ich die Daten lesen, also auch hier wieder thread-safe arbeiten.

Jan S hat Folgendes geschrieben:

Bei Tests im Virtual-XP unter Windows 7 tritt das Problem nie auf, da dies nur einen Core emuliert. Ein echtes XP kann aber anders reagieren.

Wieso hier die Unterscheidung Win 7 und XP !? Das Dateisystem ist bei beiden NTFS

Jan S hat Folgendes geschrieben:

Nein, dem widerspreche ich nachdrücklich. Wir müssen um die DFG-Richtlinien einzuhalten unsere Ergebnisse 10 Jahre lang exakt reproduzieren können. Da die Daten mit Matlab6.5/WinXP32 erstellt wurden, muss genau diese Konfiguration auch weiter laufen. Matlab 6.5 läuft unter Win7 nämlich gar nicht.

Was bedeutet "exakt"? Bei Floatingpoint Ergebnissen wäre ja exakt "im Rahmen der Maschinengenauigkeit". Ich meine real gesprochen kann das Problem auftreten, dass Dir eine Maschine auf dem die Software läuft physikalisch kaputt geht und je nach Hardware kann man diese dann nicht mal eben ersetzen, somit sollte man durchaus auch eine Portierung im Kopf haben.
Exakt interpretiere ich so, dass mit den gleichen Daten das gleiche Endergebnis heraus kommen soll und das kann ich anhand der Programmierung anpassen.

Jan S hat Folgendes geschrieben:

Um den Code auch unter modernen Betriebssystemen und Matlab-Versionen laufen zu lassen waren Änderungen an über 9000 Zeilen nötig, darunter auch neue Fälle für die Unit-Tests, wobei auch bestehende Bugs gefixed wurden. Diese Verbesserungen dürfen dann natürlich auf keinen Fall in die alten Versionen eingefügt werden, weil dann wieder eine neue Zertifizierung nötig wäre, was etwa 2 Monate dauert.

Auch hier die Frage, warum müssen 9000 Zeilen gefixt werden, wäre es evtl sinnvoller gewesen, so etwas schon direkt mit einzuplanen !? Zertifizierung ja, das ist nervig, kenne ich aus eigener Erfahrung.

Jan S hat Folgendes geschrieben:

Wenn in 10 Jahren ein Patient die Klinik verklagt, weil er meint falsch operiert worden zu sein, kann ich mich kaum herausreden, dass das Programm heute eine andere Einschätzung der Messdaten gibt, weil Microsoft inzwischen ein Update der API-Funktionen eingespielt hat, dass Vergleiche zwischen leeren ANSI und Unicode-Strings unterschiedlich beantwortet, oder irgend ein vergleichbaren Unfug.

Das sollte aber anhand der Programmierung schon abgefangen werden, d.h. wenn in einer alten Version noch kein Unicode existiert, dann muss ich bei einer neuen eben sicherstellen, dass trotz Unicode mit der gleichen Eingabe das gleiche Ergebnis heraus kommt und das kann ich sehr wohl realisieren.

Jan S hat Folgendes geschrieben:

Matlab ist zwar "recht cross-plattform", das reicht aber nicht aus, wenn die Ergebnisse sicherheitskritisch sind - also z.B. Flugzeuge, Chirurgie an kleinen Kindern, etc.

Warum nimmt man da auch Matlab !? Wenn Du doch eh wie oben beschrieben eh ein System hast, was Du als "statisch" betrachtest, dann würde ich C/C++ nehmen, mit entsprechenden Bibliotheken und gar nicht den zusätzlichen Aufwand via Matlab & Mex machen. Sorry, das hat was von Fummelei dann.
Ich finde es ungemein spannend, wenn man "alte" Datensätze hat, denn damit habe ich ein extrem breites Testfeld. Ich kenne das, dass z.B. in alten Daten manche Informationen nicht vorhanden sind, d.h. man würde beim Import von der alten in die neue Software diese Daten nachpflegen bzw. den Nutzer nachpflegen lassen.

Jan S hat Folgendes geschrieben:

Beim MEX-Interface ist der verwendete Compiler immer ein großes Problem. So ist das Ergebnis einfacher Operationen wie "0.5 < NaN" per IEEE754 zwar wohl definiert. Nur halten sich z.B. die MSVC-Compiler nicht so genau daran. Unter MSVC2008/32 ist das Ergebnis FLASE, wie jeder Vergleich mit NaN. MSVC2010/32 berechnet das je nach Compiler-Flags korrekt in der FPU oder falsch per SSE. MSVC2010/64 schiebt das immer in die SSE-Einheit, so dass man trotz IEEE754 NaNs explizit abfangen muss. Supi.

Wer sagt dass Du MSVC nehmen musst !? Es gibt zig andere Compiler. Aber MSVC ist wirklich in manchen Punkten sehr seltsam.

Jan S hat Folgendes geschrieben:

Entwicklungstechnisch sicherlich nicht sinnvoll. Entweder mache ich einen Bruch bei einer Version oder ich muss entsprechend mitpflegen.

Jan S hat Folgendes geschrieben:

Wenn Du passende Klassen für 8 Matlab-Versionen unter 6 Betriebssystemen warten kannst, ist das kein Problem. Wenn ein umfassender Test aber schon 2 Monate benötigt, ist das nicht machbar.

Ich pflege lieber definierte Versionen meiner Klasse, als einen überladenen Code zu verwenden. Auch die Matlabversionen kann mit unterscheiden, das ist letztendlich nur eine Frage der Strukturierung des Codes

Jan S hat Folgendes geschrieben:

Ja, klar. Aber wenn Du einen blanken Text hast, ist dann die Versions-Information noch erreichbar?

Das ist ja der Sinn eines Dumps.....

Jan S hat Folgendes geschrieben:

Das Einfügen der Versione-Informationen in den Source-Code ist in manchen Punkten unschlagbar (hohe Zuverlässigkeit, ohne externe Software lesbar -z.B. in meinen FileExchange-Programmen kann jeder Laie nachlesen, was warum geändert wurde), aber natürlich auch massive Nachteile: Wirklich große Projekte mit vielen Mitarbeitern wie z.B. Linux lassen sich so nicht managen und an Git etc führt kein Weg vorbei.

Dokumentation muss nach einem definierten Konzept eingefügt werden. Das Konzept muss stehen bevor man beginnt. Die Codes auf dem FileExchanger sind zwar fachlich durchaus sehr gut, wenn ich mir aber die Codebasis anschaue, dann bekomme ich manchmal das Grauen z.B.:

Code:

if
if
else
if
if
else
else
if
if
else
if
else

Funktion ohne Link?

Das ist definitiv nicht mehr lesbar, von Wartbarkeit ganz zu schweigen. So etwas würde ich immer via DNF bzw KNF und ggf Quine McClusky zusammen fassen bzw. dann die boolschen Ausdrücke vor berechnen, so dass man dann so etwas hat

Code:

a = .... x == 5 and y = 10 ....
b = ... x == 3 and y == 7 ...

if a
end

if b
end

Funktion ohne Link?

Gewachsener Code muss auch von Zeit zu Zeit einem kritischen Blick standhalten und leider muss man auch in den sauren Apfel beißen und mal den Code überarbeiten. Entwicklung ist ein kontinuierlicher Prozess, d.h. ich muss mich auch mit bewegen. Natürlich kann ich bis zu einem gewissen Grad stehen bleiben, aber irgendwann knallt es und ich werde mit gerissen und diese Probleme, die dabei entstehen, sind meist größer, als wenn ich kontinuierlich Veränderungen mit nehme und manchmal tut auch ein Cut gut, also einen Fork der Software zu erzeugen. Ich bin kein Freund von "never touch a runnnig system"

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 29.08.2012, 01:33 Titel:

Hallo flashpixx,

Jan S hat Folgendes geschrieben:

Matlab 6.5 hat die Floating-Point-Einheit beim Rücksprung aus einem MEX per mexErrMsgTxt nicht zurückgesetzt.

flashpixx hat Folgendes geschrieben:

?? Verstehe ich das richtig, dass Mex ein externes Programm aufruft !?

Nein. Matlab verwendet als Standard 64-Bit Doubles als Zwischenwerte. Wenn man in einer Mex-Funktion die Floating-Point-Unit umkonfiguriert, z.B. per _CONTROL87() die Verwendung der 80Bit Register zuläßt um die Zwischenwerte mit hoher Genauigkeit zu speichern, wurde dies bei einem Crash nicht ordentlich zurückgesetzt. Danach verwendet Matlab solange die 80 Bit Register, bis dies in einem anderen MEX neu gesetzt wird, oder z.B. per nicht dokumentierte Befehl "feature('SetPrecision', 53)".
Als Folge davon lieferten mein Programme nach dem Durchlauf der Unit-Test leicht andere Werte als ohne Unit-Test, da im Laufe der Tests auch die Reaktion auf fehlerhafter Inputs untersucht wird, also ein Crash provoziert wird. Nach einem Crash mit einer Fehlermeldung abzubrechen reichte also nicht. Um wirklich sicherzugehen musste auch die Matlab Session neu gestartet werden - zumindest bis ich die Quelle dieser Probleme identifiziert hatte und die FPU-Flags vor jedem mexErrMsgTxt zurückgesetzt hatte.

In modernen Matlab-Versionen wird aber beim Rücksprung aus einem MEX ordentlich aufgeräumt. Aber Du kannst Dir vortsllen, wie lange es gedauert hat, bis ich herausbekam, wieso die Integration-Tests über den kleine Unterschiede in den Ergebnissen stolperten, falls vorher die 44'000 Zeilen der Unit-Tests erfolgreich durchgelaufen waren...

flashpixx hat Folgendes geschrieben:

Aber wo ist das Problem !? Einmal definieren welche Compiler zu verwenden ist bzw. im Code entsprechend auf den Compiler prüfen wie z.B. wenn kein VS Studio verwendet wird, einfach via Präprozessor einen Fehler erzeugen.

Das Verhalten von MSVC2008 und 2010 unterscheidet sich, wobei jeweils auch die 32 und 64 Bit-Varianten unterschiedliches verhalten zeigen. Da Matlab 2009b und 2011a jeweils unterschiedliche MSVC Versionen benötigen, wäre eine harte Festlegung auf einen Compiler das Ende der Möglichkeit den Code auf neuere Systeme zu portieren.

Zitat:

Das kommt auf die Reihenfolge der Summanden an:

Code:

sum([1, 5e15, 5e15, 1, -5e15, -5e15])

Funktion ohne Link?

Dies ergibt z.B. 0, statt der erwarteten 2. Das ist nicht gerade bis auf Maschinengenauigkeit exakt. Auch Sortieren hilft hier nicht. Wenn dann noch moderne Matlab-Versionen bei langen Vektoren (so weit ich mich erinnere ab 89'000 Elementen) die Aufgabe auf mehrere Thread verteilen, die jeweils Teilsummen ausrechnen, ist das Ergebnis der Summe zwar mathematisch wohl definiert, aber die Ausgabe des SUM-Befehls eben nicht. Um genau zu sein: Die numerische Berechnung einer Summe ist bei begrenzter Precision instabil. Es gibt zwar stabilisierte Algorithmen zur Summenberechnung (siehe FEX: XSum), aber das Kern-Problem bleibt: Es gibt immer einen Vektor bei dem SUM (oder XSUM) sich deutlich von der Summe unterscheidet.

Jan S hat Folgendes geschrieben:

FSEEK muss z.B. auf einer Multi-Core-Maschine nicht erfolgreich sein und ein Scheitern ist nicht mal ein Fehler.

Zitat:

?? Auch das klingt nicht logisch, denn wenn ich einen Dateizeiger positionieren, dann steckt nach der Positionierung der Zeiger an dieser Position (oder es wird ein Fehler geliefert).

Es geht nicht darum, dass mehrere Threads in einem File wüten. Es geht um einen einzelnen FSEEK-Befehl, während andere Prozesse die Platte (und den Prozessor?) stark belasten.
Das Problem der Compiler-Hersteller war, dass FSEEK eventuell einen Core sehr lange lahmlegen kann, falls die Festplatte gerade stark belastet wird. Deshalb wurde beschlossen FSEEK in C/C++/Fortran/Java nur kurz auf einen Erfolg warten zu lassen und die erreichte File-Position zurückzuliefern. Falls diese von der gewünschten Position abweicht, soll der Programmierer "nachiterieren". Das Scheitern von FSEEK ist also ein gewolltes Verhalten um die Multi-Core-Effizienz zu steigern. Leider kommt in Matlab nur ein Flag als Rückgabe von FSEEK an, so dass eine starke System-Last zu falschen File-Positionen führen kann, wenn man dieses Status-Flag nicht abfragt. Wenn man es dennoch macht, wundert man sich beim Debuggen, da der Fehler ja nicht reproduzierbar ist.

Lösung:

Code:

function SafeFSeek(FID, Pos)
for dull = 1:20
if fseek(FID, Pos, -1) == 0
return;
end
end
error('Fseek failed - perhaps heavy system load?!'):

Funktion ohne Link?

Natürlich kann man per FERROR noch bessere Fehlermeldungen hinbekommen. Und für relative File-Positionen kann man noch per FTELL die benötigte absolute Position ausrechnen. Insgesamt bleibt aber ein ungutes Gefühl, dass FSEEK unter Matlab unreproduzierbar schwächeln kann. Oder konnte? Ich habe kein R2012a und unter 2009b habe ich es nur ein einziges Mal unter Test-Bedingungen erzeugen können.

Jan S hat Folgendes geschrieben:

... 10 Jahre lang exakt reproduzieren können. ...

Das Problem mit Hardware-Defekten läßt sich mit einer virtuellen Maschine leicht lösen.

flashpixx hat Folgendes geschrieben:

Exakt interpretiere ich so, dass mit den gleichen Daten das gleiche Endergebnis heraus kommen soll und das kann ich anhand der Programmierung anpassen.

Ein einfaches Gegenbeispiel ist die exakte Reproduzierung der Ergebnisse von Matlab's ACOS. Prktischerweise gibt TMW die Quelle an, nämlich die FDLIBM von netlib.org. Nun sind die ACOS Implementierungen bei +-1 numerisch instabil. Ich habe einige Zeit damit verbracht verschiedene Compiler mit verschiedenen Optimierungs- und SSE-Flags auf den Code loszulassen. Trotzdem konnte man immer Inputs finden, bei denen der Output mehr als 100 Eps von einander abweicht - und das auf dem gleichen Prozessor.
Dabei ist ACOS noch recht einfach. Die exakt gleich Ergebnisse für eine SVD oder Eigenwert-Berechnung einer großen Matrix auf unterschiedlichen Prozessoren, Betriebssystemen, SSE&FPU Umgebungen und Compiler/Matlab-Versionen zu erzeugen ist dagegen eine hoffnungslose Aufgabe.

flashpixx hat Folgendes geschrieben:

Auch hier die Frage, warum müssen 9000 Zeilen gefixt werden, wäre es evtl sinnvoller gewesen, so etwas schon direkt mit einzuplanen !?

Wie soll ich denn 1999 einplanen, dass TMW entscheidet in 2010b das Verhalten von STRNCMP zu ändern?!

Code:

% Matlab 2011b: STRNCMP('a', 'b', 0) == TRUE, 2009a: FALSE
% Matlab 2011b: STRNCMP('a', 'a', 2) == TRUE, 2009a: FALSE

Funktion ohne Link?

Oder dass FOPEN in 2008b plötzlich kein VaxD-Format mehr unterstützt? Beide Änderungen wurden übrigens nicht einmal öffentlich dokumentiert. Das Anpassen den Codes für neuer Matlab-Versionen läßt sich weder vermeiden noch vorher einplanen.

Jan S hat Folgendes geschrieben:

flashpixx hat Folgendes geschrieben:

Das glaube ich kaum. 1999 waren sogar die Unicode-Standards anders. Natürlich kann man dann eigene ICU-Bibliotheken hinzulinken, um gleiches Verhalten zu erzwingen. Und dann muss man diese Bibliotheken noch mal eben an WindowsXP (in der virtuellen Maschine) und den Borland BCC 5.5 Compiler anpassen. Und die bei dieser Anpassung entstandenen Bugs wieder per Unit-Tests finden und fixen. Und wenn dann noch ein paar andere Bibliotheken dazu kommen, ist man schnell Monate lang beschäftigt.

Jan S hat Folgendes geschrieben:

Matlab ist zwar "recht cross-plattform", das reicht aber nicht aus, wenn die Ergebnisse sicherheitskritisch sind - also z.B. Flugzeuge, Chirurgie an kleinen Kindern, etc.

flashpixx hat Folgendes geschrieben:

Warum nimmt man da auch Matlab !?

Die in diesem Thread häufig auftauchenden "!?" kommen mir unsachlich vor. Möchtest Du die Frage beantwortet haben oder nicht? Ich programmiere seit über 30 Jahren und ich habe die Platform aus verschiedenen guten Gründen gewählt. C/C++ kam auf jeden Fall nicht in Frage.

Jan S hat Folgendes geschrieben:

flashpixx hat Folgendes geschrieben:

Wer sagt dass Du MSVC nehmen musst !? Es gibt zig andere Compiler.

Das war ein Beispiel. Genau wie der MSVC haben auch Intels ICC, GCC, Borland BCC, OpenWatcom OWC und LCC ihre Eigenarten. Wenn man dann noch die 32/64-Bit Varianten und die FPU/SSE Unterschiede berücksichtigt, kann man sich mit der Wahl des C-Compilers beliebig viel Probleme bereiten.

flashpixx hat Folgendes geschrieben:

Die Codes auf dem FileExchanger sind zwar fachlich durchaus sehr gut, wenn ich mir aber die Codebasis anschaue, dann bekomme ich manchmal das Grauen ...

Ich weiß nicht, welche Funktion Du meinst. Hilfreicher als eine allgemeine Kritik wären konkrete Verbesserungsvorschläge, die in der FEX immer gerne gesehen werden. Auch ein Tutorial über die von Dir eingesetzten Methoden wären im goMatlab-Forum gut aufgehoben.

flashpixx hat Folgendes geschrieben:

Ich bin kein Freund von "never touch a runnnig system"

Ja, das habe ich verstanden. Je komplexer mein Arbeitsumfeld wurde, desto mehr habe ich von "never touch a running system" profitieren können. Die Wartung des Universitäts-DNS-Servers, die Instandhaltung des Codes für die Auswertung mehrerer 1000 Patienten-Datensätze die in unterschiedlichen Kliniken über mehr als 10 Jahre aufgenommen wurden, die Pflege des Rechners meiner Schwiegermutter - all dies wäre durch beherztes, mutiges und dynamisches Ändern schnell im Desaster geendet. Komplexe Systeme entwickeln ein erstaunliches Eigenleben und ich glaube nicht daran, dass man ein großes Programm mit irgendwelchen Methoden dazu bringen kann, nach substantiellen Änderungen die gleichen (exakt, Maschinen-Genauigkeit oder wie auch sonst immer) Ergebnisse zu liefern. Ich wäre schon froh, wenn Windows auf meinem Rechner morgens und abends gleich reagieren würde.

Gruß, Jan

flashpixx

Forum-Guru


	Beiträge: 355

	Anmeldedatum: 19.04.08

	Wohnort: ---

	Version: ---

Verfasst am: 29.08.2012, 12:54 Titel:

Jan S hat Folgendes geschrieben:

Matlab verwendet als Standard 64-Bit Doubles als Zwischenwerte. Wenn man in einer Mex-Funktion die Floating-Point-Unit umkonfiguriert, z.B. per _CONTROL87() die Verwendung der 80Bit Register zuläßt um die Zwischenwerte mit hoher Genauigkeit zu speichern, wurde dies bei einem Crash nicht ordentlich zurückgesetzt. Danach verwendet Matlab solange die 80 Bit Register, bis dies in einem anderen MEX neu gesetzt wird, oder z.B. per nicht dokumentierte Befehl "feature('SetPrecision', 53)".

Das stimmt so nicht, Double sind per Defintion 64 Bit ( http://de.wikipedia.org/wiki/Doppelte_Genauigkeit ). Im Grunde wäre hier aber Ansatz, dass der kleinste gemeinsame Nenner das entscheidende ist, d.h. wenn Du eben mit 64Bit Datentypen arbeitest, dann ist das der Nenner. Außerdem habe ich mal gelernt, dass man diese "Bitschubserei" nicht machen sollte, weil sie nicht direkt durch den Compiler optimiert werden kann. Außerdem würde ich dann direkt die SIMD Extension mit 128 Bit nehmen, falls ich diese Präzision brauche, also eine passende 2er Potenz.
Die Frage wäre aber, falls ich eben eine Genauigkeit brauche, die größer ist als 64 Bit und ich eben nicht die SIMD Typen verwenden kann, dass ich mir klassisch via OOP einen eigenen Datentyp baue, der z.B. dann eben die 80 Bit darstellt. Durch entsprechende Polymorphie kann ich damit passend rechnen und ich habe die entsprechende Bitarithmetik innerhalb einer Klasse.
Mir würde es aber interessieren wofür man 80Bit Genauigkeit braucht? Denn das sehe ich nicht wirklich, ich dann durch passende Skalierung auch ohne weiteres mit 64 Bit auskommen.

Jan S hat Folgendes geschrieben:

In modernen Matlab-Versionen wird aber beim Rücksprung aus einem MEX ordentlich aufgeräumt. Aber Du kannst Dir vortsllen, wie lange es gedauert hat, bis ich herausbekam, wieso die Integration-Tests über den kleine Unterschiede in den Ergebnissen stolperten, falls vorher die 44'000 Zeilen der Unit-Tests erfolgreich durchgelaufen waren...

Wäre es dann nicht sinnvoller zu updaten? Also nachdem der Fehler gefixt wurde die Matlabversion zu wechseln

Jan S hat Folgendes geschrieben:

Nein das meinte ich nicht, sondern dass man eben sagt "läuft nur mit MSVC" oder GCC, also auf einen Compilerhersteller.

Jan S hat Folgendes geschrieben:

Ich nutze diese Größe nur unter C++ und da konnte ich selbst bei Threads via OpenMP das Problem noch nicht feststellen. Finde ich aber doch interessant, dass Matlab da Probleme macht. Ich arbeite halt primär via double Datentypen

Jan S hat Folgendes geschrieben:

http://www.cplusplus.com/reference/clibrary/cstdio/fseek/
http://www.cplusplus.com/reference/clibrary/cstdio/ftell/

Das wäre mir neu, hast Du da für C/C++/Java eine Quelle? Mir ist dieses Verhalten definitiv nicht bekannt, bei konkurierenden Threads muss ich natürlich selbst absichern, aber das ist klar, weil weder fseek noch ftell thread-safe sind, aber innerhalb eines Threads kann das nicht passieren und nur weil es Multicore ist, heißt das nicht, dass die Zugriffe auf das Dateisystem zwischen den Cores beliebig hin und her gereicht werden.

Jan S hat Folgendes geschrieben:

Naja da müsste man ja dann mal TMW anfragen, denn das finde ich nicht in Ordnung, vor allem weil ja die Lizenzen durchaus Geld kosten, dann sollte wenigstens eine vollständige und zeitnahe Doku der Änderungen möglich sein

Jan S hat Folgendes geschrieben:

Die Frage wäre "brauchst Du wirklich Unicode"? Generell würde ich von klassischen Stringstrukturen eh abraten, sondern das ggf anders lösen wie z.B. Hashmaps o.ä. Damit hätte man eben die Stringmanipulation nur an 2 Stellen, nämlich beim Einlesen und bei der Ausgabe.

Jan S hat Folgendes geschrieben:

Matlab ist zwar "recht cross-plattform", das reicht aber nicht aus, wenn die Ergebnisse sicherheitskritisch sind - also z.B. Flugzeuge, Chirurgie an kleinen Kindern, etc.

Dann wäre die Frage, warum dann überhaupt Matlab? Weil wenn ich solche Anforderungen habe, dann würde ich das System von Grund her z.B. auf C99 Standard implementieren. Habe zwar dann einiges an Vorarbeit, aber ich halte die Codestrukturen flacher

Jan S hat Folgendes geschrieben:

Das !? ist völliges Unverständnis. Zur Programmierzeit, mir fehlen dann noch 10 Jahre *g*. Die Frage ist aber, wenn Du die ganzen Punkte die Probleme machen, da Du ja Mex, Matlab und dann noch diverse Compilerspezifikationen abfangen musst, warum dann eben so etwas baut? Matlab nutzt intern auch "nur" Bibliotheken, d.h. wenn ich die direkt in mein Programm linke, dann habe ich "nur" noch die Compilerspezifikation und eben die Eigenheiten des Codes / Bibliotheken, d.h. 2 Komponenten weniger und damit auch 2 potentielle Fehlerquellen weniger. Also eben eine flache Struktur.

Jan S hat Folgendes geschrieben:

Du sprichst von http://de.wikipedia.org/wiki/Streaming_SIMD_Extensions ? Das ist doch erst Anfang 2000 auf dem Markt

Jan S hat Folgendes geschrieben:

Die Wartung des Universitäts-DNS-Servers, die Instandhaltung des Codes für die Auswertung mehrerer 1000 Patienten-Datensätze die in unterschiedlichen Kliniken über mehr als 10 Jahre aufgenommen wurden, die Pflege des Rechners meiner Schwiegermutter - all dies wäre durch beherztes, mutiges und dynamisches Ändern schnell im Desaster geendet. Komplexe Systeme entwickeln ein erstaunliches Eigenleben und ich glaube nicht daran, dass man ein großes Programm mit irgendwelchen Methoden dazu bringen kann, nach substantiellen Änderungen die gleichen (exakt, Maschinen-Genauigkeit oder wie auch sonst immer) Ergebnisse zu liefern. Ich wäre schon froh, wenn Windows auf meinem Rechner morgens und abends gleich reagieren würde.

Zu der Windows-Aussage verkneife ich mir jetzt einen bissigen Kommentar *g*
Nimm' dies nicht persönlich, ich schätze wirklich die Diskussionen sehr mit Dir, aber genau das ist der Kernpunkt für mich, Du hast ein komplexes System geschaffen, aber "muss" es wirklich so komplex sein? Als Bsp der DNS, das ist überhaupt nicht komplex, natürlich wenn ich dahinter alles in Textdateien konfiguriere ja, aber wenn ich meinen DNS z.B. an mySQL, LDAP o.ä. anbinde, dann ist das ganze systematisch strukturiert und ich kann mit einer entsprechenden GUI recht viel verwalten.
Zu den Codingpunkten wäre meine Frage, hast Du Dir das System nicht vielleicht selbst zu komplex aufgebaut? So dass man an vielen Punkten hätte man z.B. auf andere Komponenten gesetzt evtl sich gar nicht die geschilderten Probleme geschaffen?

Beste Grüße

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 29.08.2012, 17:04 Titel:

Hallo flashpixx,

Intels Pentium Prozessoren erlauben Zwischenwerte der FPU-Berechnungen in 80 bit breiten Registern zu speichern. Dies geschieht ohne Zeitverlust und erlaubt z.B. die Summe 1+1e15+1e15+1-1e15-1e15 korrekt zu berechnen ohne an die Grenze der 53 Mantissen-Bits zu stoßen. Das ist ein ausgesprochen nettes Feature, welches aber leider z.B. von den MSVC-compilern ignoriert wird. Mit anderen Compilern läßt sich dies aber hervorragend nutzen und machne Funktionen werden durch die schnellere Konvergenz alternierender Reihen deutlich beschleunigt. Ein Festkomma-Register wäre natürlich noch schöner, aber die Prozessoren-Hersteller weigern sich (bis auf seltene Ausnahmen), dieses seit Jahrzehnten von Numerikern gewünschte Feature zu implementieren.

Mit SIMD oder per Software emulierten 80 Bit Werten hat dies also nichts zu tun.

Zitat:

Mir würde es aber interessieren wofür man 80Bit Genauigkeit braucht?

Ein einfaches DOT-Produkt kann davon profitieren:

Code:

ones(1, 6) * [1; 1e15; 1e15; 1; -1e15; -1e15]

Funktion ohne Link?

Das ist ja wieder genau das Beispiel mit der Summe. In realen Programmen wird dies wesentlich unübersichtlicher, wenn man z.B. ein Gleichungssystem mit 100'000 Variablen löst. Dann ist jede Verbesserung der Accuracy bei DOT sehr willkommen, vor allem wann man dafür nicht die Precision ändern und die BLAS und LAPACK-Bibliotheken mit neuen per OOP kreierten Datentypen nachprogrammieren muss.

Jan S hat Folgendes geschrieben:

Das Verhalten von MSVC2008 und 2010 unterscheidet sich, wobei jeweils auch die 32 und 64 Bit-Varianten unterschiedliches verhalten zeigen...

flashpixx hat Folgendes geschrieben:

Nein das meinte ich nicht, sondern dass man eben sagt "läuft nur mit MSVC" oder GCC, also auf einen Compilerhersteller.

In konkreten Fall hieße dies also: Läuft nur mit MSVC2008/32bit mit fp:fast Flag und ohne SSE2. Dann würden aber Benutzer eines 64 Bit-Systems in die Röhre schauen.

flashpixx hat Folgendes geschrieben:

Das verstehe ich nicht. welche "Größe"? Wo macht Matlab Probleme? Was hat das Arbeiten mit DOUBLE Datentypen damit zu tun?

flashpixx hat Folgendes geschrieben:

Die Frage wäre "brauchst Du wirklich Unicode"?

Nochmal: Das Thema Unicode war nur ein Beispiel. Es geht nicht darum, ob ich das brauche, aber es spielt eine Rolle, wenn TMW das Verhalten von STRNCMP an die Unicode-Libs anpasst. Und ja, ich brauche Unicode.

Zitat:

Dann wäre die Frage, warum dann überhaupt Matlab?

Ich hatte erklärt, wie unterschiedlich und regellos die C-Compiler z.B. auf Vergleiche mit NaNs reagieren. Es gibt aber natürlich noch viele weitere solcher Beispiele, bei denen sich Compiler nicht exakt an die Specifikationen halten. Matlab fängt tausende solcher Ausnahmen bereits ab, so dass "x < NaN" seit mindestens R4 immer ordentlich FALSE antwortet, und zwar auf Intel-PCs mit und ohne SSE-Einheit, Alpha-Mips, PowerPC- und Intel-Macs, und Linux Maschinen. Während die gebräuchlichen C-Compiler seit 1999 viele Hundert Bugs gefixt haben und sich gerade bei der 64-Bit Portierung nicht gerade mit Ruhm bekleckert haben, ist Matlab ein recht träger aber doch ruhiger Fels in der Brandung.
Wenn ich an andere Labore Source-Code ausliefere, muss ich mir keine Gedanken machen, ob dort ein Physiotherapist den Compiler richtig initialisiert, damit auch triviale Dinge wie NaNs korrekt behandelt werden. Natürlich würden die Unit-Tests solche Probleme bemerken. Aber "Starte dies in Matlab 65, 2008b, 2009a oder 2011b" ist deutlich einfacher als die Anleitung zur Installation und "richtigen" Nutzung eines C-Compilers, siehe die in http://www.mathworks.com/matlabcent.....mex-files-compiling-error beschriebenen nervigen Workarounds.

flashpixx hat Folgendes geschrieben:

Als Bsp der DNS, das ist überhaupt nicht komplex, natürlich wenn ich dahinter alles in Textdateien konfiguriere ja, aber wenn ich meinen DNS z.B. an mySQL, LDAP o.ä. anbinde, dann ist das ganze systematisch strukturiert und ich kann mit einer entsprechenden GUI recht viel verwalten.

Es gibt heute keine Software ohne Bugs. Den DNS dann auch noch von mehreren anderen Diensten abhängig zu machen und sogar noch per GUI zu administrieren bedeutet immer zusätzliche Abhängigkeiten und damit Fehlerquellen.
Natürtlich benutze auch ich unter Windows lieber den Windows Explorer als der DIR-Befehl im CommandWindow. Das hat aber wieder die bekannten Nachteile: Hat der Pfad mehr als MAX_PATH Zeichen, kann der Explorer ein File nicht in den Recycler bewegen. Wenn dem Server die Change-Notification-Handles ausgehen, wird eine per Drag&Drop bewegte File-Liste nicht komplett in den gleichen Ordner geworfen, sondern die unterschiedlichen Files landen in unterschiedlichen Ordnern je nach ihrer Position auf dem Bildschirm. Das Suchen nach Dateien im Explorer wird seit Windows 2000 immer unzuverlässiger. USW.

flashpixx hat Folgendes geschrieben:

Nimm' dies nicht persönlich, ich schätze wirklich die Diskussionen sehr mit Dir, aber genau das ist der Kernpunkt für mich, Du hast ein komplexes System geschaffen, aber "muss" es wirklich so komplex sein?

Das ist einfach zu beantworten: Ja. Ich habe die Gründe dafür bereits erklärt.
Ich habe weder Anlass noch Interesse mit Dir über die Organisation und Komplexität meiner Projekte zu diskutieren. Einerseits habe ich diesbezüglich keine offenen Fragen, andererseits hast Du nur einen sehr spärlichen Einblick in die Fragestellungen und Lösungsmethoden meiner Projekte.
Ich habe von meinen Erfahrungen berichtet und es ist selbstverständlich, dass Du bei Deinen Projekten andere Erfahrungen gemacht hast. Möglichweise helfen unsere Erfahrungen den Fragestellenden zu erkennen, dass er mit "Debuggen und Dokumentieren" eines fremden Source-Codes ein großes Fass aufmacht, aufmachen könnte, sollte oder müsste.

Ich werde mich nun wieder anderen Threads zuwenden.

Gruß, Jan


Einstellungen und Berechtigungen
Beiträge der letzten Zeit anzeigen:	Du kannst Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen. Du kannst Dateien in diesem Forum posten Du kannst Dateien in diesem Forum herunterladen

Impressum | Nutzungsbedingungen | Datenschutz | FAQ |

RSS

Hosted by:

Copyright © 2007 - 2025 goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks

MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.