Warum ist 3.219 kleiner 3.2?

gast wrote:
> ich würde sowas nicht so machen. Besser ist es die Differenz zu rechnen
> und dann auch > oder < 0 prüfen.

Kannst du das genauer ausfuehren? Das wuerde mich jetzt wirklich 
interessieren.

Thomas

Sven P. wrote:
> Fließkommazahlen sind ungenau

Würde ich so nicht sagen. Sie funktionieren anders als Integer, und wenn 
man sie wie Integer behandelt wird man auf die Nase fallen, aber sie 
sind nicht per se ungenau.

> deshalb soll man die nicht direkt vergleichen.

Das gilt nur für Gleichheit (==), nicht für größer/kleiner.

Andreas Schwarz wrote:

>> deshalb soll man die nicht direkt vergleichen.
>
> Das gilt nur für Gleichheit (==), nicht für größer/kleiner.

Selbst für Gleichheit gibt es Dinge, die garantiert funktionieren,
bspw. ein Vergleich auf eine exakte 0.  Eine solche entsteht u. a.
durch die (default-)Initialisierung der statischen und globalen
Variablen.  Es ist also durchaus sinnvoll und zulässig, eine globale
Variable pro Programmlauf ein einziges Mal setzen zu wollen
(natürlich auf einen Wert verschieden von 0 :), indem man schreibt:

1

   if (global_var == 0.0) {

2

      global_var = something_that_results_in_not_0();

3

   }

Sven P. wrote:
> Also nochmal die Gebetsmühle.
>> Fließkommazahlen sind schlicht und einfach wie eine Seuche.
>> [...]
>> Stichwort: Scaled Integer.

Damit bin ich einverstanden: ich kann mich nicht erinnern wenn ich das 
letzte mal floats verwendet habe. Ich verstehe dass man 
Fliesskommazahlen nicht mit == vergleichen soll, aber die Anleitung 
eines Posters, "a < b" durch ein "a - b < 0" zu ersetzen, scheint mir 
grober Unfug zu sein.

> Fließkommazahlen sind ungenau, deshalb soll man die nicht direkt
> vergleichen.

Damit bin ich nicht einverstanden, jedenfalls wenn die Vergleiche < oder 
> sind und man in Kauf nimmt, dass das auch <= und >= bedeuten kann.

Aber das (mittlerweile geloeste) Problem des OP, dass 3.219 < 3.2 
anscheinend wahr ist, sollte doch nicht auftreten, auch nicht mit den 
ungenauesten Fliesskommazahlen.

Thomas

