Rechnen mit Gleitkommazahlen

[Felix G]

Eine solche Simpelst-Optimierung macht natürlich auch der Compiler selber. Du gewinnst mit dieser Schreibweise also rein gar nichts. Du verlierst nur etwas, nämlich die Offensichtlichkeit der eigentlichen Absicht hinter dem Code.

Zugegeben, bei konstantem Divisor gewinnt man üblicherweise nichts. Ist der Divisor aber nicht konstant, kann man Divisionen deutlich beschleunigen indem man sie in eine Multiplikation und einen Rechtsshift umbaut (denn das kann der Compiler selbst nicht mehr optimieren).

Daß das nur für Controller gilt die keinen schnellen Hardware Dividierer haben, versteht sich wohl von selbst.

[sternst]

Ist der Divisor aber nicht konstant, kann man Divisionen deutlich beschleunigen indem man sie in eine Multiplikation und einen Rechtsshift umbaut (denn das kann der Compiler selbst nicht mehr optimieren).

Und haben wir hier einen solchen Fall? Nein, es geht ganz konkret um eine Division durch 65536. Und du empfiehlst, dass durch ">> 16" zu ersetzen, weil es "eleganter" und "schneller" wäre. Sorry, aber das ist eben ziemlicher Unsinn.

Und so nebenbei: Zeig mal, wie du das mit einem nicht konstanten (und damit unbekannten) Divisor machst. Was du wohl eher meinst, ist ein konstanter Divisor, der aber keine 2er-Potenz ist.

[markusj]

Ich würde da eine kleine Tabelle nehmen, es sind 256 Werte zu 16Bit notwendig.

Eieiei, warum nicht gleich ein Koprozessor? Oder halt, noch besser: Wir rüsten gleich auf einen ARM der neuesten Generation um ... oder vielleicht nicht doch einen Intel Core iSonstwas Extreme?

Eine kleine 32-Bit Multiplikation (wert * 10000) mit nachfolgender Division/Wegwerfen der letzten zwei Bytes schafft der AVR auch noch ohne Lookup-Table oder sonstige Geschütze die hier aufgefahren werden. Vielleicht nicht schneller, aber vermutlich Platzsparender als eine Lookup-Table mit 2^12 Einträgen. (Ergibt sich, wenn du ausrechnest, in welchem Wertebereich "wert" liegen kann, damit sich nach der genannten Formel Werte von +-255 ergeben)

mfG
Markus

[Peter1060]

>>2^12 Einträgen
das ist doch Unfug, wenn 2^8.

...die Tabelle sind 512 Bytes plus Prog zum auslesen.
Der TO keinen Prof. oder Sprache angegeben hat, kann keiner sagen, wieviel Speicher notwendig ist.

Da ich in 8051 Assembler arbeite, könnte ich den genauen Bedarf für diese Sache ermitteln.

Mit Gruß
Peter

[markusj]

Dann leg doch Mal los.
Die Formel war:

ausgabe = 10000 * eingabe / 2^16

Umgestellt nach "eingabe" (die du ja in die Lookup-Table reinwerfen musst) ergäbe:

eingabe = ausgabe * 2^16 / 10000

"ausgabe" liegt zwischen -255 und 255 (siehe Firstpost), damit muss "eingabe" zwischen -1671 und 1671 liegen, du brauchst also 3343 Einträge in der Tabelle, auf die nächste Zweierpotenz gerundet macht das 2^12 ...
Wie du da mit 2^8 auskommen möchtest, kann ich gerade nicht sehen, auch in Assembler schlägst du die Mathematik nicht.

mfG
Markus

[Peter1060]

habe ich oben doch schon geschrieben:

(100/65536)* wert * 100 -->> das ist doch 1Byte * ~1,52...

ausgabe = wert *1.5258

[markusj]

Problem: "wert" (bei mir oben "eingabe") ist, wie ich vorgerechnet habe, eben nicht 1 Byte (Kein uint8_t).

[Peter1060]

>>ch habe einen Integer Wert, der den Bereich -255 bis 255 abdecken sollte

und das ist Signum + uint8

;Berechnung Ausgabe = Eingabe * (10^5 / 65536)
;
;Float
;Speicherbedarf 621 Bytes
;Takte 293 Cyclen

;Tabelle
;Speicherbedarf 544 Bytes
;Takte 23 Cyclen
;

HW_FPU EQU 0 ;keine FPU

; EinWert wird in DPTR als sign.Int übergeben
; AusWert wird in DPTR als unsigniert INT übergeben, Signum in A
;---------------------------------------------

cond 1
Mov A, DPH
Push A ;signum merken
CLR A.7
Mov DPH, A
Call _uint2fs
PutA
PushFC 1.525878906 ;10^5 / 65536
GoSub _fsmul_A
Call _round_A
Pop A ;signum dazu
ANL A, #80H
RET

include Float_s.inc

Else
;---------------------------------------------

Mov A, DPL
Add A, #TABELLE
Mov DPL, A
Mov A, DPH
Push A ;signum merken
CLR A.7
AddC A, #TABELLE >> 8
Mov DPH, A
CLR A
MovC A, @A+DPTR
Push A
Mov A,#1
MovC A, @A+DPTR
Mov DPL, A
POP DPH
POP A
ANL A, #80H
RET

TABELLE: DS 512
EndC
;---------------------------------------------
END

[markusj]

Der Wert soll sich aus folgender Rechnung ergeben:

(100/65536)* wert * 100;

Bequemerweise hast du DEN Teil von Daniels Aussage vergessen ... die +-255 sind Ausgabe und nicht Eingabe. Und da du in deine LUT die Eingabe stecken musst, bringt das ganze nichts. (Außer du möchtest einen Reverse-Lookup implementieren, was dann doch etwas übertrieben ist ...)

mfG
Markus

[Peter1060]

WENN es so ist...
dann ist der EinWert also nur im Bereich -167 bis +167...und die Tabellenform wird noch kürzer...

solange Daniel sich nicht äussert ist jede weitere Diskusion zwecklos.

Mit Gruß
Peter