Probleme mit Trunc

[hhcm]

Hallo zusammen,

kann mir mal jemand auf die Sprünge helfen?

Delphi-Quellcode:

var
    c: Int64;
    a,b: Double;
begin
  a := 1.71;
  c := Trunc(a*100); // C=170

  a := 1.71;
  b := a*100;
  c := Trunc(b); // C=171

Warum ist der erste versuch falsch?

[gammatester]

Ich vermute, daß Du mit der 32-Bit-Version rechnest.

Dann ist das erste Ergebnis verständlich, da a*100 als Extended gerechnet wird: Das Zwischenresultat 170.999999999999996 wird dann auf 170 abgeschnitten.

Unter 64-Bit ist das Zwischenresultat 171.000000000000000.

Im Deinem zweiten Fall wird das Zwischenresultat erst nach Double gerundet und in b gespeichet (hat also wie bei 64-Bit den Wert 171.0)

[OLDIE1950]

In Delphi konvertiert Trunc eine Gleitkommazahl in einen Integer-Wert.
X ist ein Ausdruck des Typs Real.
Trunc gibt einen Int64-Wert mit dem gegen 0 gerundeten Wert von X zurück.
http://docwiki.embarcadero.com/Libra...e/System.Trunc

[gammatester]

Zitat:

Zitat von OLDIE1950 (Beitrag 1399820)

In Delphi konvertiert Trunc eine Gleitkommazahl in einen Integer-Wert.
X ist ein Ausdruck des Typs Real.

Das erklärt das Problem nicht! Das Wesentliche ist, daß X extended ist bei trunc(a*100).

[hhcm]

Ok, das hab ich soweit verstanden.
Trotzdem stehe ich jetzt noch dümmer da als vorher :)
Heute ist einfach nicht mein Tag.

Ich möchte eigentlich nur einen Eurowert in Cent umrechnen und das möglichst ohne Rundungsfehler :roll:
Tatsächlich wird mit 32Bit kompiliert.

[gammatester]

