You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users-de@openoffice.apache.org by Horst Schulze <jr...@tandandale.de> on 2013/01/21 22:31:38 UTC
=2884,6+3260-6106,25=38,35
Hallo,
ich hatte ein Problem in einer Tabelle und bin letztendlich auf folgende Formel gestoßen:
=2884,6+3260-6106,25=38,35
Das ist FALSCH.
Warum? Passiert das nur bei mir oder auch woanders?
=2884,6+3260-6106,25-38,35 ergibt
3,62E-13
Für einen kurzen Test und Rückmeldung wäre ich dankbar.
Horst Schulze
----
Horst Schulze
Die christliche Alternative für NRW!
AUF-Partei für Arbeit, Umwelt und Familie
Christen für Deutschland
Landesverband Nordrhein-Westfalen
02323-388847
0171 3421726
Josefinenstr. 106a
44628 Herne
http://www.auf-partei.de/nrw
Sollten Sie diese Mail irrtümlich erhalten oder sind Sie nicht mehr an weiteren Informationen interessiert, so lassen
Sie uns das bitte durch eine kurze Rückantwort wissen.
Sollten Sie diese Mail durch Weiterleitung durch Freunde erhalten haben und weitere Informationen wünschen, so
senden Sie uns ebenfalls eine kurze Mail.
Re: =2884,6+3260-6106,25=38,35
Posted by Salvalaggio Marino <m....@gmx.ch>.
Wolfgang Jäth schrieb:
> Am 28.01.2013 08:07, schrieb Salvalaggio Marino:
>>
>>> IMHO nein; das Vorzeichen müsste schon rausgerechnet sein (jedenfalls
>>> ergeben 23 Bit für die Mantisse + 8 Bit für den Exponenten nur 31 Bit;
>>> auf die vollen 32 Bit fehlt also noch eines).
>>>
>>
>> Wie soll denn ein Vorzeichen wie Du sagst rausgerechnet werden?
>
> http://de.wikipedia.org/w/index.php?title=Datei:IEEE-754-single.svg&filetimestamp=20110525181832
>
> (aus
> http://de.wikipedia.org/wiki/IEEE_754#Zahlenformate_und_andere_Festlegungen_des_IEEE-754-Standards
> ).
>
Was soll ich jetzt damit?
Da wird ja genau das ausgesagt, das ich Dir vermitteln will!
Typ Größe Exponent Mantisse Werte des Exponenten
single 32 bit 8 bit 23 bit - 126 ≤ e ≤ 127
double 64 bit 11 bit 52 bit -1022 ≤ e ≤ 1023
wie Du rechen kannst:
bei 32Bit 8+23 = 31bit
bei 64Bit 11+52 = 63bit
Wie Du sehen kannst, ist das Bit 31 bez. 63 immer mit dem Vorzeichen
belegt. Bei TRUE ist der Wert negativ, bei FALSE positiv.
Nur für die Formate HEX und unsigned ist das Bit 31 bez. 63 für den Wert
nutzbar. Die aber kennen keine Vorzeichen!
Die Formate Exp, Real und Float sind ohne Vorzeichen nicht verfügbar!
Damit der Prozessor mit grösseren Werten arbeiten kann, muss das
Übertrag-Flag abgefangen werden und in einen zweiten Variable portiert
werden.
Solches nutzt man bei 8Bit Rechnern, wenn man auf 16Bit erweitert bez.
bei 16Bit->32Bit oder 32Bit->64. Das muss aber vom Programm unterstützt
werden sonst geht das eben nicht!
Marino
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Bitte Streichen!!!
Posted by Michael Höhne <et...@scitec4.org>.
Am Tue, 29 Jan 2013 21:57:36 +0100
schrieb Michael Höhne <et...@scitec4.org>:
> Wenn es _nur_ an der Darstellung der Mantisse läge, dann dürfte es
> keinen Unterschied machen, ob ich z.B. 123-122 oder 12,3-12,2 vorgeben
> würde (Stichwort Normalisierung).
Ist Blödsinn! Hier wird ja im 2er-System normalisiert und nicht im
10er...
Sorry,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by Michael Höhne <et...@scitec4.org>.
Hallo Thomas, Marino,...
> Du hast mit Deinen Feststellungen Recht. Nur ging es hier nicht um
> die Darstellungsweisen von Zahlen, sondern um Rundungsfehler:
> ...
> Nach mehreren Kommentaren ergab sich das Problem:
> > Also (bei calc):
> > 6144,6-6106,25=38,350000000000400
> > 144,6- 106,25=38,350000000000000
>
> Da die Zahlen intern im einfachen Gleitkommasystem (Type single)
> verarbeitet werden, treten Rundungsfehler auf. Die Mantisse hat also
> eine Genauigkeit von 23 Bit (wie Wolfgang und Du festgestellt haben).
Noch was zum Knobeln:
Wenn es _nur_ an der Darstellung der Mantisse läge, dann dürfte es
keinen Unterschied machen, ob ich z.B. 123-122 oder 12,3-12,2 vorgeben
würde (Stichwort Normalisierung).
Aber ich mache mal folgende Rechnungen in Calc:
61446000,00000000000000000000
- 61062500,00000000000000000000
= 383500,00000000000000000000
6144600,00000000000000000000
- 6106250,00000000000000000000
= 38350,00000000000000000000
614460,00000000000000000000
- 610625,00000000000000000000
= 3835,00000000000000000000
61446,00000000000000000000
- 61062,50000000000000000000
= 383,50000000000000000000
6144,60000000000000000000
- 6106,25000000000000000000
= 38,35000000000040000000
614,46000000000000000000
- 610,62500000000000000000
= 3,83500000000004000000
61,44600000000000000000
- 61,06250000000000000000
= 0,38350000000000500000
6,14460000000000000000
- 6,10625000000000000000
= 0,03835000000000030000
0,61446000000000000000
- 0,61062500000000000000
= 0,00383500000000003000
0,06144600000000000000
- 0,06106250000000000000
= 0,00038350000000000200
0,00614460000000000000
- 0,00610625000000000000
= 0,00003835000000000040
Wenn in allen Fällen eine normalisierte Mantisse verwendet würde, dann
müsste (soweit ich mich an meine Kurse an der Uni erinnere) auch immer
die gleiche Ziffernfolge als Ergebnis heraus kommen. Ob mit
Rundungsfehler oder nicht...
Gruß,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by Regina Henschel <rb...@t-online.de>.
Hallo,
Thomas Kübler schrieb:
[..]
> Da die Zahlen intern im einfachen Gleitkommasystem (Type single)
> verarbeitet werden, treten Rundungsfehler auf. Die Mantisse hat also
> eine Genauigkeit von 23 Bit (wie Wolfgang und Du festgestellt haben).
Nein, wenn eine GLeitkommazahl benutzt wird, ist es in Calc _immer_ vom
Typ double.
>
> Bisher hat noch keiner geprüft, ob die Ziffernfolge 61446 der
> Dezimalzahl als Mantisse in 23 Bit im Binärsystem passen. (Oder liegt es
> an 610625?)
> Ich weiß nicht, wie ich das prüfen kann. Vielleicht hast Du eine Idee?
Es spielen zwei Phänomene eine Rolle, einmal die Umwandlung einer
Kommazahl ins Zweiersystem und zum anderen "Cancellation". Ich hatte vor
langer Zeit mal angefangen die Probleme zusammenzustellen, aber über ein
"Draft" bin ich leider noch nicht hinausgekommen.
http://wiki.openoffice.org/wiki/User:Regina/MyDrafts
Wenn ihr die Rechnungen "zu Fuß" nachvollziehen wollt, wird es mühsam.
Ihr müsst auf jeden Fall nach Addition und Subraktion das Normalisieren
durchführen.
Wer das alles ganz genau haben möchte, wird fündig bei "David Goldberg:
What Every Computer Scientist Should Know About Floating-Point Arithmetic"
http://perso.ens-lyon.fr/jean-michel.muller/goldberg.pdf
oder in einer etwas überarbeiteten Version von
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
Mit freundlichen Grüßen
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by tbgn <m....@gmx.ch>.
Thomas Kübler schrieb:
> Hallo Marino,
>
>>
>> Die Formate Exp, Real und Float sind ohne Vorzeichen nicht
>> verfügbar!
>>
>> Damit der Prozessor mit grösseren Werten arbeiten kann, muss das
>> Übertrag-Flag abgefangen werden und in einen zweiten Variable
>> portiert
>> werden.
>> Solches nutzt man bei 8Bit Rechnern, wenn man auf 16Bit erweitert
>> bez.
>> bei 16Bit->32Bit oder 32Bit->64. Das muss aber vom Programm
>> unterstützt
>> werden sonst geht das eben nicht!
>>
>> Marino
>
>
> Du hast mit Deinen Feststellungen Recht. Nur ging es hier nicht um
> die Darstellungsweisen von Zahlen, sondern um Rundungsfehler:
>
> Ausgangspunkt war die Rechnung von Horst (21.1.2013):
>> =2884,6+3260-6106,25-38,35 ergibt
>> 3,62E-13
> Obwohl es eigentlich Null sein sollte.
>
>
> Nach mehreren Kommentaren ergab sich das Problem:
>> Also (bei calc):
>> 6144,6-6106,25=38,350000000000400
>> 144,6- 106,25=38,350000000000000
>
> Da die Zahlen intern im einfachen Gleitkommasystem (Type single)
> verarbeitet werden, treten Rundungsfehler auf. Die Mantisse hat
> also eine Genauigkeit von 23 Bit (wie Wolfgang und Du festgestellt
> haben).
>
> Bisher hat noch keiner geprüft, ob die Ziffernfolge 61446 der
> Dezimalzahl als Mantisse in 23 Bit im Binärsystem passen. (Oder
> liegt es an 610625?)
> Ich weiß nicht, wie ich das prüfen kann. Vielleicht hast Du eine
> Idee?
>
Hab mal
eine kleine Tabelle in Calc erstellt, welche zeigt, wo der
Überlauf stattfindet. Wie in Calc die Rundung im Einzelnen
behandelt, weiss ich jedoch nicht, scheint mir aber nach Standard
abzulaufen <5 =0 >=5 =1.
Bit Maximal-Wert 0..x Zustände (0/1) Exp.Notation
0 1 2 2.00E+00
1 3 4 4.00E+00
2 7 8 8.00E+00
3 15 16 1.60E+01
4 31 32 3.20E+01
5 63 64 6.40E+01
6 127 128 1.28E+02
7 255 256 2.56E+02
8 511 512 5.12E+02
9 1'023 1'024 1.02E+03
10 2'047 2'048 2.05E+03 hier wird „E“ das erste mal gerundet!
11 4'095 4'096 4.10E+03
12 8'191 8'192 8.19E+03
13 16'383 16'384 1.64E+04
14 32'767 32'768 3.28E+04
15 65'535 65'536 6.55E+04
16 131'071 131'072 1.31E+05
17 262'143 262'144 2.62E+05
18 524'287 524'288 5.24E+05
19 1'048'575 1'048'576 1.05E+06
20 2'097'151 2'097'152 2.10E+06
21 4'194'303 4'194'304 4.19E+06
22 8'388'607 8'388'608 8.39E+06
23 16'777'215 16'777'216 1.68E+07
24 33'554'431 33'554'432 3.36E+07
25 67'108'863 67'108'864 6.71E+07
26 134'217'727 134'217'728 1.34E+08
27 268'435'455 268'435'456 2.68E+08
28 536'870'911 536'870'912 5.37E+08
29 1'073'741'823 1'073'741'824 1.07E+09
30 2'147'483'647 2'147'483'648 2.15E+09
31 4'294'967'295 4'294'967'296 4.29E+09
32 8'589'934'591 8'589'934'592 8.59E+09
33 17'179'869'183 17'179'869'184 1.72E+10
34 34'359'738'367 34'359'738'368 3.44E+10
35 68'719'476'735 68'719'476'736 6.87E+10
36 137'438'953'471 137'438'953'472 1.37E+11
37 274'877'906'943 274'877'906'944 2.75E+11
38 549'755'813'887 549'755'813'888 5.50E+11
39 1'099'511'627'775 1'099'511'627'776 1.10E+12
40 2'199'023'255'551 2'199'023'255'552 2.20E+12
41 4'398'046'511'103 4'398'046'511'104 4.40E+12
42 8'796'093'022'207 8'796'093'022'208 8.80E+12
43 17'592'186'044'415 17'592'186'044'416 1.76E+13
44 35'184'372'088'831 35'184'372'088'832 3.52E+13
45 70'368'744'177'663 70'368'744'177'664 7.04E+13
46 140'737'488'355'327 140'737'488'355'328 1.41E+14
47 281'474'976'710'655 281'474'976'710'656 2.81E+14
48 562'949'953'421'311 562'949'953'421'312 5.63E+14
49 1'125'899'906'842'620 1'125'899'906'842'620 1.13E+15 ab hier
ist Calc überfordert!
50 2'251'799'813'685'250 2'251'799'813'685'250 2.25E+15
51 4'503'599'627'370'490 4'503'599'627'370'500 4.50E+15
52 9'007'199'254'740'990 9'007'199'254'740'990 9.01E+15
53 18'014'398'509'482'000 18'014'398'509'482'000 1.80E+16
54 36'028'797'018'964'000 36'028'797'018'964'000 3.60E+16
55 72'057'594'037'927'900 72'057'594'037'927'900 7.21E+16
56 144'115'188'075'856'000 144'115'188'075'856'000 1.44E+17
57 288'230'376'151'712'000 288'230'376'151'712'000 2.88E+17
58 576'460'752'303'424'000 576'460'752'303'424'000 5.76E+17
59 1'152'921'504'606'850'000 1'152'921'504'606'850'000 1.15E+18
60 2'305'843'009'213'690'000 2'305'843'009'213'690'000 2.31E+18
61 4'611'686'018'427'390'000 4'611'686'018'427'390'000 4.61E+18
62 9'223'372'036'854'780'000 9'223'372'036'854'780'000 9.22E+18
63 18'446'744'073'709'600'000 18'446'744'073'709'600'000 1.84E+19
Vielleicht erklärt das einiges...
Gruss Marino
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: users-de-help@openoffice.apache.org
>
>
--
Salvalaggio Marino
Kraftwerktechnik
Technische Betriebe Glarus-Nord
Produktion
Zentrale Risi 30
8752 Näfels
http://www.tbgn.ch/xml_3/internet/de/application/d223/f229.cfm
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by Horst Schulze <jr...@tandandale.de>.
Hallo an alle,
es ist schon interessant, was für eien Diskussion ich ausgelöst habe.
Ich gehe mal davon aus, dass der Fehler bei den anderen auch so aufgetregen ist, also
nachvollziebar war und somit nicht auf einen defekten Transistor in meinem
zugegebenermaßen betagten Rechner beruht. (Neuer kommt im April.)
Ist das so richtig? Oder tritt der Fehler woanders nicht auf?
Aber ich habe früher schon mal ähnliches beobachtet, aber den Fehler nicht eingrenzen
können bzw. ignoriert.
Wenn es auf einem Rundungsfehler beruht, kann man solche Abfragen nur mit einer
GANZZAHL() Funktion nutzen. Das müsste man wissen. Das müsste dann ja auch bei
WENN() Abfragen eintreffen.Eigentlich würde ich erwarten, dass so was intern abgefangen
wird.
Das mit dem logischen Fehler ist mir nicht ganz klar. Mit 6 Stellen dürfte doch das System
eigentlich zurechtkommen müssen. Ist immerhin doppelt so viel wie auf meinem alten
Rechenschieber :-) Quatsch. Ist ja eine Addition. Da habe ich den Abakus benutzt. Der war
genau.
> 1. Fehler Zwei Systeme:
Wieso zwei Systeme? Weil eines ein Festwert und das andere die Folge einer Addition ist?
Da dürfte trotzdem das nicht auftreten, nicht in dem Bereich.
Trotzdem an alle erst einmal vielen Dank.
Horst
Am 30 Jan 2013 um 18:29 hat G. Mohing geschrieben:
> Hallo Liste!
>
> Mit Verwunderung und dem nötigigen Amüsement habe ich in den letzten
> Wochen mit erleben dürfen wie dem Fehler bei zu kommen versucht
> wurde.
> Denn es handelt sich hier eindeutig um einen logischen, vielleicht
> sogar
> techenischen, Fehler.
>
> Möglichkeiten:
> 1. "Fehler":
> Die Daten wurden vom User in zwei Systemen bearbeitet: Ein- und
> Ausgabesysteme waren nicht identisch. Dies ist in der Programmierung
> untypisch.
>
> 2. "Fehler":
> Wie schon ausreichend angesprochen wurde kann man aus [pvv], der
> Genauigkeitsbetrachtung, die Genauigkeit durch weitere Betrachtung
> weiterer Nachkommastellen nicht erhöhen. Gehen also links vom
> Gleichheitszeichen max 2 Nachkommastellen in die Berechnung ein, so
> müssen es rechts eben so viele sein. Fallen einseitg mehr
> Nachkommastellen aus so bleiben diese, der Logik nach, unbeachtet.
> Eine
> Rundung erfolgt nicht.
>
> 3. "Fehler":
> Schlicht und ergreifend ein Hardwaredefekt. Generell rechnen
> Computer
> "anders" als wie man es mit dem Abakus nach Adam Ries mal lernte.
> Hierbei kann es sich um einen konstanten, periodischen oder
> zufälligen
> Gleitkommafehler handeln, der schlicht weg durch einen defekten
> Transistor erzeugt wird. Diese Fehler sind in Heim- PCs des öfternen
> anzutreffen. Deshalb unterscheidet man auch zwischen mathematischen
> und
> technisch- wissenschaftlichen Anwendungen/ Rechnern.
>
> In diesem Sinne wünsche ich noch einen schönen Abend.
>
> MfG
>
>
>
>
> --------------------------------------------------------------------
> -
> To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
> For additional commands, e-mail:
> users-de-help@openoffice.apache.org
>
----
Horst Schulze
Bitte diese E-Mail Adresse nicht mehr benutzen.
02323-388847
0171 3421726
Josefinenstr. 106a
44628 Herne
http://www.auf-partei.de/nrw
Sollten Sie diese Mail irrtümlich erhalten oder sind Sie nicht mehr an weiteren Informationen interessiert, so lassen
Sie uns das bitte durch eine kurze Rückantwort wissen.
Sollten Sie diese Mail durch Weiterleitung durch Freunde erhalten haben und weitere Informationen wünschen, so
senden Sie uns ebenfalls eine kurze Mail.
Re: =2884,6+3260-6106,25=38,35
Posted by "G. Mohing" <gm...@gmx.net>.
Hallo Liste!
Mit Verwunderung und dem nötigigen Amüsement habe ich in den letzten
Wochen mit erleben dürfen wie dem Fehler bei zu kommen versucht wurde.
Denn es handelt sich hier eindeutig um einen logischen, vielleicht sogar
techenischen, Fehler.
Möglichkeiten:
1. "Fehler":
Die Daten wurden vom User in zwei Systemen bearbeitet: Ein- und
Ausgabesysteme waren nicht identisch. Dies ist in der Programmierung
untypisch.
2. "Fehler":
Wie schon ausreichend angesprochen wurde kann man aus [pvv], der
Genauigkeitsbetrachtung, die Genauigkeit durch weitere Betrachtung
weiterer Nachkommastellen nicht erhöhen. Gehen also links vom
Gleichheitszeichen max 2 Nachkommastellen in die Berechnung ein, so
müssen es rechts eben so viele sein. Fallen einseitg mehr
Nachkommastellen aus so bleiben diese, der Logik nach, unbeachtet. Eine
Rundung erfolgt nicht.
3. "Fehler":
Schlicht und ergreifend ein Hardwaredefekt. Generell rechnen Computer
"anders" als wie man es mit dem Abakus nach Adam Ries mal lernte.
Hierbei kann es sich um einen konstanten, periodischen oder zufälligen
Gleitkommafehler handeln, der schlicht weg durch einen defekten
Transistor erzeugt wird. Diese Fehler sind in Heim- PCs des öfternen
anzutreffen. Deshalb unterscheidet man auch zwischen mathematischen und
technisch- wissenschaftlichen Anwendungen/ Rechnern.
In diesem Sinne wünsche ich noch einen schönen Abend.
MfG
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by tbgn <m....@gmx.ch>.
Wolfgang Jäth schrieb:
> Am 29.01.2013 19:07, schrieb Thomas Kübler:
>> Bisher hat noch keiner geprüft, ob die Ziffernfolge 61446 der
>> Dezimalzahl als Mantisse in 23 Bit im Binärsystem passen. (Oder liegt es
>> an 610625?)
> Dezimal Hexadezimal Binär
> 61446 = F006 = 1111 0000 0000 0110 = 16 Stellen
61446 = F006 = 1111 0000 0000 0110 korrekt
> 610625 = 95141 = 1001 0011 0001 0100 0001 = 20 Stellen
610625 = 95141 = 1001 0101 0001 0100 0001 / da hast Du Dich
verschrieben
nur zum Richtigstellen.
>
> Wolf 'und zur Darstellung in der Mantisse wird sogar noch 1 Bit weniger
> benötigt, da das MSB weg fällt (man Normierung)' gang
Was bei Calc wichtig zu beachten ist, dass das Format bei solchen
Rechnungen nicht mit begrenzen Kommastellen gesetzt ist, sonst kommt
es sehr schnell zu Rundungen!
Wenn solch gerundete Werte an andere Zellen weitergegeben werden,
gehen die über hängigen Werte schliesslich verloren. (auch bei Excel
nicht anders)
Bei der Summe aus diversen Faktoren aus Fakturen (welche z.B. mit
%Abzügen berechnet wurden) ist das ja auch Sinnvoll,
sonst würden ja die Summe um die Rundungen fehlerhaft erscheinen
(Rundung-Differenzen)!
Beispiel:
Preis Skonto VP-Rnd VP
SFr. 101.00 3.33% SFr. 97.6 97.636700
SFr. 74.50 3.33% SFr. 72.0 72.019150
SFr. 66.25 3.33% SFr. 64.0 64.043875
SFr. 79.75 3.33% SFr. 77.1 77.094325
SFr. 225.70 3.33% SFr. 218.2 218.184190
SFr. 225.65 3.33% SFr. 218.1 218.135855
SFr. 111.30 3.33% SFr. 107.6 107.593710
SFr. 121.35 3.33% SFr. 117.3 117.309045
SFr. 225.70 3.33% SFr. 218.2 218.184190
SFr. 225.65 3.33% SFr. 218.1 218.135855
Summen
SFr. 1'408.20 1408.336895
Da gehen 10 Cent in die Binsen!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by Wolfgang Jäth <ja...@arcor.de>.
Am 29.01.2013 19:07, schrieb Thomas Kübler:
>
> Bisher hat noch keiner geprüft, ob die Ziffernfolge 61446 der
> Dezimalzahl als Mantisse in 23 Bit im Binärsystem passen. (Oder liegt es
> an 610625?)
Dezimal Hexadezimal Binär
61446 = F006 = 1111 0000 0000 0110 = 16 Stellen
610625 = 95141 = 1001 0011 0001 0100 0001 = 20 Stellen
Wolf 'und zur Darstellung in der Mantisse wird sogar noch 1 Bit weniger
benötigt, da das MSB weg fällt (man Normierung)' gang
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
OT-Re: =2884,6+3260-6106,25=38,35
Posted by Salvalaggio Marino <m....@gmx.ch>.
Preis Skonto VP-Rnd VP
SFr. 101.00 3.33% SFr. 97.6 97.636700
SFr. 74.50 3.33% SFr. 72.0 72.019150
SFr. 66.25 3.33% SFr. 64.0 64.043875
SFr. 79.75 3.33% SFr. 77.1 77.094325
SFr. 225.70 3.33% SFr. 218.2 218.184190
SFr. 225.65 3.33% SFr. 218.1 218.135855
SFr. 111.30 3.33% SFr. 107.6 107.593710
SFr. 121.35 3.33% SFr. 117.3 117.309045
SFr. 225.70 3.33% SFr. 218.2 218.184190
SFr. 225.65 3.33% SFr. 218.1 218.135855
Summen SFr. 1'408.20 1408.336895
Zum Thema Rundungen noch eine kleine Geschichte.
Da gab es vor etlichen Jahren mal einen ganz Schlauen!
Der war IT-Angestellter einer Grossbank und hat sich überlegt, dass die
Rundung-Differenzen ja in der Buchhaltung nirgends erscheinen. So hat er
eine Konto für diese Rundungen eingerichtet, in welches er aber nur die
Ab-Rundungen bei Gutschriften ein-buchte. Da auf einer solchen Bank
täglich tausende solcher Buchungen vorgenommen werden, sprengte die
Summe in kurzer Zeit die Millionengrenze.
Er finanzierte sich damit Ferien in der Karibik. Dabei hatte er aber
unterlassen, die Funktion während seiner Abwesenheit still zu legen. Das
Ende der Geschichte:
Seine Vertretung stellte während seiner Abwesenheit merkwürdige
Umbuchungen fest und das Ganze ist schliesslich, nach über einem Jahr
Laufzeit, geplatzt.
Gruss Marino
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by Salvalaggio Marino <m....@gmx.ch>.
Thomas Kübler schrieb:
> Hallo Marino,
>
>>
>> Die Formate Exp, Real und Float sind ohne Vorzeichen nicht
>> verfügbar!
>>
>> Damit der Prozessor mit grösseren Werten arbeiten kann, muss das
>> Übertrag-Flag abgefangen werden und in einen zweiten Variable
>> portiert
>> werden.
>> Solches nutzt man bei 8Bit Rechnern, wenn man auf 16Bit erweitert
>> bez.
>> bei 16Bit->32Bit oder 32Bit->64. Das muss aber vom Programm
>> unterstützt
>> werden sonst geht das eben nicht!
>>
>> Marino
>
>
> Du hast mit Deinen Feststellungen Recht. Nur ging es hier nicht um
> die Darstellungsweisen von Zahlen, sondern um Rundungsfehler:
>
> Ausgangspunkt war die Rechnung von Horst (21.1.2013):
>> =2884,6+3260-6106,25-38,35 ergibt
>> 3,62E-13
> Obwohl es eigentlich Null sein sollte.
>
>
> Nach mehreren Kommentaren ergab sich das Problem:
>> Also (bei calc):
>> 6144,6-6106,25=38,350000000000400
>> 144,6- 106,25=38,350000000000000
>
> Da die Zahlen intern im einfachen Gleitkommasystem (Type single)
> verarbeitet werden, treten Rundungsfehler auf. Die Mantisse hat
> also eine Genauigkeit von 23 Bit (wie Wolfgang und Du festgestellt
> haben).
>
> Bisher hat noch keiner geprüft, ob die Ziffernfolge 61446 der
> Dezimalzahl als Mantisse in 23 Bit im Binärsystem passen. (Oder
> liegt es an 610625?)
> Ich weiß nicht, wie ich das prüfen kann. Vielleicht hast Du eine
> Idee?
>
Hab mal
eine kleine Tabelle in Calc erstellt, welche zeigt, wo der
Überlauf stattfindet. Wie in Calc die Rundung im Einzelnen
behandelt, weiss ich jedoch nicht, scheint mir aber nach Standard
abzulaufen <5 =0 >=5 =1.
Bit Maximal-Wert 0..x Zustände (0/1) Exp.Notation
0 1 2 2.00E+00
1 3 4 4.00E+00
2 7 8 8.00E+00
3 15 16 1.60E+01
4 31 32 3.20E+01
5 63 64 6.40E+01
6 127 128 1.28E+02
7 255 256 2.56E+02
8 511 512 5.12E+02
9 1'023 1'024 1.02E+03
10 2'047 2'048 2.05E+03 hier wird „E“ das erste mal gerundet!
11 4'095 4'096 4.10E+03
12 8'191 8'192 8.19E+03
13 16'383 16'384 1.64E+04
14 32'767 32'768 3.28E+04
15 65'535 65'536 6.55E+04
16 131'071 131'072 1.31E+05
17 262'143 262'144 2.62E+05
18 524'287 524'288 5.24E+05
19 1'048'575 1'048'576 1.05E+06
20 2'097'151 2'097'152 2.10E+06
21 4'194'303 4'194'304 4.19E+06
22 8'388'607 8'388'608 8.39E+06
23 16'777'215 16'777'216 1.68E+07
24 33'554'431 33'554'432 3.36E+07
25 67'108'863 67'108'864 6.71E+07
26 134'217'727 134'217'728 1.34E+08
27 268'435'455 268'435'456 2.68E+08
28 536'870'911 536'870'912 5.37E+08
29 1'073'741'823 1'073'741'824 1.07E+09
30 2'147'483'647 2'147'483'648 2.15E+09
31 4'294'967'295 4'294'967'296 4.29E+09
32 8'589'934'591 8'589'934'592 8.59E+09
33 17'179'869'183 17'179'869'184 1.72E+10
34 34'359'738'367 34'359'738'368 3.44E+10
35 68'719'476'735 68'719'476'736 6.87E+10
36 137'438'953'471 137'438'953'472 1.37E+11
37 274'877'906'943 274'877'906'944 2.75E+11
38 549'755'813'887 549'755'813'888 5.50E+11
39 1'099'511'627'775 1'099'511'627'776 1.10E+12
40 2'199'023'255'551 2'199'023'255'552 2.20E+12
41 4'398'046'511'103 4'398'046'511'104 4.40E+12
42 8'796'093'022'207 8'796'093'022'208 8.80E+12
43 17'592'186'044'415 17'592'186'044'416 1.76E+13
44 35'184'372'088'831 35'184'372'088'832 3.52E+13
45 70'368'744'177'663 70'368'744'177'664 7.04E+13
46 140'737'488'355'327 140'737'488'355'328 1.41E+14
47 281'474'976'710'655 281'474'976'710'656 2.81E+14
48 562'949'953'421'311 562'949'953'421'312 5.63E+14
49 1'125'899'906'842'620 1'125'899'906'842'620 1.13E+15 ab hier
ist Calc überfordert!
50 2'251'799'813'685'250 2'251'799'813'685'250 2.25E+15
51 4'503'599'627'370'490 4'503'599'627'370'500 4.50E+15
52 9'007'199'254'740'990 9'007'199'254'740'990 9.01E+15
53 18'014'398'509'482'000 18'014'398'509'482'000 1.80E+16
54 36'028'797'018'964'000 36'028'797'018'964'000 3.60E+16
55 72'057'594'037'927'900 72'057'594'037'927'900 7.21E+16
56 144'115'188'075'856'000 144'115'188'075'856'000 1.44E+17
57 288'230'376'151'712'000 288'230'376'151'712'000 2.88E+17
58 576'460'752'303'424'000 576'460'752'303'424'000 5.76E+17
59 1'152'921'504'606'850'000 1'152'921'504'606'850'000 1.15E+18
60 2'305'843'009'213'690'000 2'305'843'009'213'690'000 2.31E+18
61 4'611'686'018'427'390'000 4'611'686'018'427'390'000 4.61E+18
62 9'223'372'036'854'780'000 9'223'372'036'854'780'000 9.22E+18
63 18'446'744'073'709'600'000 18'446'744'073'709'600'000 1.84E+19
Vielleicht erklärt das einiges...
Gruss Marino
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: users-de-help@openoffice.apache.org
>
>
--
Salvalaggio Marino
Kraftwerktechnik
Technische Betriebe Glarus-Nord
Produktion
Zentrale Risi 30
8752 Näfels
http://www.tbgn.ch/xml_3/internet/de/application/d223/f229.cfm
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by Thomas Kübler <th...@web.de>.
Hallo Marino,
Am 29.01.2013 14:00, schrieb Salvalaggio Marino:
> Wolfgang Jäth schrieb:
>> Am 28.01.2013 08:07, schrieb Salvalaggio Marino:
>>>
>>>> IMHO nein; das Vorzeichen müsste schon rausgerechnet sein (jedenfalls
>>>> ergeben 23 Bit für die Mantisse + 8 Bit für den Exponenten nur 31 Bit;
>>>> auf die vollen 32 Bit fehlt also noch eines).
>>>>
>>>
>>> Wie soll denn ein Vorzeichen wie Du sagst rausgerechnet werden?
>>
>> http://de.wikipedia.org/w/index.php?title=Datei:IEEE-754-single.svg&filetimestamp=20110525181832
>>
>>
>> (aus
>> http://de.wikipedia.org/wiki/IEEE_754#Zahlenformate_und_andere_Festlegungen_des_IEEE-754-Standards
>>
>> ).
>
> >
>
> Was soll ich jetzt damit?
>
> Da wird ja genau das ausgesagt, das ich Dir vermitteln will!
>
> Typ Größe Exponent Mantisse Werte des Exponenten
> single 32 bit 8 bit 23 bit - 126 ≤ e ≤ 127
> double 64 bit 11 bit 52 bit -1022 ≤ e ≤ 1023
>
> wie Du rechen kannst:
> bei 32Bit 8+23 = 31bit
> bei 64Bit 11+52 = 63bit
>
> Wie Du sehen kannst, ist das Bit 31 bez. 63 immer mit dem Vorzeichen
> belegt. Bei TRUE ist der Wert negativ, bei FALSE positiv.
> Das Gleiche gilt übrigens auch für den Exponenten.
>
> Dieser umfasst ja bei 32Bit ein ganzes Byte FF = 255.
> In diesem eingelagerten Byte (Bit 23..30) wird wiederum das
> grösste Bit (Bit 30 des Ganzen 32er Formats) für das Vorzeichen benutzt.
> Darum sind grössere Exponenten als -126..127 ebenso nicht möglich!
>
> Nur für die Formate HEX und unsigned ist das Bit 31 bez. 63 für den Wert
> nutzbar. Die aber kennen keine Vorzeichen!
>
> Die Formate Exp, Real und Float sind ohne Vorzeichen nicht verfügbar!
>
> Damit der Prozessor mit grösseren Werten arbeiten kann, muss das
> Übertrag-Flag abgefangen werden und in einen zweiten Variable portiert
> werden.
> Solches nutzt man bei 8Bit Rechnern, wenn man auf 16Bit erweitert bez.
> bei 16Bit->32Bit oder 32Bit->64. Das muss aber vom Programm unterstützt
> werden sonst geht das eben nicht!
>
> Marino
Du hast mit Deinen Feststellungen Recht. Nur ging es hier nicht um die
Darstellungsweisen von Zahlen, sondern um Rundungsfehler:
Ausgangspunkt war die Rechnung von Horst (21.1.2013):
> =2884,6+3260-6106,25-38,35 ergibt
> 3,62E-13
Obwohl es eigentlich Null sein sollte.
Nach mehreren Kommentaren ergab sich das Problem:
> Also (bei calc):
> 6144,6-6106,25=38,350000000000400
> 144,6- 106,25=38,350000000000000
Da die Zahlen intern im einfachen Gleitkommasystem (Type single)
verarbeitet werden, treten Rundungsfehler auf. Die Mantisse hat also
eine Genauigkeit von 23 Bit (wie Wolfgang und Du festgestellt haben).
Bisher hat noch keiner geprüft, ob die Ziffernfolge 61446 der
Dezimalzahl als Mantisse in 23 Bit im Binärsystem passen. (Oder liegt es
an 610625?)
Ich weiß nicht, wie ich das prüfen kann. Vielleicht hast Du eine Idee?
Viele Grüße
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by Salvalaggio Marino <m....@gmx.ch>.
Wolfgang Jäth schrieb:
> Am 28.01.2013 08:07, schrieb Salvalaggio Marino:
>>
>>> IMHO nein; das Vorzeichen müsste schon rausgerechnet sein (jedenfalls
>>> ergeben 23 Bit für die Mantisse + 8 Bit für den Exponenten nur 31 Bit;
>>> auf die vollen 32 Bit fehlt also noch eines).
>>>
>>
>> Wie soll denn ein Vorzeichen wie Du sagst rausgerechnet werden?
>
> http://de.wikipedia.org/w/index.php?title=Datei:IEEE-754-single.svg&filetimestamp=20110525181832
>
> (aus
> http://de.wikipedia.org/wiki/IEEE_754#Zahlenformate_und_andere_Festlegungen_des_IEEE-754-Standards
> ).
>
Was soll ich jetzt damit?
Da wird ja genau das ausgesagt, das ich Dir vermitteln will!
Typ Größe Exponent Mantisse Werte des Exponenten
single 32 bit 8 bit 23 bit - 126 ≤ e ≤ 127
double 64 bit 11 bit 52 bit -1022 ≤ e ≤ 1023
wie Du rechen kannst:
bei 32Bit 8+23 = 31bit
bei 64Bit 11+52 = 63bit
Wie Du sehen kannst, ist das Bit 31 bez. 63 immer mit dem Vorzeichen
belegt. Bei TRUE ist der Wert negativ, bei FALSE positiv.
Das Gleiche gilt übrigens auch für den Exponenten.
Dieser umfasst ja bei 32Bit ein ganzes Byte FF = 255.
In diesem eingelagerten Byte (Bit 23..30) wird wiederum das
grösste Bit (Bit 30 des Ganzen 32er Formats) für das Vorzeichen benutzt.
Darum sind grössere Exponenten als -126..127 ebenso nicht möglich!
Nur für die Formate HEX und unsigned ist das Bit 31 bez. 63 für den Wert
nutzbar. Die aber kennen keine Vorzeichen!
Die Formate Exp, Real und Float sind ohne Vorzeichen nicht verfügbar!
Damit der Prozessor mit grösseren Werten arbeiten kann, muss das
Übertrag-Flag abgefangen werden und in einen zweiten Variable portiert
werden.
Solches nutzt man bei 8Bit Rechnern, wenn man auf 16Bit erweitert bez.
bei 16Bit->32Bit oder 32Bit->64. Das muss aber vom Programm unterstützt
werden sonst geht das eben nicht!
Marino
>
> Wolfgang
>
--
-------------------------------
Salvalaggio Marino
Technische Betriebe Glarus-Nord
Produktion, Risi 30
8752 Näfels
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by Wolfgang Jäth <ja...@arcor.de>.
Am 28.01.2013 08:07, schrieb Salvalaggio Marino:
>
>> IMHO nein; das Vorzeichen müsste schon rausgerechnet sein (jedenfalls
>> ergeben 23 Bit für die Mantisse + 8 Bit für den Exponenten nur 31 Bit;
>> auf die vollen 32 Bit fehlt also noch eines).
>>
>
> Wie soll denn ein Vorzeichen wie Du sagst rausgerechnet werden?
http://de.wikipedia.org/w/index.php?title=Datei:IEEE-754-single.svg&filetimestamp=20110525181832
(aus
http://de.wikipedia.org/wiki/IEEE_754#Zahlenformate_und_andere_Festlegungen_des_IEEE-754-Standards
).
Wolfgang
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by Salvalaggio Marino <m....@gmx.ch>.
Wolfgang Jäth schrieb:
> IMHO nein; das Vorzeichen müsste schon rausgerechnet sein (jedenfalls
> ergeben 23 Bit für die Mantisse + 8 Bit für den Exponenten nur 31 Bit;
> auf die vollen 32 Bit fehlt also noch eines).
>
Wie soll denn ein Vorzeichen wie Du sagst rausgerechnet werden?
Das ginge nur, wenn "int" zu "uint" überführt würde. Das ist in einer
Kalkulationstabelle aber nicht so ohne weiteres möglich!
Marino
> Wolfgang
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by Wolfgang Jäth <ja...@arcor.de>.
Am 28.01.2013 07:47, schrieb Salvalaggio Marino:
>
>>> ich weiss ja nicht, wie das Programm im einzelnen eine Variable an das
>>> System übergibt.
>>> Erfahrungsgemäss aber ist bei Integer 32Bit immer auf Bit 31 das
>>> Vorzeichen eingebunden.
>>> So ergibt sich eine Bereich von -32'768...+32'767
>>> mehr kann so nicht dargestellt werden.
>>> bei usint 0...65'535 Ende der Fahnenstange!
>>
>> Föllig valsche Baustelle.
>
> Na, nicht so ganz... Der Prozessor kann schlussendlich nur mit Hex etwas
> anfangen mehr als FFFF'FFFF ist einfach unter 32Bit nicht möglich...
Ja und? Entscheidend ist doch nicht, wie etwas dargestellt wird, sondern
wie es interpretiert wird.
> Wird nun signed übergeben ist das grösste Bit halt für +/- reserviert!
Nochmal: es geht um Gleitkommazahlen, nicht um Integer. Bitte informiere
Dich erst mal über das interne Darstellungsformat von Gleitkommazahlen.
> Da auch Mantissen und Gleitkommazahlen negativ sein können gilt das dort
> ebenso...
Bei Gleitkommazahlen ist das noch ein ganz klein wenig komplizierter; da
gibt es um Bleistift plötzlich /zwei/ Vorzeichen (oder glaubst Du, der
Exponent braucht keines?) ...
> Ich hatte das erwähnt, weil jemand aussagte, dass die berechnete Summe
> 31 Bits nutze und somit ein Bit fehle.
Nicht die berechnete Summe, sondern das verwendete Zahlenformat.
> Das ist eben nicht stimmig!
Du hältst also das für internationale Normierungen zuständige Institute
of Electrical and Electronics Engineers nur für eine Horde Idioten? <g>
Wolfgang
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by Salvalaggio Marino <m....@gmx.ch>.
Wolfgang Jäth schrieb:
> Am 25.01.2013 13:25, schrieb Salvalaggio Marino:
>>
>> ich weiss ja nicht, wie das Programm im einzelnen eine Variable an das
>> System übergibt.
>> Erfahrungsgemäss aber ist bei Integer 32Bit immer auf Bit 31 das
>> Vorzeichen eingebunden.
>> So ergibt sich eine Bereich von -32'768...+32'767
>> mehr kann so nicht dargestellt werden.
>> bei usint 0...65'535 Ende der Fahnenstange!
>
> Föllig valsche Baustelle.
Na, nicht so ganz... Der Prozessor kann schlussendlich nur mit Hex etwas
anfangen mehr als FFFF'FFFF ist einfach unter 32Bit nicht möglich...
Wird nun signed übergeben ist das grösste Bit halt für +/- reserviert!
Da auch Mantissen und Gleitkommazahlen negativ sein können gilt das dort
ebenso...
Ich hatte das erwähnt, weil jemand aussagte, dass die berechnete Summe
31 Bits nutze und somit ein Bit fehle. Das ist eben nicht stimmig!
>
> Hint: Es geht um die Mantisse einer Gleitkommazahl.
>
> Wolfgang
>
Marino
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by Wolfgang Jäth <ja...@arcor.de>.
Am 25.01.2013 13:25, schrieb Salvalaggio Marino:
>
> ich weiss ja nicht, wie das Programm im einzelnen eine Variable an das
> System übergibt.
> Erfahrungsgemäss aber ist bei Integer 32Bit immer auf Bit 31 das
> Vorzeichen eingebunden.
> So ergibt sich eine Bereich von -32'768...+32'767
> mehr kann so nicht dargestellt werden.
> bei usint 0...65'535 Ende der Fahnenstange!
Föllig valsche Baustelle.
Hint: Es geht um die Mantisse einer Gleitkommazahl.
Wolfgang
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by Salvalaggio Marino <m....@gmx.ch>.
Hi,
ich weiss ja nicht, wie das Programm im einzelnen eine Variable an das
System übergibt.
Erfahrungsgemäss aber ist bei Integer 32Bit immer auf Bit 31 das
Vorzeichen eingebunden.
So ergibt sich eine Bereich von -32'768...+32'767
mehr kann so nicht dargestellt werden.
bei usint 0...65'535 Ende der Fahnenstange!
Gruss Marino
Wolfgang Jäth schrieb:
>>
>> Und hier liegt das Problem:
>> Du schreibst: 6-7 Stellen. Die Zahl -6106,25 hat aber ein Vorzeichen ==>
>> 6,5 Stellen.
>
> IMHO nein; das Vorzeichen müsste schon rausgerechnet sein (jedenfalls
> ergeben 23 Bit für die Mantisse + 8 Bit für den Exponenten nur 31 Bit;
> auf die vollen 32 Bit fehlt also noch eines).
>
> Wolfgang
>
--
-------------------------------
Salvalaggio Marino
Technische Betriebe Glarus-Nord
Produktion, Risi 30
8752 Näfels
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by David Paenson <da...@gmail.com>.
Ah Ok, jetzt verstehe ich. Seltsam in der Tat
2013/1/22 Thomas Kübler <th...@web.de>
> Hallo David,
>
> ich habe das Problem reduziert auf:
> 6144,6-6106,25
> Auf dem Taschenrechner erhälst Du 38,35.
> calc zeigt zwar bei normaler Formatierung auch 38,35 an, aber erweiterst
> Du die Nachkommastellen auf 15 Stellen, so siehst Du:
> 38,350000000000400
>
> Also (bei calc):
> 6144,6-6106,25=38,**350000000000400
> 144,6- 106,25=38,350000000000000
>
>
> Viele Grüße
> Thomas
>
>
> Am 22.01.2013 18:26, schrieb David Paenson:
>
> 2884,6+3260-6106,25=38,35
>> Inbox
>> x Ich verstehe den Thread nicht. O.a. Zahlen habe ich soeben in meinen
>> Taschenrechner eingetippt und bekomme das gleiche Ergebnis raus. Ist doch
>> alles richtig, soweit ich sehen kann.
>>
>> 2884,6
>> +3260
>> -6106,25
>>
>> = 38,35
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-de-unsubscribe@**openoffice.apache.org<us...@openoffice.apache.org>
> For additional commands, e-mail: users-de-help@openoffice.**apache.org<us...@openoffice.apache.org>
>
>
Re: =2884,6+3260-6106,25=38,35
Posted by Thomas Kübler <th...@web.de>.
Hallo David,
ich habe das Problem reduziert auf:
6144,6-6106,25
Auf dem Taschenrechner erhälst Du 38,35.
calc zeigt zwar bei normaler Formatierung auch 38,35 an, aber erweiterst
Du die Nachkommastellen auf 15 Stellen, so siehst Du:
38,350000000000400
Also (bei calc):
6144,6-6106,25=38,350000000000400
144,6- 106,25=38,350000000000000
Viele Grüße
Thomas
Am 22.01.2013 18:26, schrieb David Paenson:
> 2884,6+3260-6106,25=38,35
> Inbox
> x Ich verstehe den Thread nicht. O.a. Zahlen habe ich soeben in meinen
> Taschenrechner eingetippt und bekomme das gleiche Ergebnis raus. Ist doch
> alles richtig, soweit ich sehen kann.
>
> 2884,6
> +3260
> -6106,25
>
> = 38,35
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by David Paenson <da...@gmail.com>.
2884,6+3260-6106,25=38,35
Inbox
x Ich verstehe den Thread nicht. O.a. Zahlen habe ich soeben in meinen
Taschenrechner eingetippt und bekomme das gleiche Ergebnis raus. Ist doch
alles richtig, soweit ich sehen kann.
2884,6
+3260
-6106,25
= 38,35
2013/1/22 Wolfgang Jäth <ja...@arcor.de>
> Am 22.01.2013 10:01, schrieb Thomas Kübler:
> >
> >> Dennoch verstehe ich das Auftreten eines Rundungsfehlers hier nicht
> >> ganz; alle drei vorkommenden Zahlen sowie alle Zwischenergebnisse sind
> >> eigentlich klein genug, um als Datentyp Single[1] fehlerfrei dargestellt
> >> werden zu können.
> >>
> >> [1] Bei einer Mantisse von 23 Bit sind Darstellungen bis 2^23=8388608
> >> möglich, d. h. 6-7 signifikante Stellen; der längste verwendete Wert
> >> (-6106,25) hat aber überhaupt nur 6 Stellen.
> >
> > Und hier liegt das Problem:
> > Du schreibst: 6-7 Stellen. Die Zahl -6106,25 hat aber ein Vorzeichen ==>
> > 6,5 Stellen.
>
> IMHO nein; das Vorzeichen müsste schon rausgerechnet sein (jedenfalls
> ergeben 23 Bit für die Mantisse + 8 Bit für den Exponenten nur 31 Bit;
> auf die vollen 32 Bit fehlt also noch eines).
>
> Wolfgang
> --
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: users-de-help@openoffice.apache.org
>
>
Re: =2884,6+3260-6106,25=38,35
Posted by Wolfgang Jäth <ja...@arcor.de>.
Am 22.01.2013 10:01, schrieb Thomas Kübler:
>
>> Dennoch verstehe ich das Auftreten eines Rundungsfehlers hier nicht
>> ganz; alle drei vorkommenden Zahlen sowie alle Zwischenergebnisse sind
>> eigentlich klein genug, um als Datentyp Single[1] fehlerfrei dargestellt
>> werden zu können.
>>
>> [1] Bei einer Mantisse von 23 Bit sind Darstellungen bis 2^23=8388608
>> möglich, d. h. 6-7 signifikante Stellen; der längste verwendete Wert
>> (-6106,25) hat aber überhaupt nur 6 Stellen.
>
> Und hier liegt das Problem:
> Du schreibst: 6-7 Stellen. Die Zahl -6106,25 hat aber ein Vorzeichen ==>
> 6,5 Stellen.
IMHO nein; das Vorzeichen müsste schon rausgerechnet sein (jedenfalls
ergeben 23 Bit für die Mantisse + 8 Bit für den Exponenten nur 31 Bit;
auf die vollen 32 Bit fehlt also noch eines).
Wolfgang
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by Thomas Kübler <th...@web.de>.
Hallo Wolfgang,
Am 22.01.2013 07:29, schrieb Wolfgang Jäth:
> Am 22.01.2013 06:10, schrieb Thomas Kübler:
>> ich erhalte für die Formel (in einem Feld) auch 3,62E-13 als Ergebnis.
>
> Ich auch; allerdings nur, wenn ich das Zellenformat auf
> 'wissenschaftlich' stelle. Im Standardzahlenformat steht da eine Null.
Ich habe mal das Format 0,000000000000000 genommen. Dabei sieht man wo
der Fehler auftaucht.
> Dennoch verstehe ich das Auftreten eines Rundungsfehlers hier nicht
> ganz; alle drei vorkommenden Zahlen sowie alle Zwischenergebnisse sind
> eigentlich klein genug, um als Datentyp Single[1] fehlerfrei dargestellt
> werden zu können.
>
> [1] Bei einer Mantisse von 23 Bit sind Darstellungen bis 2^23=8388608
> möglich, d. h. 6-7 signifikante Stellen; der längste verwendete Wert
> (-6106,25) hat aber überhaupt nur 6 Stellen.
Und hier liegt das Problem:
Du schreibst: 6-7 Stellen. Die Zahl -6106,25 hat aber ein Vorzeichen ==>
6,5 Stellen. Der andere Summand liegt auch im Grenzbereich der
(einfachen) Genauigkeit. Da kann schon ein Bit unter den Tisch fallen.
> Aber bei mir kommt auch da 3,62E-013 raus:
>
> Inhalt Anzeige
> 1 2884,6 2884,6
> 2 3260 3260
> 3 -6106,25 -6106,25
> 4 -38,35 -38,35
> 5
> 6 =A1+A2 6144,6
> 7 =A6+A3 38,35
> 8 =A7+A4 3,62E-013
Danke, dass Du es noch weiter aufgesplittet hast.
Dadurch habe ich gesehen, dass das Rundungsproblem bei der Addition der
Zahlen 6144,6 und -6106,25 entstehen. Lässt man die Tausender weg, und
addiert 144,6 mit -106,25, so entsteht kein Rundungsproblem/Fehler.
Es hat also etwas mit der Anzahl der Stellen zu tun.
Mein Problem war noch, wieso bei der Summenfunktion summe() kein
Rundungsproblem auftritt. Es muss an der Reihenfolge der einzelnen
Additionen liegen.
Egal mit welchen Mitteln von calc ich die Zahlen 6144,6 und -6106,25
addiere, es kommt immer dieselbe Ungenauigkeit ins Spiel.
Viele Grüße
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by Wolfgang Jäth <ja...@arcor.de>.
Am 22.01.2013 06:10, schrieb Thomas Kübler:
> Hallo Horst,
>
> ich erhalte für die Formel (in einem Feld) auch 3,62E-13 als Ergebnis.
Ich auch; allerdings nur, wenn ich das Zellenformat auf
'wissenschaftlich' stelle. Im Standardzahlenformat steht da eine Null.
Dennoch verstehe ich das Auftreten eines Rundungsfehlers hier nicht
ganz; alle drei vorkommenden Zahlen sowie alle Zwischenergebnisse sind
eigentlich klein genug, um als Datentyp Single[1] fehlerfrei dargestellt
werden zu können.
[1] Bei einer Mantisse von 23 Bit sind Darstellungen bis 2^23=8388608
möglich, d. h. 6-7 signifikante Stellen; der längste verwendete Wert
(-6106,25) hat aber überhaupt nur 6 Stellen.
> Warum ist das Ergebnis der Summe aber exakt Null, wenn ich die Zahlen in
> vier untereinanderstehende Felder schreibe und im fünften Feld die Summe
> bilde?
>
> 2884,6
> 3260
> -8106,25
> -38,35
> ---------
> 0,00E+00
Das sind unterschiedliche Rechenschritte (die Betonung liegt auf
'Schritte'), und dabei können dann halt auch unterschiedliche
Rundungsergebnisse entstehen.
Aber bei mir kommt auch da 3,62E-013 raus:
Inhalt Anzeige
1 2884,6 2884,6
2 3260 3260
3 -6106,25 -6106,25
4 -38,35 -38,35
5
6 =A1+A2 6144,6
7 =A6+A3 38,35
8 =A7+A4 3,62E-013
Wolfgang
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by Thomas Kübler <th...@web.de>.
Hallo Horst,
ich erhalte für die Formel (in einem Feld) auch 3,62E-13 als Ergebnis.
Warum ist das Ergebnis der Summe aber exakt Null, wenn ich die Zahlen in
vier untereinanderstehende Felder schreibe und im fünften Feld die Summe
bilde?
2884,6
3260
-8106,25
-38,35
---------
0,00E+00
Viele Grüße
Thomas
Am 21.01.2013 22:46, schrieb icetex@web.de:
> Das Ergebnis ist korrekt,
> genauer kann eine im dualen Zahlensystem durchgeführte Rechnung,
> die im dezimalen Zahlensystem angezeigt wird, nicht sein.
> Es weicht um 0,000000000000362 von Null ab.
> Das ist so gut wie Null.
> Am 21.01.2013 22:31, schrieb Horst Schulze:
>> ich hatte ein Problem in einer Tabelle und bin letztendlich auf
>> folgende Formel gestoßen:
>>
>> =2884,6+3260-6106,25=38,35
>>
>> Das ist FALSCH.
>>
>> Warum? Passiert das nur bei mir oder auch woanders?
>>
>> =2884,6+3260-6106,25-38,35 ergibt
>> 3,62E-13
>>
>> Für einen kurzen Test und Rückmeldung wäre ich dankbar.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-de-help@openoffice.apache.org
Re: =2884,6+3260-6106,25=38,35
Posted by "icetex@web.de" <ic...@web.de>.
Hallo Horst,
Das Ergebnis ist korrekt,
genauer kann eine im dualen Zahlensystem durchgeführte Rechnung,
die im dezimalen Zahlensystem angezeigt wird, nicht sein.
Es weicht um 0,000000000000362 von Null ab.
Das ist so gut wie Null.
Jörn
Am 21.01.2013 22:31, schrieb Horst Schulze:
> Hallo,
>
> ich hatte ein Problem in einer Tabelle und bin letztendlich auf
> folgende Formel gestoßen:
>
> =2884,6+3260-6106,25=38,35
>
> Das ist FALSCH.
>
> Warum? Passiert das nur bei mir oder auch woanders?
>
> =2884,6+3260-6106,25-38,35 ergibt
> 3,62E-13
>
> Für einen kurzen Test und Rückmeldung wäre ich dankbar.
>
> Horst Schulze
>
> ----
> Horst Schulze
>
> *Die christliche Alternative für NRW!*
> graphic
> _AUF-Partei für Arbeit, Umwelt und Familie_
> _Christen für Deutschland_
> Landesverband Nordrhein-Westfalen
> 02323-388847
> 0171 3421726
> Josefinenstr. 106a
> 44628 Herne
>
>
> _http://www.auf-partei.de/nrw_ <http://www.auf-partei.de/nrw/>
> Sollten Sie diese Mail irrtümlich erhalten oder sind Sie nicht mehr an
> weiteren Informationen interessiert, so lassen Sie uns das bitte durch
> eine kurze Rückantwort wissen.
> Sollten Sie diese Mail durch Weiterleitung durch Freunde erhalten
> haben und weitere Informationen wünschen, so senden Sie uns ebenfalls
> eine kurze Mail.