AtNotes Übersicht Willkommen Gast. Bitte einloggen oder registrieren.
20.09.21 - 02:00:01
Übersicht Hilfe Regeln Glossar Suche Einloggen Registrieren
News:
Schnellsuche:
+  Das Notes Forum
|-+  Domino 9 und frühere Versionen
| |-+  Entwicklung (Moderatoren: Axel, eknori, Hoshee, ata, Thomas Schulte, koehlerbv)
| | |-+  Rechengenauigkeit INTEL ???
« vorheriges nächstes »
Seiten: [1] Nach unten Drucken
Autor Thema: Rechengenauigkeit INTEL ???  (Gelesen 5154 mal)
AC
Senior Mitglied
****
Offline Offline

Geschlecht: Männlich
Beiträge: 365


« am: 05.07.04 - 13:45:40 »

Mal wieder

Blöde Sache, wie erklärt mans seinen Chef, wenn er überhaupt keinen Bock hat sich die Erklärung (die er eh nicht versteht und verstehen will) anzuhören.

Ganz einfache Anwendung unter Notes 5.
Maske, mehrere Zahlenfelder, ich addier dabei zwei Felder auf:
184,8 + (-184,5).
(minus weils ne Gutschrift ist).
Herauskommen müsste 2,3
Herauskommt aber leider 2,300000000000001
Im Dokument wars zwar nicht zu sehen aber in der Ansicht (weil ich nicht die Spalteneigenschaften auf 2 Dezimal beschränkt hatte) fiel es natürlich granatenmäßig auf.
 
BTW Excel 97 rechnet genauso.

In dieser speziellen Anwendung isses nicht soo dramatisch, aber es gibt ja auch noch andere Anwendungen bei denen man die Nachkommastellenproblematik durchaus hat.

Hallo Entwickler:
Fangt Ihr sowas programmiertechnisch durch geeignete Routinen ab ? Oder lasst Ihr wenns ums Thema genaueres Rechnen unter Notes geht, die Finger weg ?
(Wobei es ja genügend Busienesspartner software gibt mit aufwendigen Rechnungen , z.B. Projektmanagementsoftware unter Notes).

Liegts an INTEL überhaupt, rechnet AMD hier anders ?


TIA, Holcomb
PS Auch ohne das Minusvorzeichen kommt bei einer Subtralktion die lange Dezimalzahl raus.
Gespeichert

Microsoft Certified Technology Specialist Microsoft Dynamics NAV 5.0 C/Side Introduction
Microsoft Certified Technology Specialist Microsoft Dynamics NAV 5.0 C/Side Solution Development

"...Glücklich ist, wer vergisst, was doch nicht zu ändern ist..."
Marinero Atlántico
Gast
« Antworten #1 am: 05.07.04 - 19:11:18 »