Dann rechne komplett 64-Bit-Integer oder mit Currency (<- dazu kann ich Dir aber nicht mehr sagen, siehe zB http://docwiki.embarcadero.com/Libra...ystem.Currency oder https://stackoverflow.com/questions/...ing-a-currency).

Oder wenn Du manuell wie oben mit 100 multiplizierst, sollte auch round statt trunc weiterhelfen.

[hhcm]

Ich bekomme durchgezogen durch die ganze Anwendung ein Double mit dem Wert.
Würde es denn unter gewissen umständen Probleme machen wenn ich den zweiten Weg einfach nutzen würde?

[Zacherl]

Zitat:

Zitat von hhcm (Beitrag 1399825)

Würde es denn unter gewissen umständen Probleme machen wenn ich den zweiten Weg einfach nutzen würde?

Ich behaupte, das ist sogar eher, was du willst (round). Statt abzuschneiden wird hier an den näheren Wert gerundet. Also praktisch kaufmännisches Runden, wie man es aus der Schule kennt

Delphi-Quellcode:

< 0.5 -> Abrunden

,

Delphi-Quellcode:

> 0.5 -> Aufrunden

.

[gammatester]

Zitat:

Zitat von hhcm (Beitrag 1399825)

Ich bekomme durchgezogen durch die ganze Anwendung ein Double mit dem Wert.
Würde es denn unter gewissen umständen Probleme machen wenn ich den zweiten Weg einfach nutzen würde?

Mit Deinem Code hast Du dann für andere Werte die Probleme, zB für a=1.13.

Mit round sollte es funktionieren.

[bcvs]

Zitat:

Zitat von hhcm (Beitrag 1399822)

Ich möchte eigentlich nur einen Eurowert in Cent umrechnen und das möglichst ohne Rundungsfehler

Dann nimm doch einfach Round statt Trunc. Dann sollte auch

Delphi-Quellcode:

Round(a*100)

funktionieren.

[KodeZwerg]

Vielleicht hilft Dir das weiter. Achtung! Keine Fehlerkontrolle!

Delphi-Quellcode:

function EuroToCt (const Euro: Single) : String;
begin
 Str(euro*100:8:2,Result);
end;

procedure TForm2.Button1Click(Sender: TObject);
begin
 Memo1.Lines.Add(EuroToCt(1.71));
end;

[gammatester]

Zitat:

Zitat von KodeZwerg (Beitrag 1399843)

Vielleicht hilft Dir das weiter. Achtung! Keine Fehlerkontrolle!

Delphi-Quellcode:

function EuroToCt (const Euro: Single) : String;
begin
 Str(euro*100:8:2,Result);
end;

Das ist doch nur reine Formatierung und hilft nicht, wenn mit c weiter gearbeitet werden soll.

[KodeZwerg]

Es sollte eine weitere Möglichkeit zu den bereits genannten Darstellen. Was man damit macht entscheidet jeder selbst, oder?

[hhcm]

Zitat:

Zitat von gammatester (Beitrag 1399832)

Mit Deinem Code hast Du dann für andere Werte die Probleme, zB für a=1.13.

:roll: Oh mann. Ja, das ist natürlich nicht gewünscht.

Zitat:

Mit round sollte es funktionieren.

Ich habe jetzt mit unterschiedlichsten Werten getestet.
Round scheint das mittel zur wahl.

[jziersch]

Zitat:

Zitat von hhcm (Beitrag 1399822)

Ich möchte eigentlich nur einen Eurowert in Cent umrechnen und das möglichst ohne Rundungsfehler :roll:

Wenn es Dir um korrekte ct Beträge geht solltest Du aber bedenken, dass Delphi nicht kaufmännisch rundet.

Hier ein Artikel dazu:
https://www.delphi-treff.de/tipps-tr...orrekt-runden/

[hhcm]

Ich habe zu 99% schon gerundete Beträge. Das Trunc bzw. Round ist nur zur Sicherheit.

[himitsu]

PS: EuroToCt -> Currency
ansonsten seid ihr an Rundungsfehlern selber Schuld

[Alallart]

@hhcm

Vielleicht noch mal klar ausgedrückt: 2 + 2 ist eigentlich 4. Wenn du aber mit Realen Zahlen in Delphi rechnest, kannst du nie sicher sein, dass das Ergebnis auch 4 wird. Die Nachkomma-Zahlen werden irgendwann gerundet, damit sie in die 8 Byte (oder was sonst) passen.

Wenn du den Effekt plastisch sehen willst, und Excel besitzt, kannst du ein kleines Experiment machen. Formatiere zuerst die Spalte A als Zahl (nicht Standard). Gib dann in die Zelle A1 den Wert

Code:

=Pi()

Gib dann in die Zelle A2 den Wert

Code:

=A1*1000

Kopiere dann durch ziehen die Zelle A2 an die 10 Zellen runter. Du wirst erleben, dass Computer standardmäßig keine unendlichen Zahlen kennen, obwohl Pi eine ist.

[gammatester]

Zitat:

Zitat von Alallart (Beitrag 1400014)

Vielleicht noch mal klar ausgedrückt: 2 + 2 ist eigentlich 4. Wenn du aber mit Realen Zahlen in Delphi rechnest, kannst du nie sicher sein, dass das Ergebnis auch 4 wird.

Das ist natürlich komplett falsch! Fließkomma-Addition, -Subtraktion und -Multiplikation von Werten mit frac()=0 ist 100% exakt, so lange die Operanden und das Ergebnis innerhalb gewisser Grenzen liegen,bei Single ist das 2^22=4194304, bei Double 2^52 = 4.50..E15 und Extended 2^63=9.22..E18.

Also ist 2+2 = 4 immer erfüllt.

Vernünftiges Arbeiten mit Fließkommazahlen ist kann schon trickreich genug sein, deshalb sollte so ein Unsinn (und vergleichbare Mythen) nicht noch verbreitet werden.

[Alallart]

@gammatester

Natürlich war das Beispiel mit

Code:

2 + 2 nicht immer 4

ein Scherz. Es sollte nur das Problem verdeutlichen. Außerdem gilt

Code:

2 + 2 = 4

als ein Synonym für eine unumstößliche Tatsache, sonst hätte ich 1 + 2 = 3 geschrieben. Du hast die Aussage nur nicht verstanden.

[gammatester]

Zitat:

Zitat von Alallart (Beitrag 1400014)

Vielleicht noch mal klar ausgedrückt: 2 + 2 ist eigentlich 4. Wenn du aber mit Realen Zahlen in Delphi rechnest, kannst du nie sicher sein, dass das Ergebnis auch 4 wird

Das mit dem eigentlich wird wohl jeder als Scherz verstehen. Der traurige Unsinn liegt im nächsten Satz, der wie gezeigt falsch ist. Dein Excelbeispiel ist genauso fehlerhaft, da dort ja nicht mit Pi gerechnet wird, sondern (wenn man Excel trauen darf) mit einer relativ guten Näherung.

Alle grundlegenden Fließkomma-Operationen sind korrekt gerundet, alle Fließkommazahlen sind exakt definiert, Division durch 2 ist exakt, die Differenz zweier Zahlen x,y mit x/2 <= y <=2x ist exakt (Sterbenz-Lemma), usw immer vorausgesetzt, daß das Ergebnis innerhalb des FP-Bereichs bleibt. Selbst die (mathematisch unstetigen) Funktionen trunc und round sind genau definiert.

Es bestreitet ja wohl niemand, daß durch Runden Fehler auftreten können, die sich bei nicht-stabilen Algorithmen verstärken können. Ein ganzer Teilbereich der Mathematik ist dieser Numerischen Mathematik (neu-deutsch Scientific Computing) gewidmet.

[Amateurprofi]

Zitat:

Zitat von Zacherl (Beitrag 1399830)

Zitat:

Zitat von hhcm (Beitrag 1399825)

Würde es denn unter gewissen umständen Probleme machen wenn ich den zweiten Weg einfach nutzen würde?

Ich behaupte, das ist sogar eher, was du willst (round). Statt abzuschneiden wird hier an den näheren Wert gerundet. Also praktisch kaufmännisches Runden, wie man es aus der Schule kennt

Delphi-Quellcode:

< 0.5 -> Abrunden

,

Delphi-Quellcode:

> 0.5 -> Aufrunden

.

Nee, Round rundet nicht kaufmännisch.

Kaufmännisch wäre
< 0.5 --> abrunden
>= 0.5 --> aufrunden

Round macht das so (bankers rounding)
< 0.5 --> abrunden
> 0.5 --> aufrunden
= 0.5 --> zur nächsten geraden Zahl runden

[Alallart]

Zitat:

Zitat von gammatester (Beitrag 1400032)

Dein Excelbeispiel ist genauso fehlerhaft, da dort ja nicht mit Pi gerechnet wird, sondern (wenn man Excel trauen darf) mit einer relativ guten Näherung.

Mein Excel-Beispiel ist richtig, auch wenn vielleicht die Rechnung sehr vereinfacht ist. Ich wollte nichts kompliziertes. Aber ich hab ein anderes Excel-Beispiel, einen Klassiker. Kennst du den Josephspfennig?

Die Geschichte geht so: stell dir vor Joseph, der Vater von Jesus, hat Jesus bei der Geburt eine Sparbuch bei einer Bank angelegt, und 1 Cent eingezahlt. Er hat damals 5% Zinsen vereinbart. Natürlich wurde nie Geld von dem Sparbuch abgehoben, so dass die Zinsen drauf blieben, und ein Teil des Vermögens auf dem Sparbuch wurden. Wie viel Geld ist heute, also 2018, auf dem Sparbuch?

Hier die Excel-Lösung:

Formatiere die Spalte B als Währung

Gib in Zelle A1 -> Jahr
Gib in Zelle B1 -> Summe

Gib in Zelle A2 -> 1
Gib in Zelle B2 -> 0,01

Gib in Zelle A3 -> 2
Gib in Zelle B3 -> =B2+(B2*5%)

Berechnet werden hier Zinsen mit den Zinseszinsen.

Ziehe nun die Zeilen runter bis du das Jahr 2018 erreichst. In der Summen-Spalte wirst du den Zinses-Zins-Wert, und der wird fast nur noch aus Nullen bestehen. Warum? Weil Excel, ähnlich wie Delphi auch, nicht hohe Zahlen, wie auch Nachkommastellen speichern kann.

[KodeZwerg]

Wen es Interessiert, was Delphi und Zahlen betrifft bei Float, der schaue bei About_Floating-Point_Arithmetic mal nach.

[gammatester]

Zitat:

Zitat von Alallart (Beitrag 1400044)

Zitat:

Zitat von gammatester (Beitrag 1400032)

Dein Excelbeispiel ist genauso fehlerhaft, da dort ja nicht mit Pi gerechnet wird, sondern (wenn man Excel trauen darf) mit einer relativ guten Näherung.

Mein Excel-Beispiel ist richtig, auch wenn vielleicht die Rechnung sehr vereinfacht ist. Ich wollte nichts kompliziertes. Aber ich hab ein anderes Excel-Beispiel, einen Klassiker. Kennst du den Josephspfennig?

Die Geschichte geht so: stell dir vor Joseph, der Vater von Jesus, hat Jesus bei der Geburt eine Sparbuch bei einer Bank angelegt, und 1 Cent eingezahlt. Er hat damals 5% Zinsen vereinbart. Natürlich wurde nie Geld von dem Sparbuch abgehoben, so dass die Zinsen drauf blieben, und ein Teil des Vermögens auf dem Sparbuch wurden. Wie viel Geld ist heute, also 2018, auf dem Sparbuch?

Hier die Excel-Lösung: [... blah blah]

Deine erste Excel-Lösung ist wie gesagt falsch und Deine zweite ist völlig falsch! (Es ist schon irgendwie symptomatisch, daß Du hier immer mit Excel argumentierst, vielleicht bist Du im falschen Forum?) Abgesehen von der pseudo-didaktischen Kindergeschichte, hast Du natürlich den völlig falschen Algorithmus gewählt.

Ich weiß zwar nicht, wie Banken das Problem genau behandeln (wenn zB nach einem Jahr auf den nächsten Cent gerundet wird, kommst Du nie von Deinem 1 Cent runter), aber nehmen wir an, Du willst a=0.01*(1+0.05)^2018 ausrechnen.

Die Rechnung mit Maple und 30 Stellen ergibt a = 5.75447255534412876764885218574e40. Selbst die relative ungenaue math.power-Routine liefert Dir 5.75447255534412801e40 mit einem relativen Fehler von 0.13e-15. Wenn Du AMath benutzt, erhältst Du 5.75447255534412878e40 mit einem 60-fach kleineren Fehler von 0.21e-17.

Das Problem ist also nicht die Fließkommarechnung, sondern das, was zwischen den Ohren ist.

[Amateurprofi]

Zitat:

Zitat von gammatester (Beitrag 1400054)

Zitat:

Zitat von Alallart (Beitrag 1400044)

Zitat:

Zitat von gammatester (Beitrag 1400032)

Dein Excelbeispiel ist genauso fehlerhaft, da dort ja nicht mit Pi gerechnet wird, sondern (wenn man Excel trauen darf) mit einer relativ guten Näherung.

Mein Excel-Beispiel ist richtig, auch wenn vielleicht die Rechnung sehr vereinfacht ist. Ich wollte nichts kompliziertes. Aber ich hab ein anderes Excel-Beispiel, einen Klassiker. Kennst du den Josephspfennig?

Die Geschichte geht so: stell dir vor Joseph, der Vater von Jesus, hat Jesus bei der Geburt eine Sparbuch bei einer Bank angelegt, und 1 Cent eingezahlt. Er hat damals 5% Zinsen vereinbart. Natürlich wurde nie Geld von dem Sparbuch abgehoben, so dass die Zinsen drauf blieben, und ein Teil des Vermögens auf dem Sparbuch wurden. Wie viel Geld ist heute, also 2018, auf dem Sparbuch?

Hier die Excel-Lösung: [... blah blah]

Deine erste Excel-Lösung ist wie gesagt falsch und Deine zweite ist völlig falsch! (Es ist schon irgendwie symptomatisch, daß Du hier immer mit Excel argumentierst, vielleicht bist Du im falschen Forum?) Abgesehen von der pseudo-didaktischen Kindergeschichte, hast Du natürlich den völlig falschen Algorithmus gewählt.

Ich weiß zwar nicht, wie Banken das Problem genau behandeln (wenn zB nach einem Jahr auf den nächsten Cent gerundet wird, kommst Du nie von Deinem 1 Cent runter), aber nehmen wir an, Du willst a=0.01*(1+0.05)^2018 ausrechnen.

Die Rechnung mit Maple und 30 Stellen ergibt a = 5.75447255534412876764885218574e40. Selbst die relative ungenaue math.power-Routine liefert Dir 5.75447255534412801e40 mit einem relativen Fehler von 0.13e-15. Wenn Du AMath benutzt, erhältst Du 5.75447255534412878e40 mit einem 60-fach kleineren Fehler von 0.21e-17.

Das Problem ist also nicht die Fließkommarechnung, sondern das, was zwischen den Ohren ist.

Hallo Gammatester:
Banken runden m.W. analog der Round-Funktion in Delphi (<0.5 --> abrunden, >0.5 --> aufrunden, =0.5 --> zur nächsten geraden Zahl runden).
Na klar bleibt von den Zinsen nach dem ersten Jahr nichts übrig, d.h. der Kontostand würde immer bei 1 Cent bleiben.
Zu den von dir gezeigten Ergebnissen von 0.01*(1+0.05)^2018
5.75447255534412876764885218574e40 Maple 29. (letzte) Stelle korrekt gerundet
5.75447255534412801e40 math.power, 16. Stelle falsch
5.75447255534412878e40 AMath 17. Stelle falsch
Genau: https://www.delphipraxis.net/134885-rechenprogramm.html

Code:

57544725553441287676488521857390212572917.8581289871900056863263866749390470682445466388192543716581
3791264388509806011194607299055615568247095709261438959969987853303090249863393890967034049436696648
4470056982611964241762183141559128773196204476992123036545219341489095474740988759777653826446932762
2108628818548513301095384743203155671753278505583073169090075499252542697208876565035975676590545885
8496077174373706494695600781474747664451818060352417378004382971135614401765338452439875680507150035
9368596952114022332636736921226969298701630767343398823003033150701187689626511602124552390051496805
2107975204109543474430485331870919737956387829176043987071190751977849704228795932278315703315744463
8631125238387187808330206608538726037301081415995528116814161912109213822486527893254951043739202653
2957514297187370022980093492894271067798728677022884195975749267431784072926206935830939576566694405
8617937363273714396281767744191902098912804646398100702694395085258728156645937294810568266314139786
3342608352904931917726869521328274394409234153052992118244659279456239816987627813672691673629900478
9785593430900393489591486219538739551215156776028382153063792864362049837459215274217616382785117690
1164720263607102314672828675090484759565254763416188290393285229225481036485880727579222754142111549
8449319217616991418421790834711500732970927494384559220791132696694870714123340148360175098990944059
6677872635566903082756021559511667245145743412617034242040731582562385776996847979967378072951274769
1691893139047930203766493384664571701658496476680289570499145249455333967689974263872912839316947499
2798298479389751962532260814609187356655660746834258978202568326396360097066541112082857999999434209
2799985145019174952944105067283941687546633862918360703697305717478371569835532778988805971647916718
7670376313477252156274761750472506507282940323421752542305029419855147073391201616164604752855501233
3358942206287530929457497133388436770961326902463463134166919157371725606875900184779419792938851442
2611973047385887982480549879877519966432457671492827271883245992931885442320458513780000949558844440
9994069187208056372543711781317984904741377239661464015467854337088525610142164963906346732107339987
7296686449077902418584187072572412085163066372849275784923326893294656002554969161958821776497613402
2056044467642775089205403885853325120945698240005252856454666978118732512792018076619250869122986266
2761681655040674982426128919064733227276729080831089036455037383167759117735304410328826660462308675
8184034626892247061206464376125823268598412796487787038403875387237735131838384228111070698022472869
3353789978468135052191121788435228712645083866230614347884322826432966534641972293826588386120289835
8493812082129044228055803829202718975713623082325637507984418885270082179358072418572859473820410783
4646242280879564485492377635671271638540682354133081918482639791948919406996852120804806905339419425
7413219187501404457171993600491400901150691615748324824190986962734365697878314561636424690156302307
1790409800398924084496789004204202150929008360798599576049918117317781918808504147308241183440889969
4251818036801510372607179626256579527718940033866164041876022339853333872120045905751751102803594637
7651867179414900108755204551532802046188111546317389406781316977429525771824512749445137597334189200
7125859789585948573515742822005202131230234096594304937749708888988319812399728076354315506969530615
9902321704594356779261066086192085628821261206912708977689956099492107741953266480013328709836820240
0001635050975581061135046672420511678587742225133556227503618542010717560854641298509970170001243617
6778851640271982788500123453040135731666664276591637767101408364728087962521198982074400260280243498
8554773057504900333524403291146242608245773293282941393624388306723580029740843370642577832930925288
7391929190921256874889885745216191310040156319540179720304640989851514978245736043593854722571768711
9623224605939376830131568753202372991162706244179928336115862515165584325848227684844822386611242771
82827656787512755714035699721820441899546028086120941225090064108371734619140625

[Alallart]

@gammatester

Vielen Dank für die Kindergeschichte ;) , da du aber mit einer Formel aus Wikipedia angekommen, seht man, dass du dich über die Kindergeschichte informiert hast. Nur hast du die Intention hinter dem Beispiel wohl nicht verstanden. Weder die "Kindergeschichte", die die Problematik mit Zins und Zinseszins beschreiben soll, noch um was es geht.

