Das Notes Forum
Domino 9 und frühere Versionen => ND6: Entwicklung => Thema gestartet von: Jenson am 14.09.04 - 15:35:20
-
Hallo zusammen,
ich verzweifle gerade an einer simplen Berechnung in Lotus Notes mit der @Formel. Ich habe zwei Variablen in denen beiden jeweils eine Zahl mit 2 Nachkommastellen gehalten wird. Diese beiden ziehe ich von einander ab und bekomme dann eine Zahl mit ziemlich vielen Nachkommastellen zurück.
Beispiel:
_HoursIst hat als Wert 8,45
_HoursSoll hat als Wert 8
Diese Formel:
_Debit := (_HoursIst - _HoursSoll)
ergibt dann den Wert 0.449999999999999
Ich habe mittels @TextToNumber aus Textfeldern die beiden Variablen _HoursIst und _HoursSoll gefüllt und das Ergebnis der Formel auch wieder mit @Text in ein Textfeld geschrieben.
Gibt's da irgendeine Erklärung dazu? Und ich dachte ich kann mittlerweile mit der Formelsprache umgehen :-) ???
Jenson
-
schau mal hier rein http://www.atnotes.de/index.php?board=7;action=display;threadid=14989;start=0 (http://www.atnotes.de/index.php?board=7;action=display;threadid=14989;start=0) da ist so eine ähnliche Thematik beschrieben
-
Hallo eknori,
Das ist jetzt ein echtes Problem. Ich habe auch einfach mal versucht den Wert einfach per @Round( <ERGEBNIS>; 0,01) zu runden. Das wiederrum führt zum totalen Abbruch des Scriptes.
Wie bringe ich das nun unserem Chef bei.... Es geht dabei um eine Simple Berechnung von Überstunden ... Ts...
Jenson
-
hmm, was passiert denn, wenn man das Ganze in Minuten umrechnet, die Subtraktion durchführt und dann das ergebnis wieder in stunden ?
-
Nehme an, Du meinst Abbruch der Formel. Was heisst hier übrigens total? Fehlermeldung? Kein Resultat? Warum stellst Du nicht die Anzeigeoptionen auf 2 Stellen nach dem Komma?
-
Das wäre eine Idee... das Probiere ich mal schnell aus. Werde berichten ...
Jenson
-
@Semaphorus:
Das ist eine Datenbank in der ich in einer Maske die Möglichkeit habe eine @Formel einzugeben. Diese wird dann beim Aufrufen eines Dokumentes über das Web vorher ausgeführt und schreibt berechnete Werte in ein Template. Alles was zum Schluss ausgegeben wird ist reiner Text.
Totaler Abbruch heisst, dass ich bei der Ausgabe des Dokumentes über das Web alle Felder die ich bis zu dieser Stelle in der Formel ausgebe angezeigt werden. Alle die nach dieser Stelle in der Formel berechnet werden, fehlen in der Webausgabe.
Jenson
-
Ich habe auch einfach mal versucht den Wert einfach per @Round( <ERGEBNIS>; 0,01) zu runden. Das wiederrum führt zum totalen Abbruch des Scriptes.
Bei mir ergibt @Round (8,45-8; 0,01) als Ergebnis 0,45
System stürzt NICHT ab!
Gruß Armin
-
Na, das mit totalem Abbruch zu bezeichnen, ist ein bisschen unsinnig - sorry. Da stimmt wohl mit der Syntax etwas nicht. Poste doch mal die gesamte Formel
-
Die Formel hat derzeit 12 DIN-A4 Seiten Umfang ... Ich kann aber mal den Ausschnitt posten um den es eigentlich geht:
_HTMLHoursComplete hat hier laut Ausgabe: 8,5
_WorkingHours hat hier laut Ausgabe: 8
-----SCHNIPP------
_HoursIst := @TextToNumber(_HTMLHoursComplete);
_HoursSoll := @TextToNumber(_WorkingHours);
_Debit := (_HoursIst - _HoursSoll);
@if((@isError(_HoursInteger) | (@isError(_Debit))); "";
@Do(
@if(_Debit < 0; _HTMLHoursUnder := @Text(_Debit); "");
@if(_Debit > 0; _HTMLHoursOver :=@Text(_Debit); "")
)
);
------ SCHNAPP -------
Als Ergebnis bekomme ich dann diese 0.4999999999 ....
Jenson
-
Hallo Jenson,
mit dieser Formel erhalte ich 0,45 als Ergebnis:
_HoursIst := @TextToNumber("8,45");
_HoursSoll := @TextToNumber("8");
_Debit := (_HoursIst - _HoursSoll);
@Round(_Debit; 0,01)
Wo ist dann das Problem?
Armin
-
Sehr merkwürdig - bei mir ist das Ergebnis von Armins Formel auch ohne @Round 0,45 ... Wenn da zwischendurch noch eine Division laufen würde (wie in dem von Ulrich angesprochenen Thread), würde ich es ja einsehen, aber bei einer Subtraktion ...
Bernhard
-
Hallo Bernhard,
wo läßt du die Formel rechnen? in einem Feld? ist dieses Feld auf 2 Nachkommastellen formatiert?
Ich lasse obige Formel im Betreff einer Mail rechnen (mit Shift + F9) und erhalte OHNE @Round 0,4499999... und MIT @Round 0,45
Armin
-
Nö, das war ein Buhtong samt Prompt.
A-Bär: R5 !
Selbiges - wie erforderlich - in R6: Gleiches Ergebnis wie bei Dir, Armin.
Das ist damit ein ganz eindeutiger Bug in R6 !
Bernhard
-
Ich kann das wie gesagt auch nicht in einem Feld rechnen, sondern einfach in einer Variablen innerhalb meiner Formel. Die Daten für die Berechnung bekomme ich als text aus einem DBLookup.
Jenson
-
Bernhard: Die Rundungsdifferenz in diesem Fall hat nix zu tun mit der Operation, aus der das Ergebnis herauskommt, sondern mit der Umrechnung von Binär zu Dezimal und umgekehrt, deshalb kann es auch bei einer Subtraktion zu gerundeten Ergebnissen kommen. Da in R6 die gesamte @Formel-Engine neu geschrieben wurde, ist es durchaus klar, dass die Rundungsfehler nun halt an anderen Orten zuschlagen als dies noch zu R5-Zeiten der Fall war, also kein Bug in R6, sondern genau das Problem, auf das Ulrich hingewiesen hat: Rundungsungenauigkeiten. Man vergesse nicht, dass Umrechnung von einem Zahlensystem ins andere mit Multiplikation (und damit mit Rundungsproblemen und Fehlerfortpflanzung) zu tun hat.
-
@TextToNumber ("8,45") - @TextToNumber ("8") = 0,449999999
Wenn das kein Bug ist, dann weiss ich nicht, was ein Bug sein soll !!!
Notes betreibt hier "Schätzen Sie mal !"
"Wieviel ist 18 plus 5"? "Ungefähr 22".
Auf genau das läuft das hinaus. Das es bei Zwischenergebnissen zu Problemen kann - okay, das sehe ich noch ein. Aber
"8" als Zahl ist bei Notes 7,9999999
dafür habe ich NULL Verständnis.
Bernhard
-
Sorry. Bernhard, aber wenn Du nicht mit BCD-Format rechnest, kann Dir tasächlich mit Print 8 eine 7,999999999 (ok, das Beispiel ist unpassend .... )oder sowas rauskommen, woher willst Du wissen, wie präzise die binäre Darstellung Deiner 8 ist? Diese Probleme kann man nur beheben, wenn man BCD als Datentyp verwendet, und der steht in Notes leider nicht zur Verfügung. Allein die Konvertierung der Datenbasis ist bereits fehlerbehaftet. Wenn Du 1/3 in Dezimal darstellst, gibts eine unendliche Zahl, wenn Du 1/3 im Trinärsystem darstellst, ist das 0,1 also ohne irgend eine Periode darstellbar. Zwischen Dezimal und Binär gibt es ganz ähnliche Erscheinungen
-
Der Background ist mir schon klar, Jens. Aber das ändert nichts, überhaupt nichts daran, dass Notes hier absoluten Mist baut - und das erst ab R6.
Bernhard
-
Ich kann das wie gesagt auch nicht in einem Feld rechnen, sondern einfach in einer Variablen innerhalb meiner Formel. Die Daten für die Berechnung bekomme ich als text aus einem DBLookup.
Jenson
Hallo Jenson,
Bug hin oder her... ("mein Bug dein Bug........")
Nehmen wir diese Rundungsproblematik einfach als gegeben, was spricht denn nun gegen ein @Round um dein Ergebnis???
Armin
-
Hallo Jenson,
Bug hin oder her... ("mein Bug dein Bug........")
Nehmen wir diese Rundungsproblematik einfach als gegeben, was spricht denn nun gegen ein @Round um dein Ergebnis???
Armin
"Mein Bug Dein Bug" ist doch nicht das Thema, Armin. Jenson kann sich jetzt sicherlich behelfen, indem er @Round verwendet.
Vor mir steht ab koMo die Aufgabe, eine hochkomplexe (Fremd-)Applikation im Kundenauftrag auf R6-Kompatibilität zu testen und dann entweder für R6 freizugeben oder erforderliche Änderungen durchzuführen. Das ist sowieso schon eine spannende Aufgabe, aber tut dieser Bug nun auch noch not ? Ich muss davon ausgehen, dass die hier besprochene Situation auch in dieser Applikation auftritt. Sicher habe ich Werkzeuge, danach zu suchen, trotzdem wird das ein ziemlicher Stunt. Und wie soll ich dem Kunden erklären: "Sorry, ich habe drei Tage länger gebraucht, aber Lotus hat in R6 da richtige Sch**sse gebaut, was das Rechnen in @functions angeht ...."
Mein Fazit: Das ist ein ganz, ganz übler Bug.
Bernhard
-
"Mein Bug Dein Bug" ist doch nicht das Thema, Armin. Jenson kann sich jetzt sicherlich behelfen, indem er @Round verwendet.
Bernhard, du hast mich wohl falsch verstanden, hiermit habe ich scherzhaft auf eine Werbung vor ein paar Jahren angespielt.... ;D
Armin
-
Ich kann das wie gesagt auch nicht in einem Feld rechnen, sondern einfach in einer Variablen innerhalb meiner Formel. Die Daten für die Berechnung bekomme ich als text aus einem DBLookup.
Jenson
Hallo Jenson,
Bug hin oder her... ("mein Bug dein Bug........")
Nehmen wir diese Rundungsproblematik einfach als gegeben, was spricht denn nun gegen ein @Round um dein Ergebnis???
Armin
:-) Netter Spruch :-) Also grundsätzlich spricht da nichts dagegen, da die Werte an dieser Stelle nur für die Anzeige berechnet werden müssen, aber dennoch bereiten mir solche "Unstimmigkeiten" immer so ein komisches Gefühl in der Magengegend. Zudem hatte ich den Effekt, dass wenn ich in meiner Formel mehr als 3 solcher unrunden Werte hatte die Formel bei @Round abgebrochen hat.
Ich werde es mal versuchen. Wenn ich das ganze erst in Minuten umrechen und dann danach wieder in Stunden, dann kann mir das gleiche auch wieder passieren denke ich, oder?
Mal sehen. Werde das morgen früh nochmal angreifen.
Jenson
PS: Seid doch alle wieder lieb zueinander ;D
-
Äh - wir haben uns doch alle ganz doll lieb ... Wo hast Du denn hier eine Kontroverse gesehen, die über den normalen Meinungsaustausch hinaus geht ?
Bernhard ;)
-
War wohl auch so ein "Bauchgefühl" :-) Mag auch der Hunger gewesen sein.
Jenson
-
hihi....altgestandene C-Programmierer werden bei diesem Beitrag leicht nostalgische Gefühle bekommen und ihn mit einem mildem Lächeln quittieren.
Den zu C-Zeiten wusste jeder um implizite Typkonvertierungen und deren Probleme..
wenn du statt :
var := @texttonumber("8");
folgendes:
var := @texttonumber("8,0");
geschrieben hättest...wäre die Welt in Ordnung gewesen.
Merke: der @-Interpreter wurde (bis zur Version 5) in C geschrieben..und hat damit auch alle entsprechenden Eigenarten. Sogar einige Eigenarten von Lex&Yacc lassen sich bis dahin feststellen :-).
Worin der 6er Interpreter geschrieben ist weis ich zwar nicht...aber ich nehme keine sonderlich neue Technologie an.
-
Das ist nicht korrekt so: Gerade in R5 hat es noch funktioniert, und in R6 ändert auch die Dezimalangabe nichts am falschen Ergebnis.
So sind zumindest meine Testergebnisse.
Bernhard
-
nur mal so am Rande; hat das mal jemand als ticket bei IBM/Lotus gemeldet ??