Versteh die Welt gerade nicht... Wo kommen die Rundungsfehler her???

[Crazy X]

Egal ob mit FDT oder in Flash
Egal ob Flash Player 10 oder 11

var sprite : Sprite;
			
sprite = new Sprite();
sprite.graphics.beginFill(0xffffff);
sprite.graphics.drawRect(0, 0, 50,50);
sprite.graphics.endFill();
sprite.alpha = 0.8;

trace('shape.alpha: ' + (sprite.alpha));

gibt
shape.alpha: 0.796875

Kann mir das jetzt mal einer erklären? Warum kann Flash bei mir nichrt mehr rechnen (Mein Preloader geht jetzt auch irendwie nicht ... sagt 0.99999999999)

Sowhat von strange! :-)

Gruß
Crazy X

[shin10]

Zum einen gibt es bei int und floats immer Rundungsprobleme - das hat aber nichts mit Flash zu tun. Rundungsfehler??

Du wunderst dich jetzt vermutlich, warum das passiert, obwohl du nicht damit rechnest.
Das liegt daran, dass der Alphawert mit 0 bis 1 angegeben wird, aber für die Dartstellung tatsächlich ja einen Wert von 0 bis 255 verwendet wird.
Edit: Das liegt daran, dass der Alphawert -128 <= alpha < 128 als 8.8-Bit fixed point Wert gespeichert wird. (8 Bit für die Ganzzahl vor dem Komma, 8 Bit für die Nachkommastelle; so spart man sich 48 Bit im Vergleich zur Number (IEEE-754 double-precision floating-point number mit 64 Bit), welche ausgelesen wird)

0.8*256 = 204,8

-> verwendet wird aber nicht Number sondern Int, sprich auf 204 abgerundet
beim Auslesen passiert also folgendes:

204/256 = 0,796875

mfg

sx

Edit: warum nicht durch 255 geteilt wird? kp

[Martin Kraft]

Zitat von shin10

Edit: warum nicht durch 255 geteilt wird? kp

Weil 8bit nunmal 256 Werte sind und nicht 255:
8 Bit = 1 Byte = 2^8 = 256 = 0 bis 255

[shin10]

Ja schon - vielleicht hab ich gerade nen Hänger, aber ich hätte da mit 0xFF gerechnet. weil ich bei 1 * 256 = 256 also 0x100 rausbekomme und nicht 0xFF wie gewünscht.
Im Umkehrschluss würde ich also auch bei 0xFF/0x100 nur 0.99609375 statt 1 herausbekommen.
Bin aber auch gerade etwas müde - weiß zumindest nicht, warum ich mich daran aufhäng.

Häng doch das Offensichtliche einfach nochmal für mich ran.

[Martin Kraft]

Du darfst nicht vergessen, die 0 mit zu zählen!

Zahlen und Zahlensysteme sind eben 0 indiziert – genauso wie z.B. Arrays. Da ist ja auch array[ array.length-1 ] der größte mögliche Index und array[ array.length ] nicht definiert.

Analog dazu hat z.B. das Dezimalsystem an jeder Stelle ja auch 10 mögliche Werte (0, 1, 2, 3, 4, 5, 6, 7, 8, 9) und das Binärsytem 2 (0 und 1). Die namensgebende Zahl ist also nie als einzelnes Zeichen im System abbildbar sondern entspricht dem Wert 1 in der nächst höheren Stelle.

[shin10]

Hmm - also die 0 hab ich nicht vergessen. Dafür bin ich dann doch zu lang dabei. Für mich steht alpha=1 einfach für 100%. Und 100% von 0xFF sind 0xFF. Also weißt schon was ich mein, oder?

[speedjunkie]

Hallo Martin, hallo Shine,

es stimmt, was Martin sagt.

Die meiste Computerhardware und die meisten Computersprachen bilden Näherungswerte von reellen Zahlen mit Hilfe der Fließkommadarstellung IEEE 754. Aus Gründen der Hardware-Effiziens sind die meisten Fließkommadarstellungen Binärdarstellung. Binäre Fließkommadarstellungen können einfachen Zahlen wie 0.1 nicht exakt darstellen. Das ist nicht Actionscript spezifisch.

trace(0.4 - 0.3 == 0.1); // false 
 

[Martin Kraft]

Im Endeffekt geht's doch hier um ein ganz simples Rundungsproblem:

Rundung auf 2 Nachkommastellen im Dezimalsystem:

Math.round( 100 * 0.8 ) / 100 = 0.8

Rundung auf 2 Nachkommastellen im Hexadezimalsystem:

Math.round( 0x100 * 0.8 ) / 0x100 = 0.796875

Zitat von shin10

Für mich steht alpha=1 einfach für 100%. Und 100% von 0xFF sind 0xFF. Also weißt schon was ich mein, oder?

Auch wenn diese Analogie nicht ganz so glücklich ist: Es sind nicht 100% von 0xFF sondern 100% von 0x100. 100 ist eben nicht 99!

[shin10]

Der Alphakanal gibt maximal 0xFF her, damit sind das für mich die 100%. Mit alpha hat eine Farbe 32 Bit - wenn das Maximum 0x100 sein sollten wären weir bei 33 Bit. So viel haben wir aber doch nicht.

Und jetzt pass auf, ich hab mal folgendes gemacht:

PHP-Code:

var val = 0;
var alphaIs = [];

while(val<=1){
    alpha= val+=0.001;
    if(alphaIs[alphaIs.length-1]!=alpha){
        alphaIs.push(alpha);
    }
}
trace(alphaIs.length);//257 