Hier geht es nicht darum mit a=0.01*(1+0.05)^2018 einen Wert auszurechnen, sondern zu zeigen, das 8 Byte sowohl den Zahlenbereich -2147483648..2147483647 als Integer, wie auch 5.0 x 10^-324 .. 1.7 x 10^308 als Real. Auch Excel rechnet nur mit einer begrenzten Anzahl Bits. Wenn man eine bestehende Zahl immer erhöht, dann wird man irgendwann auch den Rundungsfehler bemerken.

Und das ist das was du anscheinend bei dem kleinen Excel-Beispiel nicht verstanden hast, weil du mit einer Formel angekommen bist. Irgendwo wird abgeschnitten.

57544725553442900000000000000000000000000,00

[Daniel]

Klärt die persönlichen Differenzen per PN.
Darüber hinaus versucht einfach mal, die anderen Beitrage zu verstehen. Dass abgeschnitten wird, da Datentypen eine endliche Genauigkeit haben, habt Ihr beide bereits geschrieben.

[gammatester]

Zitat:

Zitat von Alallart (Beitrag 1400073)

da du aber mit einer Formel aus Wikipedia angekommen, seht man, dass du dich über die Kindergeschichte

Wenn ich dieses sprachliche Konstrukt dahingehend interpretiere, daß ich irgendwo bei Wiki eine Formel gefunden haben soll, liegst du falsch. Die 'Formel' über Zinseszins gehört mM zum mathematischen Allgemeinwissen.

Zitat:

Zitat von Alallart (Beitrag 1400073)

Hier geht es nicht darum mit a=0.01*(1+0.05)^2018 einen Wert auszurechnen, sondern zu zeigen, das 8 Byte sowohl den Zahlenbereich -2147483648..2147483647 als Integer, wie auch 5.0 x 10^-324 .. 1.7 x 10^308 als Real.

Schon wieder völlig falsch, 8-Byte-Integer haben eine Beeich von -2^63 = -9223372036854775808 ... 2^63-1= 9223372036854775807

Zitat:

Zitat von Alallart (Beitrag 1400073)

Auch Excel rechnet nur mit einer begrenzten Anzahl Bits. Wenn man eine bestehende Zahl immer erhöht, dann wird man irgendwann auch den Rundungsfehler bemerken.

Und schon wieder Excel plus Unsinn (wie erhöht man eine Zahl?)

Zitat:

Zitat von Alallart (Beitrag 1400073)

Und das ist das was du anscheinend bei dem kleinen Excel-Beispiel nicht verstanden hast

Und zu Abschluß noch einmal Excel.

Mir reicht diese Diskussion und ich werde keine weiteren Beiträge dazu liefern.

Schönes Wochenende

Edit: Sehe gerade Daniels Beitrag. @Alallart: bitte keine PN