Zur Not kannst du das mit einer relativ aufwendigen Spaltenformel abfangen.
So in der Art.
Code:
valTemp := @right(@Text(val);",");
etc..
@TextToNumber(
Da existiert aber sicherlich noch eine bessere Lösung.

Ansonsten kann ich deinen Chef verstehen.
Das muss man irgendwie hinbekommen.
Als Anwender würde ich Erklärungen bezüglich der Einschränkungen des Registerspeichers auch nicht akzeptieren. Interessieren tät mich das auch nicht.
 
« Letzte Änderung: 05.07.04 - 19:13:58 von Marinero Atlántico » Gespeichert
eknori
@Notes Preisträger
Moderator
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 11560


« Antworten #2 am: 05.07.04 - 19:17:32 »

da gab es doch mal ( lang, lang ist es her ) diesen Rechenfehler im Pentium ... http://www.krisennavigator.de/mafa3-d.htm Sollte der etwa immer noch da sein  Huh
Gespeichert
Marinero Atlántico
Gast
« Antworten #3 am: 05.07.04 - 19:26:14 »

compadres,

es sollte doch möglich sein, unserer furchtlosen Groupwareplattform durch ein paar sause-schnelle @commands klarzumachen, dass sie die Zahl auf 2 Nachkommastellen abrundet Huh
Ohne das damit zu erklären, dass eine Chaostruppe wie Intel natürlich nicht in der Lage ist, die von uns gewöhnten Qualitätsstandards von Iris einzuhalten  Grin
Gespeichert
eknori
@Notes Preisträger
Moderator
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 11560


« Antworten #4 am: 05.07.04 - 19:31:47 »

der Fehler tritt auch bei meinem AMD auf:

Gespeichert
Marinero Atlántico
Gast
« Antworten #5 am: 05.07.04 - 19:53:40 »

Java:
Code:
double zahl1 = 184.8;
double zahl2 = 184.5;
double result = zahl1 - zahl2;
return result;
ergibt:

Das hat etwas mit allgemeinen Ungenauigkeiten von double auf 32-bit Rechnern zu tun.

Kann das aber mit
http://java.sun.com/j2se/1.4.2/docs/api/java/text/NumberFormat.html
lösen.
Bei wirklich großen oder kleinen Zahlen gibt es immer noch:
http://java.sun.com/j2se/1.4.2/docs/api/java/math/BigDecimal.html

« Letzte Änderung: 05.07.04 - 19:55:04 von Marinero Atlántico » Gespeichert
eknori
@Notes Preisträger
Moderator
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 11560


« Antworten #6 am: 05.07.04 - 19:54:55 »

ähhh ist es mit der Rechengenauigkeit von Holocomb auch nicht so weit her ??

184,8 + (-184,5).
(minus weils ne Gutschrift ist).
Herauskommen müsste 2,3

@Holocomb: gaaaanz sicher ??

Ich habe mal Adam Riese und Schürmanns Rechenbuch befragt; da kommt aber 0,3 raus ...

Möglicherwesie sehen das gewisse Herrschaften im Takonomi (Yakatomi oder wie auch immer ) Tower wieder als Beleidigung an; ist aber nicht so gemeint ;-)
Gespeichert
Marinero Atlántico
Gast
« Antworten #7 am: 05.07.04 - 19:57:46 »

Float wird noch ungenauer:
Code:
float zahl1 = 184.8f;
float zahl2 = 184.5f;
float result = zahl1 - zahl2;
return result;

« Letzte Änderung: 05.07.04 - 19:58:32 von Marinero Atlántico » Gespeichert
Semeaphoros
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 8152


ho semeaphoros - agr.: der Notesträger


WWW
« Antworten #8 am: 05.07.04 - 20:00:27 »

Leute, solange man binär rechnet und nicht mit BCD, sind die Rundungsfehler inhärent und haben nix mit Fehlern im Pentium oder was auch immer zu tun. Das hängt ganz einfach damit zusammen, dass sich die endlich darstellbaren Zahlen des Dezimalsystems nicht unbedingt mit endlichen Zahlen des Binärsystemes darstellen lassen, es gibt also keine 1 zu 1 Relation zwischen Dezimal und Binär, und damit kommt es zwangsläufig zu Rundungsfehlern, ob man will oder nicht. Das mit dem Abfangen hat auch seine Nase, jedes Runden vergrössert den sowieso schon vorhandenen Fehler und wir bekommen Probleme mit einem Ding, das sich Fehlerfortpflanzung nennt.

Da hatte ich mal einen Informatiker als Angestellten, der das Problem selber unterschätzt hat  Er hat es zwar aus der Ausbildung heraus gekannt, aber nie wirklch erlebt. Da musste man einen Wassertropfen am linken Rand des Bildschirmes herunterlaufen lassen. Um den nächsten Schritt zu berechnen, dividiere man die Höhe des Bildschirms durch die Anzahl Schritte, die man machen will, tönt ganz einfach. Der Mann hat dann bei jedem Rechenschritt schön brav gerundet. In der VGA-Auflösung, die damals noch üblich war, kam der Tropfen auch wie gewünscht unten am Bildschirm an. Wenn wir dann für die Produktion auf 800 x 600 umschalteten, da passierte etwas merkwürdiges: der Tropfen blieb nach 2/3 der Strecke einfach stehen. Ich hab gleich gefragt, hast Du zu früh gerundet? Er wollte mir das nicht glauben, dass das einen derart grossen Effekt haben könnte, so dass ich ihm nahelegte, ändere mal den Code, mach die Rundung erst ganz am Schluss ..... und siehe da, der Tropfen landete wie gewünscht bei beiden Auflösungen korrekt unten am Bildschirm.
Gespeichert

