mikrocontroller.net

Forum: PC Hard- und Software FPU ungenau - warum?


Autor: Oliver Noll (batman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich schreibe morgen eine Klausur in Informatik 2. In diversen 
alten Klausuren ist gefragt warum es zu Rundungsfehlern bei der FPU 
kommt?
Das einzige was ich bisher herausgefunden hab, ist das bei Operationen 
Zwischenergebnisse größer sein können als wie sie abgespeichert werden 
könne und dadurch Ungenauigkeiten entstehen.

Doch ist das der Hauptgrund?

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Hauptprobem ist eher, dass Fliesskommazahlen, wie sie die FPU 
verarbeitet, nicht für genaue Berechnungen gedacht/ausgelegt sind.
Andersherum ausgedrückt: Sinn der FPU ist es nicht, exakte Werte zu 
berechnen, sondern eine Annäherung an das richtige Ergebnis zu liefern.
Es ist also eher ein Sonderfall, wenn kein Rundungsfehler auftritt.

=>http://de.wikipedia.org/wiki/Gleitkommazahl

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Oliver: Nein.

Rechne dezimal 1 dividiert duch 3 mit Darstellung des Ergebnisses in 
endlicher Stellenzahl. Hoffentlich fällt jetzt der Groschen.

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder mathematisch ausgedrückt:

Die Gleitkommazahlen, mit denen die FPU arbeitet, sind eine endliche 
Teilmenge der Reellen Zahlen, und bilden keinen Körper.
Beweis durch Gegenbeispiel:
Das multiplikativ Inverse von 3 ist nicht als Gleitkommazahl 
darstellbar.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder ganz einfach die Addition von Werten mit sehr unterschiedlicher 
Größenordnung. Wenn die Mantissengenauigkeit nicht ausrecht, dann fällt 
der kleine Operand einfach unter den Tisch.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rechne mal mit Excel

 0.05+(-0.07)+0.02+0

Also schreibe untereinander

0,05
-0,07
0,02
0

Dann Addieren


OpenOffice.org rechnet übrigens richtig.

Autor: Peter ##### (ich_eben)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hammer, ein grund mehr auf microsooft zu verzichten

Autor: Tilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicht ganz.

Bei Openoffice basiert die Rechnerei auf Java und ist schnarchlangsam. 
Ein Bekannter von mir hat ein paar komplexere Berechnungen in einer 
Excel-Tabelle gemacht. Excel war nach ein paar Sekunden fertig, OO hat 
er nach 30min abgeschossen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da wäre die Quintessenz also nun
  langsam und richtig <=> schnell und falsch ?

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast wrote:
> Rechne mal mit Excel
>
>  0.05+(-0.07)+0.02+0
>
> Also schreibe untereinander
>
> 0,05
> -0,07
> 0,02
> 0
>
> Dann Addieren
>
>
> OpenOffice.org rechnet übrigens richtig.

Solche Effekte bekommt man, wenn man binär rechnet: Dann gehts 
sauschnell, aber es führt zu solchen Effekten.

Wenn man stattddessen mit BCD-Darstellung rechnet, dann fallen die 
Rundungsfehler bei der Wandlung dezimal -> binär -> dezimal weg. Der 
Preis ist, daß es länger dauert.

Autor: anybody (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die X87 FPU hat intern mit 80 Bit gerechnet, wenn (Zwischen)Ergebnisse
im RAM gespeichert werden müssen werden diesen auf 64 Bit gekürzt.

Besonders eklig wenn durch leichte Änderungen im Code der Compiler
anders optimiert und dadurch Zwischenergenisse im RAM gespeichert werden
müssen, welche vorher in den internen Stack passten.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Blödsinn. OOo rechnet nicht mit Java. Es rechnet halt nicht mit 
Fließkommazahlen, was bei einer Tabellenkalkulation ja auch sinnvoll 
ist, auch wenns langsamer ist.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die Frage ist ob das mit dem Excel wirklich ein Problem ist, denn die 
abweichung von 1*10^-18 wird bei der ausgabe immer auf 0 gerundet. Und 
das bei viele werten wirklich mal eine Differenz rauskommt wo ist nicht 
egal ist dürfte an der Grenze von 65.000 Zeilen scheitern.

Aber wenn OO mit java rechnet mit dort nicht mit Flieskommazahlen 
gearbeitet wird wie stellt dann java 1/3 dar? Nimmt es sich dann den 
ganzen arbeitspeicher und merkt dann das es nicht geht? Ich genke die 
rechnen intern auch mit Double aber runden das Ergebniss damit dieser 
Fehler nicht sichtbar wird.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dezimal und binär wird mit Fest- oder Fliesskommarechnung aus 1/3 nie 
was, und eine korrekte Darstellung vom Ergebnis gibt es auch nicht.

Allerdings können abhängig von der Art der Rechnung, also ob dezimal 
ober binär, unterschiedliche Rundungseffekte auftreten, die bei 
kaufmännischer Rechnung eine Rolle spielen. Denn so wie 1/3 dezimal 
nicht endlich darstellbar ist, ist 1/10 binär nicht endlich darstellbar.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Effekt, den Gast hier 
Beitrag "Re: FPU ungenau - warum?" vorgeführt hat, hat 
mit der 1/3-Problematik nichts zu tun.

Das 1/3-Problem kann man mit Rational-Arithmetik in den Griff bekommen. 
Wenn aber reelle Zahlen ins Spiel kommen, dann bleibt nur symbolische 
Algebra und anschließend mit möglichst kleinen Fehlern zu wandeln.

Die gesamte Fehlerproblematik spielt aber in dem Gebiet, in dem Excel 
hauptsächlich eingesetzt wird, keine Rolle. Die Kaufleute runden eh 
immer auf 2, 3 Nachkommastellen und dort verschwinden die Fehler dann 
freundlicherweise...

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn bei einer Addition von Zahlen mit nur 2 Nachkommastellen schon 
Rundungsfehler auftreten, ist das für eine Tabellenkalkulation absolut 
inakzeptabel. Wie auch immer das Problem zu lösen ist, es muss zu lösen 
sein und wenn das bei einer Tabellenkalkulation nicht standardmäßig 
geht, ist die Tabellenkalkulation unbrauchbar. Mein Taschenrechner 
rechnet auch richtig.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dein Taschenrechner rundet einfach, oder rechnet in BCD. Intern haben 
die einfachen Dinger auch mehr Stellen als auf dem Display erscheinen, 
eben um Rechenfehler ausgleichen zu können.

Sag einfach er soll das Ergebnis auf 10 Stellen genau angeben, 
angefangen vor'm Komma. Wegen 10^-18 rumzudiskutieren ist Blödsinn.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver Noll wrote:
> Hallo, ich schreibe morgen eine Klausur in Informatik 2. In diversen
> alten Klausuren ist gefragt warum es zu Rundungsfehlern bei der FPU
> kommt?

Da der Exponent und die Mantnisse nur in einer begrenzten Genauigkeit 
gespeichert werden kann der darstellbare Zahlenbereich nicht beliebig 
fein aufgeloest werden, alleine daher kommt es zu Darstellungsfehlern. 
In anderen Faellen ist die B-adische Entwicklung einer eigentlich 
geraden Zahl im Zielsystem aber periodisch -- und lauter solche Scherze 
;) Es gibt bei diesen Zahlensystemen auch so etwas wie einen minimalen 
Abstand zwischen zwei darstellbaren Zahlen. Hast das in der Vorlesung 
nicht durchgenommen? Unwahrscheinlich sonst wuerde sowas doch nicht 
gefragt?

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast wrote:
> Also wenn bei einer Addition von Zahlen mit nur 2 Nachkommastellen schon
> Rundungsfehler auftreten, ist das für eine Tabellenkalkulation absolut
> inakzeptabel.

Aua, aua... Der Fehler ist 10^-18 -- die 2. Nachkommastelle ist 10^-2, 
es ist also noch massenhaft 'Luft' da, den Fehler durch eine simple 
Rundungsoperation zu beseitigen. Das macht man üblichereise dadurch, daß 
man bei Excel das Zahlformat auf 2, oder wieviel auch immer im Rahmen 
der Möglichkeiten, Nachkommastellen einstellt und der Käs ist 
gegessen...

Völlig inakzeptabel ist allerdings, wenn ein nicht-BWLer das nicht 
begreift. (Einem BWLer ist das sowieso wurscht.)

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Völlig inakzeptabel ist allerdings, wenn ein nicht-BWLer das nicht
> begreift. (Einem BWLer ist das sowieso wurscht.)

Ein BWLer muss nicht wissen, was Fließkommazahlen sind, der Anwender 
einer Tabellenkalkulation muss das auch nicht wissen. Die 
Tabellenkalkulation muss richtig rechen, darauf muss man sich verlassen 
können. Dem Anwender muss es egal sein, wie die Software intern die 
Zahlen darstellt und wie die Software gewisse Probleme umschifft. Es ist 
beängstigend, wie Microsofthörig viele schon sind und welches niedrige 
Qualitätsbewußtsein viele haben. Würde eine andere Tabellenkalkulation 
diese gravierende Fehler haben, würde alle wieder losschreien. Das 
angegebene Beispiel von Zahlen in diesem Wertebereich ist nun wirklich 
nicht realitätsfremd. Solche Konstellationen kommen in der Praxis oft 
vor. Da ist es dann schon wichtig, dass das Ergebnis stimmt. Das 
Beispiel mit anderen Programmen und mit dem Taschenrechner zeigt, dass 
es besser geht. Wie andere Programme und der Taschenrechner das intern 
rechnet, muss dem Anwender egal sein. Klar ist auch die Genauigkeit des 
Taschenrechners begrenzt und Rundungsfehler treten auch da auf, aber 
nicht bei solch einfachen Aufgaben mit so wenigen Nachkommastellen.

> Aua, aua... Der Fehler ist 10^-18 -- die 2. Nachkommastelle ist 10^-2,

Ich rechne im Dezimalsystem und da sind es in diesem Beispiel 2 
Nachkommastellen. Die interne Rechnung interessiert nicht.

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Es ist beängstigend, wie Microsofthörig viele schon sind und welches
>niedrige Qualitätsbewußtsein viele haben. Würde eine andere
>Tabellenkalkulation diese gravierende Fehler haben, würde alle wieder
>losschreien.

Ich hätte das eher genau andersrum gesagt! Einem OpenSource System wie 
Linux gesteht man eher mal einen Fehler zu, das geht im 
Microsoft-Hass-Rausch vollkommen unter.

>Das Beispiel mit anderen Programmen und mit dem Taschenrechner zeigt, dass
>es besser geht.

Bloß weil der Taschenrechner schon automatisch rundet wird der Fehler 
nicht besser.

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich rechne im Dezimalsystem und da sind es in diesem Beispiel 2
> Nachkommastellen. Die interne Rechnung interessiert nicht.

Rechnen im Dezimalsystem oder mit Dezimalbrüchen ist auch kein 
Allheilmittel. Spätestens bei Quadratwurzeln wird's immer ungenau, da 
müsste man schon symbolisch rechnen (Maple, Mathematica). Eine 
Abweichung um 10^-18 ist in der Praxis fast nie ein Thema. Man sollte 
aber als Computernutzer dennoch aufpassen, insbesondere bei einer 
Abfrage auf Null der Form

if (x==0)...

Wenn hier x eine Gleitkommavariable ist, spielt der Unterschied zwischen 
0 und 10^-18 sehr wohl eine Rolle.

Gruss
Mike

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wobei ich jetzt Linux nicht als Tabellenkalkulation bezeichne. Das 
sollte nur als ein Beispiel aus dem Open Source Lager herhalten, das 
auch nie vollkommen fehlerfrei ist. Es ist klar, dass vollkommene 
Fehlerfreiheit mit endlichen Mitteln praktisch nicht realisierbar ist, 
trotzdem finde ich, dass Microsoft in der öffemtlichen Wahrnehmung 
diesem Anspruch trotzdem genügen muss. Bei Open Source ist das häufig 
anders.

Autor: ööööööö (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Rechnen im Dezimalsystem oder mit Dezimalbrüchen ist auch kein
> Allheilmittel. Spätestens bei Quadratwurzeln wird's immer ungenau

Ja natürlich kann man immer irgendwelche Fälle herbeireden. Gleich kommt 
jetzt noch einer mit Winkelfunktionen. Wenn aber bei einer 
Tabellenkalkulation eine einfache Addition mit wenigen Nachkommastellen 
zum Problem wird, dann ist die zugehörige Software unbrauchbar. Da gibt 
es überhaupt keine Entschuldigung! Da hat der Programmierer versagt. Der 
Programmierer müßte nämlich wissen, was Fließkommadarstellung ist.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier war doch nicht die Rede von Taschenrechnern, hallo? Die rechnen 
nochmal wesentlich ungenauer und auch nicht nach IEE754.

Hier nachlesen:
http://de.wikipedia.org/wiki/IEEE_754

Und so nen Kaese mit der Tabellenkalkulation ist auch Dummfug. "Korrekt" 
heisst hier eben nicht "exakt". Wer den Unterschied nicht versteht ist 
schlicht und ergreifend als Anwender unfaehig.

Autor: Skua (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@mike
>if (x==0)...
>Wenn hier x eine Gleitkommavariable ist, spielt der Unterschied zwischen
>0 und 10^-18 sehr wohl eine Rolle.

Richtig wäre sowieso
if (x<epsilon)...

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gast

Nochmal zum mitmeißeln: Alle rechnen falsch. Egal ob Taschenrechner, 
Tabellenkalkulation oder FPU. Die Frage ist nur, ob sie dir den Fehler 
auch anzeigen oder die Ausgabe schönen.

(a-b)^2 ist bekanntlich a^2-2ab+b^2. Nun setze mal Werte wie 1'000'001 
und 1'000'000 ein, früher oder später kommt bei a^2-2ab+b^2 das falsche 
Ergebnis raus.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
x==0 ist problematisch, x<epsilon ist falsch (wenn schon bitte 
fabs(x)<espilon, ist aber genauso falsch).

Epsilon bezieht sich auf die relative Genauigkeit. Bei 1-1 passt das, 
bei 1e-90 - 1e-90 passt es dagegen nicht mehr, da müsste man auf 
fabs(x)<epsilon*1e-90 testen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gero A. wrote:

> Und dass das Ergebnis eines Vergleichs den Wert "problematisch" haben
> kann, ist mir auch neu.

Doch, das geht, gewissermassen ;-). Heisst allerdings offiziell 
"unordered".

Autor: blabla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Alle rechnen falsch. Egal ob Taschenrechner,
> Tabellenkalkulation oder FPU. Die Frage ist nur, ob sie dir den Fehler
> auch anzeigen oder die Ausgabe schönen.

Entscheident ist doch das, was als Ergebnis rauskommt!!!!
Wer es als Programmierer einer Tabellenkalkulation nicht schafft, das 
Ergebnis einer einfachen Addition richtig auszugeben, ist ein Versager. 
Ob er das dadurch schafft, dass er intern mit 1000facher Genauigkeit 
rechnet,  oder indem er gar keine Fließkommaarithmetik verwendet (das 
ist wohl am sinnvollsten) oder ob er geschickt rundet sodass der Fehler 
im Endergebnis nicht auffällt, das ist doch für den Anwender sowas von 
schnurz piep egal! Dass es besser geht als es Excel macht, sieht man ja. 
Dass in speziellen Fällen, die von den Trollen hier angeführt wurden, 
trotzdem Rundungsfehler entstehen, ist zwar nicht schön, ist aber besser 
als der Murks von Excel.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Umgekehrt: Der Anwender, der nicht sieht, dass 1e-18 praktisch 0 ist, 
ist zu doof um mit einer Tabellenkalkulation zu arbeiten.



@gero

x<epsilon ist grundsätzlich falsch. Du hast nämlich nicht verstanden 
woher das epsilon überhaupt kommt, bitte informier dich mal ein bisschen 
über Numerik, und wenn du damit fertig bist überlegst du mal, ob das 
epsilon von der Mantisse oder dem Exponenten abhängt.

Deine Reaktion auf "problematisch" zeigt aber, dass du sowieso keine 
Argumente hast.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da der Beitrag grad verschwunden ist nochmal allgemein zur Klarstellung:

http://de.wikipedia.org/wiki/Fehlerschranke

> Eine Fehlerschranke wird mit dem griechischen Buchstaben ε (Epsilon)
> angegeben und definiert eine vereinbarte oder garantierte, zugelassene
> äußerste Abweichung von einem Sollwert.


Ich ging davon aus, dass dieses Epsilon gemeint ist, damit lässt sich 
der Vergleich auf 0 präziser gestalten (x<epsilon ist trotzdem falsch). 
Ganz allgemein epsilon>0 reicht für den Vergleich auf 0 nämlich nicht 
aus.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit der Fehlerschranke bringt Dir nur auch nicht recht viel... naja 
man sollte, wenn moeglich, Gleitkommazahlen sowieso vermeiden ;) Und in 
den meisten Faellen kann man das auch.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorsicht, du bist hier in einem PC Unterforum ;). Gleitkomma ist gut und 
bringt viel, wenn man damit umgehen kann. Auch auf einem 
Mikrokontroller.