Willst du mir wirklich sagen, dass sich das nicht beißt?
Ich glaub da hat der Praktikant die LUT versaut.

[Martin Kraft]

Ach Du redest von einem Bitmap-Alpha-Kanal?! Das ist etwas ganz anderes als das Alpha in der Displaylist. Hier geht darum möglichst viele werte in möglichst wenig Stellen speichern. Und in 2 hexadezimale oder 8 binäre Stellen passen nun einmal genau 256 Werte.

Da macht es keinen Sinn aus quasi ästhetischen Gründen ein ganzes Bit (-1) zu verschenken, nur um auf eine runde Zahl zu kommen. Das ist so, als ob man dezimal nur die Zahlen von 0 bis 99 nehmen dürfte. Das sind genau 100 Werte. Will man aber die 100 dabei haben, braucht man 101 und eine ganze Stelle mehr (mit der man dann auch noch die Zahlen bis 999 bezeichnen könnte). Die dezimalen 101 entsprichen also den 257 im binär System.

[shin10]

Zitat von Martin Kraft

Ach Du redest von einem Bitmap-Alpha-Kanal?

Ja, auch. Ich wär davon ausgegangen, dass das nahezu einerlei ist/sein sollte. Bei Grafikkarten kann flash im Grunde ja auch maximal von 0xFF je Kanal ausgehen. Es scheint mir keinen Sinn zu machen, das in der DisplayList jetzt mit 0x100 anzugehen, wenn es dann doch zur letztendlichen Ausgabe wieder auf 0xFF umgerechnet werden muss.

Auch in der Referenz; sieht man sich da mal die Formeln für die ganzen blendModes an, stellt man fest es wird immer mit 0xFF gerechnet.

Ich finde es jedenfalls ziemlich seltsam.

[Martin Kraft]

Die alpha-Werte in der Displaylist werden ja nicht direkt dargestellt, sondern sind Multiplikatoren für die zugehörigen Farbwerte. Von daher macht da der Datentyp Number (also 0x1.00) im Gegensatz zu int (also 0xFF) bei den Farbkanälen durchaus Sinn.

[shin10]

Jap, hast Recht. Ich hab das hier gerade gefunden.

Multiplication transforms multiply the red, green, blue, and alpha components by an
8.8 fixed-point value. The fixed-point representation of 1.0 is 0x100 or 256 decimal.
Therefore, the result of a multiplication operation should be divided by 256.

Das betrifft den swf specs nach CXFORM und CXFORMWITHALPH. Bei allem anderen bleibt's bei 255 ... Puh! Jetzt kann ich endlich wieder schlafen.

[Crazy X]

wow
Danke für diese aufschlussreiche Diskussion. Ich glaube für mich kamen einfach mehrere Sachen auf einmal zusammen, so das ich erst mal etwas verwirrt war und auch als eher perfektionistischen/sauberen Programmierer nicht so ganz mit Leben wollte

- Zum einen hatte ich nie Probleme mit meinem selbstgemachten und oft benutzten einjährigen Preloader
- zum Anderen ist mir - was ich ja noch viel krasser finde - das mit dem alpha-"Rundungsfehler" noch nie in meinen mittlerweile über 10jähriger Flash-Karriere wirklich aufgefallen.

Echt super interessant... jetzt kann ich wieder beruhigt weiterhin sauber Programmieren
Danke!

Gruß
Crazy X

für die Nachwelt dann nochmal kurz ein simples Beispiel:

PHP-Code:

import flash.display.Shape;

var test:Shape = new Shape;

// einfache Ausgabe ------------------------------
test.alpha = 0.0;
trace(test.alpha, realAlpha(0.0));
test.alpha = 0.1;
trace(test.alpha, realAlpha(0.1));
test.alpha = 0.2;
trace(test.alpha, realAlpha(0.2));
test.alpha = 0.3;
trace(test.alpha, realAlpha(0.3));
test.alpha = 0.4;
trace(test.alpha, realAlpha(0.4));
test.alpha = 0.5;
trace(test.alpha, realAlpha(0.5));
test.alpha = 0.6;
trace(test.alpha, realAlpha(0.6));
test.alpha = 0.7;
trace(test.alpha, realAlpha(0.7));
test.alpha = 0.8;
trace(test.alpha, realAlpha(0.8));
test.alpha = 0.9;
trace(test.alpha, realAlpha(0.9));
test.alpha = 1.0;
trace(test.alpha, realAlpha(1.0));


// Example:einfacher "Tween" ---------------------
trace("-----------------------------");
test.alpha = 0.0;
for(var i:uint; i < 10; i++) {
    test.alpha = realAlpha(roundAlpha(test.alpha) + 0.1);
    trace(test.alpha);
}

function realAlpha(alphaValue:Number):Number {
    return Math.floor(alphaValue * 256) / 256;
}
function roundAlpha(alphaValue:Number):Number {
    return Math.round(alphaValue * 10) / 10;
} 


Output:

0 0
0.09765625 0.09765625
0.19921875 0.19921875
0.296875 0.296875
0.3984375 0.3984375
0.5 0.5
0.59765625 0.59765625
0.69921875 0.69921875
0.796875 0.796875
0.8984375 0.8984375
1 1
-----------------------------
0.09765625
0.19921875
0.296875
0.3984375
0.5
0.59765625
0.69921875
0.796875
0.8984375
1

[speedjunkie]

Wollt nur mal ein Link posten zu Arithmetik und Zahlenpräzision im Allgemeinen für AS3.

bigdecimal - BigDecimal implementation for ActionScript 3. - Google Project Hosting