Jens-B. Augustiny

Beratung und Unterstützung für Notes und Domino Infrastruktur und Anwendungen

Homepage: http://www.ligonet.ch

IBM Certified Advanced Application Developer - Lotus Notes and Domino 7 und 6
IBM Certified Advanced System Administrator - Lotus Notes and Domino 7 und 6
AC
Senior Mitglied
****
Offline Offline

Geschlecht: Männlich
Beiträge: 365


« Antworten #9 am: 06.07.04 - 08:45:58 »

Hallo Leute, erstmal allen danke für das feedback.

mehr später, weil ich erstmal was schnell für Chef machen muß.

@eknori
Die zweite Zahl war 182,50 und nicht 184,5.- Sorry mein Fehler.
Korrekt lautet es also 184,80 + (- 182,50).
Und dann kriegt man eben die Nachkommastelle.
Merci auch für das AMD Beispiel, hat mich auch interessiert.

Bis später, Holcomb,
Gespeichert

Microsoft Certified Technology Specialist Microsoft Dynamics NAV 5.0 C/Side Introduction
Microsoft Certified Technology Specialist Microsoft Dynamics NAV 5.0 C/Side Solution Development

"...Glücklich ist, wer vergisst, was doch nicht zu ändern ist..."
AC
Senior Mitglied
****
Offline Offline

Geschlecht: Männlich
Beiträge: 365


« Antworten #10 am: 06.07.04 - 09:32:28 »

@ Marinero,:

Wegen Cheffe, bleibt nur eins.
"schummeln". Sicherstellen, daß in Dokument und auch view nur begrenzte Anzahl der Nachkommastellen. Und dann hoffem, daß Chef nicht auf die Idee kommt, in dei Feleigenschaften zu gucken.   <g>

Punkt 2: AS/400 rechnet auch nicht anders. Da kam das gleich heraus, auch hinten die " ...01".

@semeea:
das mit dem einmaligen Runden erst am Ende aller Rechenoperationen war mir an sich klar.
Aber danke für Deine Erlärung.

Bis später, Holcomb
Gespeichert

Microsoft Certified Technology Specialist Microsoft Dynamics NAV 5.0 C/Side Introduction
Microsoft Certified Technology Specialist Microsoft Dynamics NAV 5.0 C/Side Solution Development

"...Glücklich ist, wer vergisst, was doch nicht zu ändern ist..."
AC
Senior Mitglied
****
Offline Offline

Geschlecht: Männlich
Beiträge: 365


« Antworten #11 am: 06.07.04 - 10:01:31 »

Konsequenz:
Ich darf dem nach nie blauäugug abprüfen ob ein Wert, der aus einer aritmetischen Operation stammt,  = 0 ist, auch wenn er es nach Adam Riese aus Staffelstein eigentlich sein müsste.

Da ja leider
(184,8 - 182,5) - 2,3  <> 0  

:-/.

Holcomb

Gespeichert

Microsoft Certified Technology Specialist Microsoft Dynamics NAV 5.0 C/Side Introduction
Microsoft Certified Technology Specialist Microsoft Dynamics NAV 5.0 C/Side Solution Development

"...Glücklich ist, wer vergisst, was doch nicht zu ändern ist..."
Marinero Atlántico
Gast
« Antworten #12 am: 06.07.04 - 10:09:01 »

