Hallo Leute, ich muss einen Prozentwert einer etwas grösseren Zahl(19Bit) berechnen. Wenn ich versuchen meineZahl*Prozentsatz/100 zu berechnen, dann habe ich eine Division durch 100. Division ist (fast) immer übel, aber gibt es vielleicht ein schnelle/einfache Division durch 10 oder 100? Oder hat jemand ne ander Idee? danke patrik
Gast
#961487
Was für ein Zahlenformat benutzt du denn? Wäre eventuell ein Q-Format http://en.wikipedia.org/wiki/Q_(number_format) denkbar? Dann könntest du mit 0.01 multiplizieren. Ansonsten könntest du vielleicht eine Binär-Dezimal-Umwandlung mit Schieberegistern umfunktionieren. Wie schnell muss es denn sein? Durchsatz? Latenz?
Schnell: multiplizier die Zahl mit dem Kehrwert (vorher entsprechend viele Nachkomma-Bits dranhängen). Einfach: zähle wie oft du 100 abziehen kannst bevor das Vorzeichen wechselt. Dazwischen gibt es natürlich noch diverse Mittelwege.
>meineZahl*Prozentsatz/100
Angenommen, "meineZahl" ist variabel, aber Prozentsatz ist konstant.
Dann ist das ist eine Multiplikation, denn wenn Prozentsatz konstant
ist, dann ist "Prozentsatz/100" auch konstant.
Einfach die Zahl mit 2^16/100=655 multiplizieren und die unteren 16 Bit wegwerfen. Fertig ist die Division durch Hundert. Siehe Festkommaarithmetuk
Gast
#962254
Guggst Du bei TI nach: SLAA329
Gast
#962302
Falk Brunner wrote: >Siehe Festkommaarithmetuk Da ist aber nicht wirklich viel vorhanden ... Nimm lieber Festkommaarithmetik
>>SLAA329
Das in der Appnote ist ja nun auch wieder
Festpunkt(oder -komma)arithmetik:1 | |
Nur steht das nicht so ausdrücklich da.
Gast
#962337
> >>SLAA329 > Das in der Appnote ist ja nun auch wieder > Festpunkt(oder -komma)arithmetik: > > M = 1/41.8375 = 0.0239020018 = 0.0000011000011110b > > Nur steht das nicht so ausdrücklich da. Das ternäre Hornerschema ist natürlich Festkommaarithmetik. Hast Du Wunder erwartet? Die Anzahl der benötigten Operationen ist allerdings recht gut. Der OP hat es ja mal wieder unterlassen, einen Hinweis auf die Zielarchitektur herauszurücken. > Prozentwert einer etwas grösseren Zahl(19Bit) Da wird ja wohl keiner extra deswegem die Float-Library dazulinken wollen :-)
Gast
#962454
> Einfach die Zahl mit 2^16/100=655 multiplizieren und die unteren 16 Bit > wegwerfen. Fertig ist die Division durch Hundert. Naja, zumindest wenn es nicht so ganz genau sein soll (z.B. wird es für einen Progress-Bar locker reichen). Beispiel: x = 100 x / 100 = 1 (x * 655) >> 16 = 65500 >> 16 = (int)0.99945068359 = 0
Gast
#962458
>Naja, zumindest wenn es nicht so ganz genau sein soll (z.B. wird es für >einen Progress-Bar locker reichen). Den macht man aber in Integerarithmetik mit X * 1,28 / 128 !
Gast
#962490
.. dann bekommt man ein neues Problem: Multiplikation mit 1.28, also dann doch lieber mit 655 multiplizieren ..
Gast
#962500
Wieso ? Multiplikation mit 1,28 ist genau, 655 nicht.
Gastinformatiker wrote:
> Wieso ? Multiplikation mit 1,28 ist genau, 655 nicht.
Wieso? 1.28 ist genauso ungenau wie das Benutzen von 655, wenn man bei
1.28 (=1.0100011110101110000101000111101b) auch nur 10 bit Genauigkeit
benutzt.
Gast
#962677
Hi Allerseits, Um auf Falk's ursprünglichen Vorschlag zurückzukommen - der ist nämlich m.E. nach bisher der beste Vorschlag - aber ich würd' mehr Bits spendieren: mit einem 18-Bit Multiplizier (17 Bit unsigned !) - die in den 'modernen devices vorhanden sind - ergibt sich mit SEHR hoher Genauigkeit: 1/100 ~ 41943/2^22 = 0.00999999 41943 = 0xA3D7 (16 Bit) Also: mit 41943 multiplizieren und die unteren 22 Bits wegschmeißen Gruß Jochen
>Prozentwert einer etwas grösseren Zahl(19Bit) passt nicht in einen >18-Bit Multiplizier (17 Bit unsigned !) Wieso brauche ich für einen Prozentwert eigentlich 17 oder 18 Bit? Na gut, der Funktionsblock ist eben so groß... >die unteren 22 Bits wegschmeißen... Wir leben in einer Wegwerfgesellschaft. Für 100% reichen aber doch 7 Bits, da könnte ich noch viel genauer rechnen und wesentlich mehr wegschmeissen (34 Bits - 7 Bits = 27 Bits ;-) Finde ich übrigens interessant, dass Patrick (OP) sich gar nicht mehr meldet :(
Gast
#962723
8 Bits sollten es schon sein, da die Genauigkeit vor der Rundung eine Dezimalstelle besser sein muss (im Binärsystem Faktor 2). 100% erfordern 0,5% -> Auflösung = 200! -> 8 Bit. Man kann es aber bedenkenlos größer formulieren - die Synthese wirft das unbenutzte weg. Wenn aber die 100% auf 0,1 angegeben werden müssen, braucht s logischerweise 3 Bit mehr.
Wie wär's, wenn die gesamte Rechnung mit unpacked BCDs gemacht wird?