Man kann "==" auch für Floats verwenden, wenn man weiß was man tut. Lua 
z.B. verwendet ausschließlich Float-Variablen auch für Ganzzahlen 
(http://lua-users.org/wiki/FloatingPoint).

Andreas Schwarz wrote:
> Man kann "==" auch für Floats verwenden, wenn man weiß was man tut.

Ich denke, genau das ist der springende Punkt:
Wenn man weiß, was man tut, ist das alles kein Problem.
Aber wenn man naiv in Floating Point herangeht (auch normale double sind 
da keine Ausnahme, die Probleme werden nur von der Größenordnung her 
kleiner), dann kann man sich da eine Menge Probleme einhandeln an denen 
man schier verzweifeln kann.

Ich empfehle jedem, das hier mal durchzuarbeiten:
http://www.physics.ohio-state.edu/~dws/grouplinks/floating_point_math.pdf

Auch, wenn man vieles daraus so nicht wieder braucht, so schärft es doch 
das Verständniss dessen, wo die Probleme liegen.

Sven P. wrote:
> Un-be-lehr-bar. Entweder willst du mich nicht verstehen, oder du hast
> das mit den Fließkommazahlen wirklich nicht verstanden. Keine der beiden
> Varianten möchte ich dir aber pauschal unterstellen.

Du bist aber auch ziemlich unbelehrbar.  Oder besser gesagt, du
bestehst partout darauf, dass nichts außer deiner Reinen Lehre
gelten darf.  Fließkommazahlen sind ein bequemes Mittel, um Zahlen
mit einem großen Dynamikbereich in für viele Fälle brauchbarer
Genauigkeit darstellen zu können, und sie sind noch dazu Bestandteil
des C-Standard-Sprachumfangs, was die Bequemlichkeit ihrer Nutzung
einfach mal drastisch erhöht.  Sie haben ihre Grenzen, keine Frage,
aber auch 16-bit-Integers haben ihre Grenzen, trotzdem werden sie
häufig genug (auch und gerade im Controller-Bereich) benutzt.

Deine gebetsmühlenartige Wiederholung, dass sie gar nicht nötig
wären, erinnert an die ebenso gebetsmühlenartige Konstatierung einiger
Programmierer, dass alles außer Assemblerprogrammierung gar nicht
nötig wäre.  Im Prinzip richtig, aber wie Karl schon schrieb: Zeit
ist Geld, und wenn ich mein Problem mit Standard-Bordmitteln des
C-Compilers hinreichend genau gelöst bekomme, fange ich nicht an,
umständlich in Assembler zu programmieren oder eben umständlich
mit irgendeiner Fixpoint-Arithmetik zu jonglieren.  Das mache ich
genau dann, wenn ich es brauche: Assembler, wenn es sich in C nicht
mehr sinnvoll ausdrücken lässt, Fixpoint, wenn mir Wertebereich und/
oder Genauigkeit von Fließkommazahlen nicht genügen.  Die Benutzung
von Nicht-Standard-Mitteln birgt in jedem Falle eine höhere Fehler-
wahrscheinlichkeit, weil einem der Compiler weniger Arbeit abnehmen
kann.  Damit wird nicht nur die Entwicklungszeit länger, sondern auch
der Wartungsaufwand höher.

Dass man neben den Möglichkeiten die Grenzen seiner Werkzeuge kennen
muss, steht natürlich außer Zweifel.  Das gilt aber genauso für die
Genauigkeit (oder eben nicht exakte Vergleichbarkeit) von Gleitkomma-
zahlen zu wie für die Tatsache, dass 65535 + 1 = 0 (statt 65536) ist,
wenn man mit einer vorzeichenlosen 16-bit-Ganzzahl arbeitet.  Wenn man
diese Grenzen nicht beachtet, erlebt man einfach mal sein blaues Wunder.

Ich kann Sven schon ein wenig verstehen. In der Schule, sogar im Studium 
haben wir bisher nie behandelt wann man Floats verwenden darf und kann. 
Bei Integern hingegen schon (Maximaler Zahlenraum 2^n-1 und sowas).
Es wird einfach weggelassen. Man sagt Float und Double sind für 
Gleitkommazahlen und fertig.

Bei meinem Cousin befand sich sogar eine Frage in einer 
Informatikklausur, wo nach einem optimalen Datentyp für Währungen 
gefragt war und da gab es dann auch nur Integer oder Float. Und Float 
war natürlich richtig, weil es ja eine Gleitkommazahl war... Autsch.

Karl wrote:
> Das ist allerdings echt heftig, da schlicht falsch. Gerade bei
> Finanzsoftware wird mit 100stel Cent "Integern", also fixedpoint,
> gerechnet.

Kommt natürlich auch drauf an.  Solange du in einer Währungseinheit
bleibst, ist ein um 100 (oder 1000) skalierter Integer sicher die
beste Wahl.  Wenn man aber zwischen verschiedenen Währungseinheiten
mit variablen Umrechnungsfaktoren arbeiten muss, sieht die Sache
schon wieder ganz anders aus...

Jörg Wunsch wrote:
...
> Fließkommazahlen sind ein bequemes Mittel, um Zahlen
> mit einem großen Dynamikbereich

Dynamikbereich ist ja fast das Gegenteil von Auflösung/Genauigkeit.

> in für viele Fälle brauchbarer
> Genauigkeit darstellen zu können, und sie sind noch dazu Bestandteil
> des C-Standard-Sprachumfangs,

Das sind viel, auch umstrittene Dinge.

> was die Bequemlichkeit ihrer Nutzung
> einfach mal drastisch erhöht.  Sie haben ihre Grenzen, keine Frage,

Die sind aber sehr komplex.

> aber auch 16-bit-Integers haben ihre Grenzen, trotzdem werden sie
> häufig genug (auch und gerade im Controller-Bereich) benutzt.

Integers haben einen großen Vorteil: Die Auflösung ist immer exakt 1. 
Der Dynamikbereich ergibt sich aus der Anzahl Bits.

> Deine gebetsmühlenartige Wiederholung, dass sie gar nicht nötig
> wären,

In der realen Welt halte ich Floats auch für unnötig. Am Ende ist der 
Input immer ein Integer. Auch die 1,234 µV gibt der ADC als Integer aus.

Am Ausgang sind auch wieder Integer. Eine PWM ist immer nur A/B, mit A 
und B als Integer, was Du in den DAC steckst, ist ein Integer...

> erinnert an die ebenso gebetsmühlenartige Konstatierung einiger
> Programmierer, dass alles außer Assemblerprogrammierung gar nicht
> nötig wäre.  Im Prinzip richtig, aber wie Karl schon schrieb: Zeit
> ist Geld, und wenn ich mein Problem mit Standard-Bordmitteln des
> C-Compilers hinreichend genau gelöst bekomme, fange ich nicht an,
> umständlich in Assembler zu programmieren oder eben umständlich
> mit irgendeiner Fixpoint-Arithmetik zu jonglieren.

Sobald Du schwer verständliche Effekte mit Floats hast, ist der 
Zeitvorteil aber schnell aufgefressen.

> Das mache ich
> genau dann, wenn ich es brauche: Assembler, wenn es sich in C nicht
> mehr sinnvoll ausdrücken lässt, Fixpoint, wenn mir Wertebereich und/
> oder Genauigkeit von Fließkommazahlen nicht genügen.  Die Benutzung
> von Nicht-Standard-Mitteln birgt in jedem Falle eine höhere Fehler-
> wahrscheinlichkeit, weil einem der Compiler weniger Arbeit abnehmen
> kann.  Damit wird nicht nur die Entwicklungszeit länger, sondern auch
> der Wartungsaufwand höher.

Je komplexer das eingesetzte Werkzeug ist, umso größer sind die 
Probleme, wenn das Werkzeug etwas anderes tut, als erwartet.

> Dass man neben den Möglichkeiten die Grenzen seiner Werkzeuge kennen
> muss, steht natürlich außer Zweifel.  Das gilt aber genauso für die
> Genauigkeit (oder eben nicht exakte Vergleichbarkeit) von Gleitkomma-
> zahlen zu wie für die Tatsache, dass 65535 + 1 = 0 (statt 65536) ist,
> wenn man mit einer vorzeichenlosen 16-bit-Ganzzahl arbeitet.  Wenn man
> diese Grenzen nicht beachtet, erlebt man einfach mal sein blaues Wunder.

Und ich behaupte, daß die Grenzen eines Integers leicht zu definieren 
sind, die eines Floats eben nicht.

Und deswegen kann ich mir keine sinnvolle Anwendung von Float 
vorstellen, die letzten Endes nicht sinnvoller mit Integers gelöst 
werden kann.

Aber ich freue mich über Gegenbeispiele.

73,
Falk

Man kann vieles mit Integern machen, was in ganz natürlicher Form erst 
einmal auf Fliesskommarechnung raus liefe. Nur wird das dann manchmal 
deutlich umständlicher.

So kann man Mondphasenanzeige, Sonnenaufgang und dergleichen sicherlich 
sogar mit BCD- oder ASCII-Arithmetik rechnen. Nur erschliesst sich mir 
nicht, warum man vorhandene Trigonometriefunktionen mit Gewalt umgehen 
sollte, bloss weil manche Vergleiche bei Fliesskommadarstellung 
problematisch sind - die man dafür garnicht benötigt.

Dass man wissen sollte was man tut ist unstrittig. Gilt aber ziemlich 
universell, denn mit Integer-Rechnung kann man aufgrund wesentlich 
wahrscheinlicheren Überlaufs genauso Schiffbruch erleiden. Eine 
Problematik die hier im Forum alle naselang aufkreuzt.

Wohlgemerkt: Ich will hier nicht der Fliesskommarechnung für einfache 
Temperaturumrechung und ADC-Skalierung das Wort reden. Ist da meist 
überflüssig. Bloss hat dieser Thread für mich irgendwie schon was 
Komisches:

Da hat jemand ein Problem und hat erkennbar Fliesskommarechnung 
verwendet, wobei weder Code noch Aufgabenstellung bekannt sind. Prompt 
stürzen sich manche Leute geradezu reflexhaft auf die 
Fliesskommarechnung, obwohl grösser/kleiner Relationen eher 
unproblematisch sind. Weshalb das natürlich auch nicht aufhört als sich 
herausstellt, dass es sich um einen simplen Tippfehler und ein stark 
irreführendes Posting handelte. Aber auf Prinzipien reitet es sich halt 
am besten.

A. K. wrote:

...

> Da hat jemand ein Problem und hat erkennbar Fliesskommarechnung
> verwendet, wobei weder Code noch Aufgabenstellung bekannt sind. Prompt
> stürzen sich manche Leute geradezu reflexhaft auf die
> Fliesskommarechnung, obwohl grösser/kleiner Relationen eher
> unproblematisch sind. Weshalb das natürlich auch nicht aufhört als sich
> herausstellt, dass es sich um einen simplen Tippfehler und ein stark
> irreführendes Posting handelte. Aber auf Prinzipien reitet es sich halt
> am besten.

Zur Aufheiterung die graphische Darstellung eines typischen 
Integer-Problems: http://xkcd.com/571/

Falk

> Aber auf Prinzipien reitet es sich halt am besten.

Da hast du schon recht.
Das Problem bei Floating Point ist, dass es kein "One size fits all" 
gibt. Man muss jeden Fall im Grunde neu betrachten und sich überlegen, 
was alles passieren kann. Oft (meistens) kommt man auch ohne eine 
derartige Analyse durch ohne dass irgendetwas Gröberes passiert. Aber 
dann gibt es auch noch die "harten Fälle", die einem den Schweiß auf die 
Stirn treiben können. Vor allem dann, wenn die Float Operationen sich 
über mehrere Berechnungen hinziehen.

Ich hab mal ein Beispiel gefunden. Es stammt aus "Geometric and Solid 
Modeling, Christoph Hoffmann" und zeigt, wie man je nachdem wie man 
rechnet (wobei beide Arten mathematisch völlig gleichwertig sind) zu 
völlig unterschiedlichen Ergebnissen kommen kann. Selbst wenn man ein 
Epsilon berücksichtigt!

<quote>
Consider implementing a test of whether two points in the plane are 
equal. Specifically assume that the point u is the intersection of the 
pair of lines (L1,L2), and that the point v is the intersection of the 
lines (L3,L4). The line equations are the input to the following 
algorithm:

1. Compute the coordinates of u.
2. By substituting into the line equations L3 and L4, conclude that
u == v if both L3(u) and L4(u) are smaller then some tolerance.

Intuitively, this algorithm ought to be equivalent to a second version 
in which the roles of u and v are reversed. Lets see if this is true.

(Hint: a1 denotes 'a' with a subcscript of 1)

1. The intersectoin (ux, uy) of the lines

1

   a1*x + b1*y + c1 = 0 

2

   a2*x + b2*y + c2 = 0

is computed as:

1

   D = a1*b2 - a2*b1 

2

   ux = (b1*c2 - b2*c1) / D 

3

   uy = (a2*c1 - a1*c2) / D

2. The point (ux,uy) is assumed to lie on the line

1

   a*x + b*y + c = 0

   if the distance is small; that is if

1

   |a * ux + b * uy + c| < eps * sqrt(a*a + b*b)

We assume eps to be 1E-10, a reasonable bound for double precision. We 
ask whether u and v are incident using 2 different methods:

a. Compute the coordinates of u
   conclude that u == v, iff u is on both L3 and L4.
b. Compute the coordinates of v
   conclude that u == v, iff v is on both L1 and L2.

The line coefficients follow. Since pow(2,-23) ~ 1E-7, they differ from 
1 and 0 by amounts that are several orders of magnitude larger then eps.

1

  L1: a1 = -1; b1 = 1; c1 = 0 

2

  L2: a2 = -(1+pow(2,-23)); b2 = 1-pow(2,-23); c2 = pow(2,-22) 

3

  L3: a3 = 1; b3 = 0; c3 = -(1+pow(2,-15)) 

4

  L4: a4 = 0; b4 = 1; c4 = -(1+pow(2,-15))

These coefficients can be represented exactly in double precision. The 
coordinates of the points are now computed to be

1

u = ( 1.0, 1.0 ) 

2

v = ( 1.000030517578125, 1.000030517578125)

They are both exact. Moreover since ai*ai + bi*bi is aproximately 
between
1 and 2, the evaluation of the line equations after substituting the 
point coordinates yields an error that can be compared directly with 
eps. We obtain the values

1

L3(u) ~ -3E-5        > eps 

2

L4(u) ~ -3E-5        > eps

from which we conclude that u connot be incident to v, since it is too 
far from the lines L3, L4 whose intersection is v.

But we also obtain

1

L1(v) = 0            < eps 

2

L2(v) ~ -7E-12       < eps

from which we must conclude that v is incident to u, since it lies 
extremely close to both lines.
Therefore, although they ask the same geometric question, the two 
computations yield contradictory results.

So what can one do about this.
Clearly: Don't use that algorithm. One could choose to do:

1. Compute the coordinates of u and v, by intersecting the respective 
lines.
2. If the euclidian distance between u and v is smaller then eps,
     decide u == v;
   otherwise
     decide u != v

(Note that this computation is more 'expensive' then the previous one. 
This time both points and an euclidian distance needs to be computed. In 
the previous algorithm only one point is computed and the testing does 
not involve a square root.)

This method is symetric, but it does not exhibit transitivity. 
Specifically, we choose 3 points u, v and w such that u is incident to 
v, v is incident to w, but u is not incident to w. We assume an eps of 
1E-10

1

u = ( 0, 0 ) v = ( 0, 0.8E-10) w = ( 0, 1.6E-10 )

Clearly the distance between the adjacent pairs is less then eps, but 
the distance between u and w is greater then eps. So what is the correct 
answer? Are all those points equal or are they not?
</quote>

Nach den ganzen Argumenten für Integer will ich auch noch mal ein 
Argument für Floats bringen:
Auf manchen Architekturen ist float-Arithmetik schneller als 
Integer-Artithmetik, z.B. bei der M32R-Familie von Renesas.

Wir sich wohl eher auf Multiplikation und Division beziehen. Da werden 
diese Integer-Operation auch schon mal auf dem Umweg über die 
Fliesskommaeinheit durchgeführt, weshalb das dann mehr Zeit braucht als 
die Fliesskomma-Operationen.

Das war beispielsweise auch bei Intels Prozessoren schon der Fall. 
Pentium: IMUL 10-11 Takte, FMUL 3 Takte. Wenn man FMUL und die 
Konvertierungen zusammenrechnet kommt man ungefähr bei IMUL raus.

@Gruenschnabel:
Beides braucht ein Takt.
A.K. hat recht, ich habe damit eigentlich Mul und Div gemeint:
imul: 3 Takte
fmul: 1 Takt
idiv: 37 Takte
fdiv: 14 Takte

Das liegt beim Multiplizieren einfach daran, dass er nur einen 16x32 
Multiplizierer hat und deswegen eine 32x32 Multiplikation aus 2x mul und 
1x add zusammensetzen muss.

Thomas wrote:
> Floatingpoint führt in aller Regel viel schneller, genauer, fehlerfreier
> und lesbarer zu Ergebnissen als Integer.

Darum ging es in der Diskussion doch gerade. FP ist nicht zwangsläufig 
genauer. Ein 32Bit-Integer bietet mehr Genauigkeit als 32Bit-Float, da 
letzterer nur 23Bit Mantisse hat.

Konkretes Beispiel: Ich musste den Durchschnitt aus einer Million Zahlen 
bilden, die einen Wertebereich von +-40 haben. Das kann man nicht ohne 
Trickserei (Zwischenergebnisse) mit 32Bit-Floats rechnen, aber sehr wohl 
mit 32Bit Integern. 64Bit-Floats durfte ich nicht verwenden.

> Der Hauptgrund, der trotzdem noch für Integer spricht sind die hohen
> Kosten für Controller mit FPU (nur bei hohen Stückzahlen ein Argument).
> Die meißten Fälle lassen sich heutzutage allerdings auch prima auf nem
> 8-Bitter ohne FPU in Double lösen...

Der avr-gcc kann kein double.

Markus Kaufmann wrote:
> Der avr-gcc kann kein double.
Kleine Ergänzung: Er kann mit dem Datentyp double arbeiten, allerdings 
ist sizeof(double) == sizeof(float) == 4, weshalb double keinerlei 
Vorteile bietet.

Nicht wirklich. Denn obzwar er "double" als Typ akzeptiert, ist das im 
Sinn des C Standards kein "double", weil zu wenig Stellen.

A. K. wrote:
> Nicht wirklich. Denn obzwar er "double" als Typ akzeptiert, ist das im
> Sinn des C Standards kein "double", weil zu wenig Stellen.
Richtig, er heißt nur double. Ist das falsch rübergekommen? Oder 
worauf bezog sich das "nicht wirklich"?

Ich verstehe auch nicht, warum ständig wieder die Diskussion Gleitkomma 
vs. Festkomma aufkommt. Das sind zwei Dinge, die man nicht gegeneinander 
stellen kann, da sie unterschiedliche Anwendungsbereiche haben. Klar, es 
gibt Systeme, die standardmäßig in Gleitkomma rechnen (wie das erwöhnte 
MATLAB), was aber i.d.R. daran liegt, dass der zugrunde liegende 
Prozessor eine FPU hat. Auf Embedded-Systemen, die keine FPU haben (und 
darum ging es ursprünglich), kann man die meisten Dinge sicherlich 
sinnvoll in Festkomma lösen. Aber auch Gleitkommazahlen haben dort ihre 
Daseinsberechtigung, wenn es darum geht, mit Zahlen zu jonglieren, deren 
Wertebereiche sich über mehrere Größenordnungen (d.h. Zehnerpotenzen) 
erstrecken. Dabei ist eine Mantisse-Exponent-Darstellung unschlagbar. 
Man sollte sie nur mit Bedacht eisetzen, aber sicher nicht verteufeln.

Klar, ich kann mir auch selber ein Gleitkommaformat zusammenstricken, 
aber es haben sich zu der Thematik schon viele Leute Gedanken gemacht, 
die Ahnung von der Materie haben und die das sicher effizienter 
hinbekommen...

Peter Stegemann wrote:

> Nach der ganzen Diskussion hier hat also jemand immer noch nicht
> verstanden, dass IEEE Fliesskommazahlen eben nicht genau und
> fehlerfrei sind.

Das steht dort aber auch gar nicht.

Thomas hatte den QA-Aspekt in den Vordergrund gerückt (wie ich weiter
oben auch schon), und solange man mit 23 bit tatsächlicher Genauigkeit
für den jeweiligen Zweck auskommt (bzw. den berühmten 6...7 Dezimal-
stellen), hat er damit gut Recht.

Bezüglich des Aufwandes an Maschinencode dürfte übrigens eine 64-bit-
Integer- oder -Festkomma-Implementierung oft größer ausfallen als
eine 32-bit-Gleitkomma-Implementierung (ist ja auch logisch, sie
bietet ja mehr Genauigkeit).

48 bit Gleitkomma wäre ein sinnvoller Kompromiss (und würde auch die
minimalen Genauigkeitsanforderungen für double gemäß C-Standard
erfüllen), aber da wir hier in einem GCC-Forum sind: GCC unterstützt
leider nur 16-bit-, 32-bit- und 64-bit-Datenformate (und ggf. noch
80 bit oder 128 bit für long long double).

Peter Stegemann wrote:

> Nun, was steht denn da?

Dass FP in der Regel viel schneller, genauer und lesbarer zu
Ergebnissen führt.

Es steht dort nicht, dass die Ergebnisse selbst genauer oder die
Rechnung schneller wären.

In vielen Fällen stört es einfach mal gar nicht, nur über eine
geringere Genauigkeit zu verfügen, weil die externe Verarbeitung
vielleicht sowieso nur eine Genauigkeit im Bereich von 1 % oder
so bietet.  Dann ist die Rechengenauigkeit der Gleitkommazahl
mehrere Größenordnungen besser und damit komplett ausreichend
für den Zweck.

>> Thomas hatte den QA-Aspekt in den Vordergrund gerückt
>
> Was ist der QA-Aspekt?

Quality Assurance, die Sicherheit, dass die ursprüngliche Intention
sich auch sauber im geschriebenen (und dann ausgeführten) Code
widerspiegelt.  Bei einer Standardmethode kannst du dich in dieser
Hinsicht erst einmal darauf verlassen, dass deine Werkzeuge ihr
Versprechen halten und eine Implementierung bieten, die in sich
schlüssig und korrekt ist (wobei die Implementierung ihre Grenzen
hat, die man kennen muss, darüber sind sich hier alle einig).

Wenn du eine Nichstandard-Methode nimmst wie Festkommazahlen, dann
musst du dich sowohl um die Qualität der Implementierung selbst als
auch der Umsetzung des Algorithmus kümmern.  Um die Grenzen der
Realisierung musst du dir (ganz genau wie bei Gleitkomma) ohnehin
Gedanken machen, ansonsten handelst du dir mit Über- oder Unterlauf-
Problemen ähnlichen Ärger ein, wie sie dir ein loss of precision
bei Gleitkomma bescheren kann.  In dieser Hinsicht ist die Methode
also keineswegs systembedingt besser.  (Höchstens dahingehend, dass
jemand bei so einer Methode vielleicht eher geneigt ist, diese
Betrachtungen von vornheren mit einzuplanen, während er es bei
Nutzung von Gleitkommazahlen u. U. vergessen könnte.)

Peter Stegemann wrote:

> Sorry, aber worauf soll sich denn die Genauigkeit und die Fehlerfreiheit
> beziehen, wenn nicht auf das Ergebnis?

Auf die Implementierung, das heißt auf die Umsetzung der Aufgabe in
den Code.  Das ist der Gegenstand von QA.

Peter Stegemann wrote:

> Thomas hatte auch nirgends QA oder Implementierungsprobleme
> erwaehnt, mir ist wirklich unklar, wieso du das so interpretierst.

Weil er es genau so geschrieben hat.

Du interpretierst es nur so (meiner Meinung nach falsch), dass es
wieder in dein Weltbild ("Gleitkomma ist böse") passt.

> Im Uebrigen gab es ja schon spektakulaere FPU-Fehler - wer QA ernst
> nimmt, muesste also auch das testen!

Du meinst den ollen Pentium-Bug vor X Jahren?

Als ob das der einzige jemals vorhanden gewesene CPU-Bug wäre...
Selbst, wenn man mal nur beim Intellismus bleibt, war der F00F-Bug
weitaus dramatischer.

Investmentbanker wrote:

> Nein, hat er nicht. Auch wenn ich genügend Bits habe um den Wertebereich
> abzudecken sind nicht alle Zahlen mit einem float darstellbar. Z.B. wird
> 0.1 nur als Näherung abgelegt und nicht exakt.

Es geht um mehr als nur Geld.  Dass dafür Gleitkommazahlen schlecht
brauchbar sind, war bereits diskutiert worden.  (Bei Wechselkursen
wird das schon anders, denn dort kommst du mit Festkomma u. U. in
das gleiche Dilemma, weil du vielleicht deinen einen Euro nicht mehr
exakt auf 4,41302862 Zloty abbilden kannst.)

Bei einem LC-Meter, das von 0,5 pF bis 100 µF alles messen können
soll, hast du aber mit Festkommadarstellungen ziemlich schlechte
Karten.  Dafür interessiert es dich dort überhaupt nicht, ob die
angezeigten 53.12 pF nun intern nur mit einem Rundungsfehler
dargestellt werden können oder nicht.

Jeder Aufgabe ihr Werkzeug.

(Was Thomas denn nun wirklich gemeint hat, kann er nur selbst
erklären.)

Oliver wrote:

> ...ausser daß das jezt genau DAS klassische Mikrocontrollerbeispiel ist,
> bei dem (je nach Meßprinzip) floats nicht gebraucht werden :-)

Naja, 2 * PI (für die Thomsonsche Schwingungsgleichung) lassen sich
mit keiner Computerzahlendarstellung exakt darstellen...  Zumindest
machen die floats hier das Leben deutlich einfacher.

Peter Stegemann wrote:

> Konvertiert wird immer ueber eine Referenzwaehrung
> und da hast du dann auf n Stellen festgelegte, exakte Kurse.

Dann ist natürlich klar, dass ein scaled integer die einzig brauchbare
Lösung ist.  Allerdings muss man den dann wohl dezimal skalieren, also
nicht im Sinne des  ISO/IEC TR 18037:

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1169.pdf

Jörg Wunsch wrote:
> Naja, 2 * PI (für die Thomsonsche Schwingungsgleichung) lassen sich
> mit keiner Computerzahlendarstellung exakt darstellen...  Zumindest
> machen die floats hier das Leben deutlich einfacher.

2*PI lässt sich aber mit gar keiner Darstellung exakt darstellen :-)

Gast wrote:
> Hatte mal eine map<float> verwendet ... Die ersten schreine
> wahrscheinlich schon *gg*
>
> Haufen Werte zugewiesen - der Key war dabei immer ein Winkel ...

floats als key in einer map klappt bestens wenn man mit upper_bound 
darin sucht.

