Hier mal was aus der Sparte skuriles:



Dies ergibt am Schluss "NaN". Warum? Folgendes:



Ergibt jedesmal 0 - selbst wenn die beiden Komponenten vor dem Bruch sehr wohl mit Zahlen besetzt sind. dPi ist als double definiert.

Wenn ich jede Komponente einzeln in einer Variable speichere und dann diese sehr triviale Operation durchführe, funktioniert es.

Kann mich mal jemand erleuchten? Ich steh auf dem Schlauch.

Die Berechnung wird mit Integern durchgeführt. Integer durch Integer ist immer ein Integer im Resultat, dadurch gehen die Nachkommastellen verloren. Erst nach diesem Verlust wird das Ergebnis in einen Double umgewandelt. Wenn du die Operanden erst in Doubles zwischenspeicherst, wird die Berechnung natürlich mit dem "gewünschten" Typ durchgeführt und das Ergebnis paßt.

Versuche es mal mit explizitem Casten und einem ".0" (markiert die Zahl als Double) an der Konstante:
(double) Match->PDF[i].iGrayValue * (double) Match->PDF[i].iAmount / 256.0

Das ist ja interessant. Es war mir nicht bekannt, dass der Datentyp eines Resultats durch die Datentypen in der Gleichung bestimmt werden und nicht durch die Variable, in der die Gleichung gespeichert wird.
Ich hatte zwar so etwas ähnliches vermutet und habe auch folgendes probiert:



Aber das funktionierte nicht. Ich werde aber deine Methode mal probieren, danke!

P.S.: Aus Neugier: Angenommen ich hätte in der Gleichung einen Double und einen Integer Wert. Würde dann der nächst Präzisere Datentyp gewählt? In dem Fall Double?

Das ist ja auch nicht ähnlich, sondern ganz anders. Da wird erst in den Klammern die komplette Berechnung mit Integern durchgeführt inklusive Division, wodurch Nachkommastellen verloren gehen. Dieses "beschädigte" Ergebnis wird, statt implizit bei der Zuweisung gecastet zu werden, jetzt halt explizit vor der Zuweisung gecastet, aber der Schaden ist längst entstanden.

Genau deshalb müssen die Operanden schon vorher umgewandelt werden, damit die Operation selbst mit dem richtigen Typ und daher ohne Verlust von Nachkommastellen durchgeführt wird.



Ja, im Prinzip schon. In deiner Berechnung sollte es schon reichen, wenn du 256 durch 256.0 ersetzt, damit ist der zweite Operand der Division ein Double statt Integer und der erste Operand wird implizit gecastet. Der erste Operand ist in dem Fall das Ergebnis der Multiplikation, die noch mit zwei Integern durchgeführt wird. Nachkommastellen sind an dieser Stelle unwichtig, die Multiplikation zweier Ganzzahlen erzeugt ja keine. Wenn die Zahlen groß genug sind, kann es trotzdem kritisch werden. Beispiel:



Was passiert hier? Für e ist das leicht zu klären. Dank explizitem Casting wird jede Operation mit Doubles durchgeführt, das Ergebnis in e ist 100000.0 oder zumindest etwas mit nur sehr kleiner Abweichung dazu. Floatingpoint-Werte sind nämlich niemals ganz präzise, das kann auch noch zur Stolperfalle werden falls du nicht aufpaßt. Wenn du das Ergebnis prüfen willst, greift unter Umständen (e == 100000.0) nicht, sondern erst sowas wie (abs(e - 100000.0) < 1.0e-6). Bei speziell diesen Zahlen ist aber ein exaktes Ergebnis wahrscheinlich, weil sie exakt als Double dargestellt werden können.

Aber erstmal zur Berechnung ohne explizites Casten. Erst wird a * b berechnet, was 10 Milliarden ergibt. Das paßt leider nicht in einen Integer, es werden also nur die unteren 32 Bit des Ergebnisses behalten. Das entspricht 1410065408, was für die nächste Operation implizit (weil der Divisor von einem genaueren Typ ist) in 1410065408.0 gecastet wird. Nach der Division steht in d also 14100.65408 (bzw. eine Double-Repräsentation sehr nah dran), was nicht ganz dem erwarteten Ergebnis entspricht.

Tatsache - dein Code hat funktioniert



Jup - das Thema hatten wir schonmal - mit ausführlicher Erklärung deinerseits weshalb das so ist (war glaub sogar in diesem Thread - ich fand die Erklärung auf jeden Fall super). I prüfe allerdings praktisch nie den Zahlwert exakt, sondern breche ab, sobald die zu prüfende Variable(n) unter einen bestimmten Wert sinkt/en (wie auch üblich in statistischen Ausgleichungen). Somit umschiffe ich das dann recht schön.

Ich habe mal wieder ein Problem (juhui ). Es sind, mal wieder, die beliebten Pointer. Zumindest glaube ich, dass dies das Problem ist. Und zwar stürzt mir das Programm ab, je nachdem, wohin ich meine 'new ...' Anweisungen setze.

Ich habe in meiner Klasse 3 Methoden:

- m_LSM_Initialize (gibt den Variablen Werte - idR. 0, 0.0, NULL)

- m_LSM_Iteration (Eine iterationsschleife, die eine Ausgleichung ausführt)

- m_LSM_Main (Liest die Bilder und Files ein und ruft dann anschliessend m_LSM_Iteration auf - wenn die Methode 'true' zurück gibt, werden die Koordinaten geschrieben)

Und nun das Problem: Ich habe im Header File (LSM.h) folgendes definiert:



Und im Source-File (LSM.CPP) platziere ich das da:



Das Problem? Je nachdem, in welche Methode ich den zweiten Teil platziere, funktioniert das Programm oder eben nicht.

Platziere ich die beiden 'new' Anweisungen ins m_LSM_Initialize, dann stürzt das Programm mit einer OpenCV Fehlermeldung ab, dass die Werte ausserhalb des Bildbereiches liegen, was aber nicht stimmt. Was wirklich passiert ist, dass er in der ersten Iteration die richtigen Werte aus den beiden Files rausliest und in der nächsten Iteration nicht auf die nächste Zeile springt - somit immer beim gleichen Punkt bleibt.

Ich habe mal valgrind drüber laufen lassen, und das da stach mir ins Auge (es gibt noch 3-4 gleiche Fehler):



Sieht so aus, als würde er auf etwas zugreifen, was nicht mehr existiert. Da ich den Pointer aber nicht gelöscht habe, verwundert mich das ein wenig.
Wenn ich dann die beiden 'new' Anweisungen ins m_LSM_Iteration reinpacke, funktioniert es einwandfrei. Valgrind hat dann auch keine grösseren Probleme mehr gefunden:



Verwundern tut mich das v.a. deshalb, weil ich eine ähnliche Konstruktion in einem anderen Programm habe und es da einwandfrei funktioniert.

Hat jemand grad eine Idee, woran das liegen könnte? Auf Wunsch kann ich auch gerne den ganzen Quellcode zur Verfügung stellen (gekürzt - die Algorithmen selbst sind ja nicht so wichtig).

P.S.: Die übrigen Leaks stammen von der MATPACK-Library. Falls jemand eine gute Mathematik Library kennt, wo man relativ einfach Matrizen, Vektoren etc. basteln und berechnen kann, so wäre ich froh um einen Hinweis

Schwierig, ohne den Code zu sehen.
Sind iSearchSize und iSearchSize konstant? Oder ändern die sich vielleicht irgendwo (werden vielleicht erst später gesetzt?). Es kann auch immer an ganz anderen Variablen liegen, die dann Nebenwirkungen haben.

Du definierst globale Variablen in einer Header-Datei? Ganz böse, damit hätte jede der Source-Dateien, die diesen Header inkludiert, eine eigene Kopie. Eigentlich sollte bei sowas der Linker über mehrfach definierte Symbole motzen. Versuch mal stattdessen, deine globalen Pointer in einer Source-Datei zu definieren und im Header nur eine Deklaration unterzubringen. Etwa so:




Falls die Methoden, die diese Variablen verwenden, auf mehrere Sourcen aufgeteilt sind, ist das mit hoher Wahrscheinlichkeit das Problem. Wenn nur eine Source den Header inkludiert, ist es nur noch unsauber, das Problem müßte dann aber woanders liegen.

Dem kann ich gern nachhelfen

http://www.photogrammetry.ethz.ch/gener ... SM_Odd.zip (übersichtshalber ist der Algorithmus selbst im m_LSM_Iteration nicht drin)

Die iSearchSize ändert sich während den Iterationen nicht. Müsste also an sich kein Problem geben.