Also Holcomb das ist wirklich kein Schummeln, wenn du die Zahlen entsprechend für das Display formatierst.
Die Feldeigenschaftenbox ist nicht für die Anwender gedacht, sondern für Admins und Entwickler.
Zählst, ist auf dem Platz (Fussball) oder
Zählt ist der View und im Dokument (Notes).  
Jens hat ja die Problematik der Repräsentation von Bruchzahlen (oh je das heisst anders, aber ich bin ohne Bücher) aufgezeigt.
Wenn ich mich recht erinnere haben z.B. RDBMS z.B. den Datentyp Decimal, um diese Float/Double Probleme zu umgehen. Da wird aber glaub ich auch intern gerundet.
Selbst BigDecimal in Java hat sicher irgendwelche Grenzen, wo es nicht mehr genau ist.
Gespeichert
Semeaphoros
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 8152


ho semeaphoros - agr.: der Notesträger


WWW
« Antworten #13 am: 06.07.04 - 11:44:21 »

Völlig richtig, dass eine Prüfung auf = extrem gefährlich ist, egal ob da auf der einen Seite eine Null ist oder ein anderer Wert, da müsste man ein Epsilon definieren, sprich einen Bereich, innerhalb dem man annimmt, dass die Werte tatsächlich gleich sind.
Gespeichert

Jens-B. Augustiny

Beratung und Unterstützung für Notes und Domino Infrastruktur und Anwendungen

Homepage: http://www.ligonet.ch

IBM Certified Advanced Application Developer - Lotus Notes and Domino 7 und 6
IBM Certified Advanced System Administrator - Lotus Notes and Domino 7 und 6
AC
Senior Mitglied
****
Offline Offline

Geschlecht: Männlich
Beiträge: 365


« Antworten #14 am: 06.07.04 - 18:27:59 »

Völlig richtig, dass eine Prüfung auf = extrem gefährlich ist, egal ob da auf der einen Seite eine Null ist oder ein anderer Wert, da müsste man ein Epsilon definieren, sprich einen Bereich, innerhalb dem man annimmt, dass die Werte tatsächlich gleich sind.

Jou.  Wird einem hier mal wieder vor Augen geführt.
Bleibt als Lösung am Ende einer Berechnung das Endergebnis zu  runden (und nicht auch die Teilergebnisse wie Du oben auch berschrieben hast) und zwar auf die Genauigkeit mit der man arbeiten will.

Ich setz den Thread mal auf erledigt.

Thx an alle Schreiber hier im Thread.

Bye, Holcomb



Gespeichert

Microsoft Certified Technology Specialist Microsoft Dynamics NAV 5.0 C/Side Introduction
Microsoft Certified Technology Specialist Microsoft Dynamics NAV 5.0 C/Side Solution Development

"...Glücklich ist, wer vergisst, was doch nicht zu ändern ist..."
Semeaphoros
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 8152


ho semeaphoros - agr.: der Notesträger


WWW
« Antworten #15 am: 06.07.04 - 18:37:32 »

Genau, so ist es.
Gespeichert

Jens-B. Augustiny

Beratung und Unterstützung für Notes und Domino Infrastruktur und Anwendungen

Homepage: http://www.ligonet.ch

IBM Certified Advanced Application Developer - Lotus Notes and Domino 7 und 6
IBM Certified Advanced System Administrator - Lotus Notes and Domino 7 und 6
Marinero Atlántico
Gast
« Antworten #16 am: 06.07.04 - 19:21:47 »

auch Net schafft es nicht (habs auch nicht anders erwartet, will nur ein bischen mit meinen extrem tiefsinnigen Kenntnissen in MS.NET Konsolenanwendungen angeben.  Grin
Obwohl Microsoft da hunderte von Milliarden von Dollar investiert hat.
Code:
double zahl1 = 184.8;
double zahl2 = -184.5;

System.Console.WriteLine(zahl1 + zahl2);

« Letzte Änderung: 06.07.04 - 19:23:53 von Marinero Atlántico » Gespeichert
Seiten: [1] Nach oben Drucken 
« vorheriges nächstes »
Gehe zu:  


Einloggen mit Benutzername, Passwort und Sitzungslänge

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006, Simple Machines Prüfe XHTML 1.0 Prüfe CSS
Impressum Atnotes.de - Powered by Syslords Solutions - Datenschutz | Partner: