Hi Micha, vielen Dank für das Patch! Die Änderung im fromString() finde ich super und checke sie gleich ein, da das auf jedem Fall eine Verbesserung ist (Nenner also separat parsen und dann direkt in den mpq_t schreiben). Dein Testprogramm hab ich gleich als unittest mit dazugestellt.
Mit dem "deprecated" bin ich nicht so überzeugt, denn die entsprechenden Funktionen (zumindest toDouble) wird tatsächlich alle Nase lang benutzt. Im Prinzip wäre ich auch dafür, die zu deprecaten und dann rauszuwerfen, aber das muss Martin dann schon selber entscheiden. Vielen Dank für diesen Patch. Gruß Christian Am Dienstag, 14. Juli 2009 11:43 schrieb Micha Lenk: > Hallo Martin, > > On Tue, Jul 14, 2009 at 08:19:30AM +0200, to...@tuxteam.de wrote: > > Ich muss Micha recht geben. Ich erwarte hier keine wilden Operationen, > > die solch eine Zahl rechtfertigen würden (im Wesentlichen geteilt durch > > Hundert bei der Dezimal -> Intern Wandlung, und das müsste eine > > Bruchlibrary wie libgmp verlustfrei können: 36154/100, ggf. gekürzt). Es > > sieht also aus, als wäre die arme Zahl durch eine float-Mangel gezogen > > worden. > > Korrekt, und zwar von AqBanking selbst in der Funktion > AB_Value_fromString(), die den übergebenen String bisher zunächst in > eine Gleitkommazahl (der Typ mpf_t aus der Bibliothek GMP ist eine > Gleitkommazahl mit beliebiger Präzision!) umwandelt, um erst dann eine > rationale Zahl daraus zu machen. > > Ich habe gerade einen Patch geschrieben, der eine Zahl, die > so normalerweise in Strings übergeben wird, korrekt in ein mpq_t > (rationale Zahl aus libGMP) umwandelt (im Anhang die Datei > proper_rational_number_AB_Value.patch). Dazu habe ich ein kleines > Testprogramm geschrieben, dass mit dem folgenden Befehl in eine > ausführbare Datei übersetzt werden kann: > gcc $(pkg-config --cflags --libs aqbanking) -o ab_value_test > ab_value_test.c Anhand dieses Beispiel-Programms kann man gut > nachvollziehen, wie mit dem ungepatchten AqBanking aus der Zahl 361,54 > intern die unsägliche Zahl > 28644149875407128613569879804477/79228162514264337593543950336 wird. Mit > dem Patch wird die Zahl hingegen als einfache rationale Zahl 36154/100 > gespeichert. > > Zusätzlich behebt der Patch einen kleinen, sehr selten auftretendes > Speicherleck: free(tmpString) wurde unter bestimmten Umständen nicht > aufgerufen. > > Zu guter letzt habe ich die ganzen API-Funktionen, die irgendwie mit > Gleitkommazahlen agieren als veraltet (deprecated) markiert, damit man > beim Übersetzen mal sieht, wo überall dieser Mist verwendet wird und > damit man evtl. irgendwann mal gänzlich auf die Gleitkommazahlen > verzichten kann. Auch die Funktionen für Multiplikation und Division von > AB_VALUEs habe ich als veraltet markiert, da sie zum einen nicht > wirklich sinnvoll sind (Was ist denn 10€ * 10€? Korrekt wäre 100€²...) > und zum anderen nach meinen Recherchen nicht benutzt werden. > > Ich würde mich freuen, wenn der Patch ins SVN kommt. > > Schöne Grüße > Micha ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Aqbanking-devel mailing list Aqbanking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