Cheers, Roger

Simon K. wrote:
> Jörg Wunsch wrote:
>> Naja, 2 * PI (für die Thomsonsche Schwingungsgleichung) lassen sich
>> mit keiner Computerzahlendarstellung exakt darstellen...  Zumindest
>> machen die floats hier das Leben deutlich einfacher.
>
> 2*PI lässt sich aber mit gar keiner Darstellung exakt darstellen :-)

Hast Du doch gerade. In ASCII geht alles ;-)

Falk
P.S.: PI=3243F6A8885A308D3>>64

Peter Stegemann wrote:

> Diese Vergleicherei von Bittiefen ist ueberhaupt nicht zielfuehrend.
> Betrachte es am Beispiel von Finanzrechnung, die wir schon angesprochen
> haben. Du hast die Auflage mit einer bestimmten Anzahl von
> Dezimalstellen und festen Rundungsregeln zu rechnen. Die
> Integerimplementation kann die geforderten n Dezimalstellen exakt
> darstellen und auch die Beachtung der Rundungsregeln ist problemlos
> implementierbar. Die IEEE Fliesskommazahl kann nicht einmal 0.1 korrekt
> speichern, das fuehrt zwangsweise zu Rechenfehlern und die sind nicht
> gestattet, auch nicht im Sub-Cent-Bereich. Ganz schnell kracht es, wenn
> Zahlen aus anderen Darstellungen importiert werden. Schon kleinste
> Unterschiede in der Wandlung fuehren dazu, dass zwei Zahlen, die in der
> Ausgabe gleich aussehen, in der internen Darstellung nicht gleich und
> damit auch nicht vergleichbar sind.

Dafür gibt es für die Finanzwelt extra die IEEE 854, welche inzwischen 
Teil der IEEE 754r ist.

Damit ist auch 0.1 exakt darstellbar.

Johann

Und deshalb gibt es Rechnerarchitekturen, die Fliesskommaarithmetik auf 
Basis 10 in Hardware unterstützen.

Zum allgemeinen Interesse sei noch angemerkt, daß es neben den 
Darstellungen "Ganzzahl", "Gleitkommazahl", "Fixpunktzahl" noch andere 
Darstellungen nebst Arithmetik gibt, etwa mit folgenden Eigenschaften.

1) Erlaubte Eingaben sind ganze Zahlen
2) Erlaubte Operationen sind +, -, *, / und Quadratwurzel

Dann lässt sich für einen Werte a, der aus der Eingabe durch Anwendung 
der Operationen hervorgeht, exakt — also ohne Rundungsfehler — 
entscheiden, ob a = 0, a < 0 oder a > 0 gilt!

Wem die Niederungen des Börsenparketts oder der Ganzzahl-Arithmetik fern 
sind, kann ja dazu überwechseln ;-)

Johann