[Alallart]

Wie kommst du drauf, dass ich dir je eine PN geschrieben hätte. Bitte keine Unterstellungen. So wichtig bist weder du, noch die Diskussion.

[Daniel]

Zitat:

Zitat von Alallart (Beitrag 1400078)

Wie kommst du drauf, dass ich dir je eine PN geschrieben hätte. Bitte keine Unterstellungen. So wichtig bist weder du, noch die Diskussion.

Was ist mir Dir los? Er schreibt, dass er keine PN von Dir haben möchte. Er trifft keine Aussage darüber, ob er bereits eine von Dir erhalten hat. Und irgendwie kann ich ihn verstehen ... und so wortreich, wie Du Dich hier einbringst, scheint Dir die Diskussion entgegen Deiner Aussage doch wichtig zu sein.

[Alallart]

Daniel, ich hätte nie eine PN an ihn geschickt. Warum auch? So wichtig ist das Ganze auch nicht. Seine Bitte an mich ihm keine PN zu schicken ist ähnlich dem, als wenn jemand ihn bitten würde keine fremden Kinder auf der Straße zu schlagen. Hatte er vermutlich nicht vor, es wird aber der Anschein erweckt das er es wollte.

[himitsu]

Zitat:

Und das ist das was du anscheinend bei dem kleinen Excel-Beispiel nicht verstanden hast, weil du mit einer Formel angekommen bist. Irgendwo wird abgeschnitten.

57544725553442900000000000000000000000000,00

Aus diesem Grund gibt es bei den Fließkommatypen auch die Angabe der Signifikanten Dezimalstellen.

Ja, einige Typen können locke Zahlen mit mehreren tausend Dezimalstellen vor und hinter dem Komma aufnehmen, aber egal wie groß der Wert ist, nur die "größten" X Dezimalstellen sind quasi "richtig" und alles nachfolgendes ist "nicht definiert", also "zufällig".

Problematisch wird es dann auch noch, wenn dann unterschiedlich große Zahlen miteinander verrechnet werden, wie z.B.
11111222223333344444555556666677777888889999,0 + 0,0000000000000000000000000000000000000001
Hier kann man 0,0000000000000000000000000000000000000001 so oft dazu rechnen, wie man will, aber das Ergebnis wird dennoch niemals größer werden.

Für sowas gibt es dann angepasste Bibliptheken, wenn man sowas unbedingt braucht.