Hi Claudio,
Claudio Wilmanns schrieb:
Hallo Klaus, Herr Spangenberg, et. al.,
habt ihr bei euren Untersuchungen berücksichtigt, dass die Programme
intern möglicherweise mit Daten unterschiedlichen Typs (float, double
oder long double) arbeiten?
Ich bin einfach von den DataSets (in denen ganzzahlige, dezimale
Prozentwerte definiert sind) und den zugehörigen TIFs (8Bit)
ausgegangen. Interne Repräsentationen interessieren mich dabei zunächst
nicht -- mir ist nur wichtig zu wissen, was am Ende herauskommt bzw.
herauskommen sollte. Und das ist offensichtlich nicht ganz eindeutig.
[...]
Ihr geht außerdem (stillschweigend) davon aus, dass die Werte mit 8
Bit/Kanal berechnet wurden. Vielleicht wurden aber auch 16 Bit/Kanal
oder gar 32 Bit/Kanal verwendet und am Ende wird noch einmal auf 8 Bit
heruntergerechnet.
Schon klar, dass bei Mehrfach-Rundung bzw. -Konvertierung selbst mit
Fließkommazahlen Abweichungen auftreten können. Gerade deshalb ist es
wichtig,
a) das Ziel eindeutig zu definieren
b) dafür zu sorgen, dass diese Definition praxisgerecht ist und im
Alltag zumindest keine /systematischen/ Fehler produziert.
Es existiert übrigens ein ANSI/IEEE Standard 754 zur Umrechnung von
Dezimalzahlen in Gleitkommazahlen (inklusive Rundungsvorschirifen).
Vielleicht lohnt sich ein Blick in dieses Dokument zu werfen. Ein
Auszug, dessen Richtigkeit ich nicht zu beurteilen vermag, findet sich
in Wikipedia:
<http://de.wikipedia.org/wiki/IEEE_754>
Danke für den Hinweis.
Interessant finde ich vor allem den Satz zu binären Rundungen:
"Bei binären Rundungen muss zur nächstgelegenen darstellbaren Zahl
gerundet werden. Wenn diese nicht eindeutig definiert ist (genau in der
Mitte zwischen zwei darstellbaren Zahlen) muss gemäß dem Vorschlag von
Carl Friedrich Gauß in Richtung zur nächstgelegenen geraden Zahl
gerundet werden."
Diese Situation kann in unserem Fall genau 4 mal auftreten. Wenn wir
davon ausgehen, dass sich alle beteiligten Fließkommazahlen in der
FP-Repräsentation exakt codieren lassen, ist das Ergebnis eindeutig:
% Stufe toEven Ergebnis
---------------------------------
10 25,5 26 10,20
30 76,5 76 29,80
50 127,5 128 50,20
70 178,5 178 69,80
90 229,5 230 90,20
Der Faktor 2,55 lässt sich aber nicht exakt als Float darstellen -- die
Konsequenzen sieht man z.B. schön in R:
round(c(10,30,50,70,90)*255/100)
[1] 26 76 128
178 230
round(c(10,30,50,70,90)*2.55)
[1] 26 76 127
178 229
90*2.55 - 90*255/100
[1] -2.842171e-14
Auf Lange Sicht wird man als Anwender mit diesem
Problem leben müssen,
zumindest, wenn man unterschiedliche Betriebssysteme, Software oder
sogar verschiedene Versionen derselben Software verwendet. Zumal von
einer Vielzahl an existierenden Daten nicht mehr unbedingt gesagt
werden kann mit welchem Programm und auf welchem System sie erzeugt
wurden. Wenn es aber neue Erkenntnisse gibt, so haltet uns bitte auf
dem Laufenden.
... solange es aber keine unmissverständliche Regelung gibt, wird sich
an der Situation auch in Zukunft nichts ändern :-(
Das ganze Problem ließe sich sehr einfach umgehen, indem bereits in den
Tabellen auf 8 bit gerundete Werte mit ein oder zwei Nachkommastellen
angegeben würden (also z.B. 69,80 statt 70%)
Klaus Karcher