Die Variablen sind als 'private' deklariert. Aber es stimmt von daher schon: jede source, die das Ding included, bekommt das. Da ich aber momentan nur mit einer Source arbeiten, wird das wohl der Grund sein, warum er sich nicht beschwert?

Momentan liegen alle methoden in der gleichen source-Datei drin.

Edit: Mit



im Header, beschwert sich der Compiler:

Ah, also Membervariablen innerhalb einer Klasse. Ich bin von globalen Variablen ausgegangen, weil für mich nichts anderes ersichtlich war aus deinem Posting. In dem Fall solltest du das dazu von mir gesagte ignorieren.

Vielleicht irre ich mich, aber in der "m_LSM_Initialize" erstellst du das SearchValues-Array immer mit [0], da iSearchSize in der selben Methode auf 0 gesetzt wird und nirgends sonst in der Methode einen sinnvollen Wert bekommt.

Du hast ja so recht! Manchmal sieht man den Wald vor lauter Bäumen nicht mehr. Dank dir!



Ja - ich wollte ursprünglich den ganzen Quellcode posten, was jedoch etwas zu lang geworden wäre. Ich habe so die Angewohnheit, nicht genau genug zu spezifizieren (mehr aus Unwissenheit als aus Absicht ).

Da wir ja grad so schön dabei sind, hier noch ein kleines Problem:



Ist ja ein relativ simpler Fall - ich lese aus einem File so lange aus, bis keine Einträge mehr drin sind. Soweit so gut - nur scheint er mir immer noch einen zusätzlichen Eintrag zu lesen. D.h. wenn ich 3 Einträge in der Quelldatei habe, schreibt er mir 4 raus. Ich vermute, dass ein Carriage-Return versteckt ist, den ich nicht löschen kann. Im Editor ist auf jeden Fall keiner zu sehen und ich bin da ein wenig irritiert. Die Ausgabe der 4. Zeile ist nämlich wilkürlich (also irgendwelche Zahlen und nicht etwa die letzte Reihe nochmal).

Der gesamte Quellcode ist hier zu finden: http://www.photogrammetry.ethz.ch/gener ... angles.zip

Hallo Hypo,
bei mir ist am Ende der Datei noch ein Zeilenumbruch (sogar ein windowsmäßiger). Dadurch ist das eof() noch nicht durch das letzte Float einlesen erreicht. Hier eine recht interessante Beschreibung der Fallstricke bei eof():
http://fara.cs.uni-potsdam.de/~kaufmann//faqs/eof.pdf

Interessant. Unter Linux seh ich da irgendwie nichts. Ich werde sehen, ob mir dein PDF weiterhilft. Sieht ja sehr gut aus - danke!

Ich hab hier wieder so ein interessantes Problem:

Und zwar habe ich ein Programm, das in C geschrieben wurde. Den Quellcode habe ich, aber ich bin zu faul und zu wenig erfahren, das Ganze nach C++ zu konvertieren. Idee: Ich rufe die Binary aus dem C++ code auf.

Soweit so gut - das funktioniert auch. Wenn ich aber dem C-Programm sage, es soll einen Integer 'return'-en, gibt's Ärger.

Dieser Aufruf geht ohne weiteres (ohne return im C-Programm):



Wenn ich allerdings den integer-Wert, den das C-Programm ins return speichert, so im C++ Programm speichern will, gibt's ein kleines Chaos:



Der Code im C-Programm sieht so aus (teilweise):



Ich 'return'-e also das 'm'. Wenn das Programm durchläuft, zeigt es mir die richtige Anzahl an, via das fprintf (611). Wenn ich aber dann das m im C++ Programm speichere, habe ich statt 611, 25344 in der Variable DB->cs->iImagePointCount stehen.

Warum, ist mir ein wenig schleierhaft. Was aber noch interessant ist: Das Ganze bleibt konstant. Beispiel: Wenn ich im C Programm m = 1 setze, bekommt die Variable im C++ Programm den Wert 256. Für m = 2 => 512. Das setzt sich so fort - aber ab einem gewissen Punkt stimmt das dann nicht mehr. 611 gibt, wie oben schon gezeigt, 25344 - und nicht 156416 (allerdings wäre das selbst dann noch ein Schmarn - es sollte 611 sein).

Weiss da jemand, was das sein könnte?