Die wichtigste Neuerung der letzten Jahre im Bereich PC CPUs war, dass 
sich ein SIMD Standard für Gleitkommaberechnungen durchgesetzt hat 
(SSE/SSE2). Dadurch ist die Rechenleistung auch in vielen praktischen 
Bereichen um Faktor 2 gestiegen.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I_ H. wrote:
> Vorsicht, du bist hier in einem PC Unterforum ;). Gleitkomma ist gut und
> bringt viel, wenn man damit umgehen kann. Auch auf einem
> Mikrokontroller.

Das ist mir durchaus bewusst.

Autor: Maik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Umgekehrt: Der Anwender, der nicht sieht, dass 1e-18 praktisch 0 ist,
> ist zu doof um mit einer Tabellenkalkulation zu arbeiten.

Nein du Troll. Dem Anwender hat es nicht zu interessieren, wie die 
Zahlen intern dargestellt werden.  Wenn bei solchen Rechenaufgaben 
Rundungsfehler bei der Ausgabe des Ergebnisses entstehen, so ist die 
interne Genauigkeit zu gering, oder man sollte bei bestimmten 
Aufgabenstellungen ganz auf Floatingpoint verzichten. Mit anderen 
Worten: Der Programmierer ist eine Niete. Bei anderen Anwendungen ist 
eine geringe Ungenauigkeit akzeptabel (z.B. Simulation von 
physikalischen Vorgängen), aber nicht wenn ich beispielsweise die Preise 
einiger Posten in einer Tabelle addiere, was eine häufige Anwendung für 
eine Tabellenkalkulation ist, und hinterher ein Rundungsfehler auftritt. 
Die Trolle hier sollten mal in die Grundschule gehen und das 
"Plusrechnen" lernen. Dort gibt es bei der Addition keine 
Rundungsfehler, auch nicht bei "Kommazahlen". Wer als Programmierer 
einfach überall unüberlegt die standardmäßig vorgefertigten 
Floatingpoint-Libs verwendet, ist ein Nichtskönner.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ist wohl jemand als Gast zurückgekehrt.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte wirklich nicht in der Haut eines Programmierers für
Tabellenkalkulationsprogramme stecken. Wie er es auch anstellt, er macht
es immer komplett falsch:

- Verwendet er die FPU für Berechnungen, kommen die Kaufleute und Bänker
  und schreien: "Igitt, da kommt jar gar nicht 0 heraus." Und im
  konkreten Fall: "Was bedeutet überhaupt dieses 'E' mitten in der Zahl?
  Sind das die Euros? Und das '-' nach dem 'E'? Hat da das Programm etwa
  gar nicht zu Ende gerechnet?"

- Lässt er alles in BCD rechnen, kommen die Wissenschaftler und
  Techniker und jammern: "Bäh, das Programm ist ja a****lahm. Mein PC
  hat doch eine FPU, warum wird die nicht genutzt?" Und spätestens bei
  der ersten Division oder längeren Multiplikation in Verbindung mit
  Additionen und Subtraktionen beginnt auch das Gezeter der Kaufleute
  und Bänker aufs Neue.

- Benutzt er rationale Arithmetik mit automatisch angepasster
  Genauigkeit, sind die Kaufleute und Bänker erst einmal ruhig, die
  Wissenschaftler und Techniker schmeißen das Programm jetzt aber
  endgültig weg.

- Implementiert der Programmierer hingegen alle drei Varianten und
  überlässt die Auswahl dem Benutzer, ist die Verwirrung zu 100% perfekt
  (sofern überhaupt jemand den Menüpunkt zur Umschaltung des
  Zahlenformats findet). Und alle, die Kaufleute, Bänker,
  Wissenschaftler und Techniker beklagen sich zudem, dass die neue
  Programmversion schon wieder mehr Speicher frisst.

Das mit dem Umschalten von Formaten klappt ja jetzt schon nicht,
zumindest, was die Ausgabeformate betrifft: Würden die Kaufleute und
Bänker für diejenigen Felder, die mit Geld zu tun haben, das Format
"Währung" und für die Zinssätze das Format "Prozent" wählen, die beide
defaultmäßig auf 2 Nachkommastellen runden, wäre der ganze Spuk vorbei
und jeder glücklich.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.