Spezielle Festkommazahl?

[SnuffMaster23]

Wäre es möglich Delphi ganz spezielle Festkomma-Datentypen beizubringen?

Ich dachte so an 1/2(Vorzeichen) Bit(s) vor dem Komma und 15/14 Bits danach.
Also Wertebereich von 0 bis 1 bzw. von -1 bis +1 bei recht hoher Genauigkeit bei niedrigem Speicherbedarf. Festkomma wegen der schnelleren Verarbeitung.
(Und ich habe nicht vor das ganze Prog in asm zu schreiben :D)

[3_of_8]

Du müsstest dir halt einen eigenen schreiben. Ab Delphi 2006 kannst du dafür auch Klassenoperatoren verwenden. Im Prinzip musst du "nur" die Funktionsweise der FPU nachahmen.

[SnuffMaster23]

Hm ok, und wie schreib ich mir den?
Ich hab Delphi 2005.
Und ich müsste nur die ALU nachahmen, Festkommazahlen "sind" doch Integers.

[3_of_8]

Aargh, Festkommazahl... Ich hab nur das F und das Komma gelesen... ;)

Dann wird das ganze ein bissel einfacher.

Du bekommst aber ein Problem, wenn du deine Zahl mit einem Integer/Cardinal oder einer Gleitkommazahl multiplizieren willst.

Im Prinzip kannst du für deine Zahl auch einfach einen SmallInt nehmen und dann nur die Rechenoperationen und Ausgabeprozeduren anders implementieren.

[SnuffMaster23]

Gleitkommas sollte es eigentlich nicht geben, Integers schon eher.

Wenn ich nen SmallInt nehm, wie siehts dann aus wenn ich z.B. 1x1 hab? Da steht ja dann im SmallInt 32768 x 32768. Kommt da dann wieder 32768 raus? Wohl nicht, der Windows-Rechner sagt 0.
Drum müsste man da nen neuen Datentyp einführen denk ich mir.
Sonst muss ich ja solche Sachen wie Plus und Minus neu schreiben und zwar als Funktionen. Oder kann man Operatoren definieren?
Zur Ausgabe muss das dann als Genzzahl in ein/zwei Byte(s) gemappt werden.

[3_of_8]

Nein, das sagte ich bereits. Du musst die Rechenfunktionen anders implementieren.

Am einfachsten ginge das so:

Delphi-Quellcode:

function FixedMul(a, b: SmallInt): SmallInt;
var aex, bex: Extended;
begin
aex:=1/a;
bex:=1/b;
result:=round(1/(aex*bex));
end;

function FixedDiv(a, b: SmallInt): SmallInt;
var aex, bex: Extended;
begin
aex:=1/a;
bex:=1/b;
result:=round(1/(aex/bex));
end;

[SnuffMaster23]

Ui, da war ich wohl zu langsam mit editen :D

Ich dachte an den Datentyp weils dann viel schneller zu verarbeiten wäre.
Deine Funktionen sind ja eigentlich ziemlich langsam wegen den vielen Divisionen, Programmsprüngen und Extendeds (die sind ja eigentlich auch Krücken, kein PC kann mit 10 Bytes auf einmal rechnen).

Und fürs Verständnis: Wieso Kehrbrüche?

[3_of_8]

Îch nehme mal 7F FF soll soviel wie 1 heißen. Also ist 00 01 1/32768.

Und wenn dir das zu langsam ist, kannst du deinen Code ja auch selbst schreiben, mit Binärgefummel. Allerdings wird das garantiert nicht so schnell gehen wie mit einem nativen Datentypen.

[r2c2]

Im Prinzip brauchst du keinen neuen Datentyp. Integers reichen. Allerdings musst du Schiebefaktoren mitspeichern. Also: Mit Integer rechnen und immer n Schiebefaktor mitführen. ggf. noch n shr bzw. shl einbauen und fertig. So wirds jedenfalls bei "richtiger" Festkommarechnung(z.B. aufm DSP) gemacht...

Musst nur eben die versch. Rechenarten beachten:
+, - ==> Schiebefaktor ändert sich nicht
*, / ==> aufpassen

mfg

Christian

[SnuffMaster23]

@3_of_8: Wieso 7F FFh (0111 1111 1111 1111b) als "1" und nicht 80 00h (1000 0000 0000 0000b)?
Wie stellst du dann z.B. 0,5 dar? Oder einfach 1?
Der Kehrbruch von 1 ist bei mir 00 001h und nicht 7F FFh :?

@r2c2: Der Schiebefaktor wäre ja immer gleich also kann ich den hardcoden.
Nur wenn ich das hin und her-shifte, was passiert dann mit dem Nachkommateil? Der is dann weg wenn ich nicht drauf aufpasse^^.
Und wie muss ich dann mit dem rechnen, ich kann mir das nicht so ganz vorstellen.

Ich dachte halt Festkomma weils schneller zu behandeln ist (Integer) und es keinen 2-Byte-Gleitkommatyp gibt (Speicherbedarf).
Aber ich hab grad festgestellt dass sich selbst mit Single (4 Byte) der Speicherbedarf eigentlich in Grenzen hält.

Ich werds dann mal mit Singles probieren, wenns nicht tut werd ich auf Festkommas zurückkommen.
Singles dürften ja schneller "sein" als Extendeds, die passen ja noch nichtmal in nen 64-Bit Prozzi rein ;)

Ihr dürft natürlich weiterhin gerne versuchen mir das zu erklären :D

[r2c2]

Zitat:

Zitat von SnuffMaster23

@r2c2: Der Schiebefaktor wäre ja immer gleich also kann ich den hardcoden.
Nur wenn ich das hin und her-shifte, was passiert dann mit dem Nachkommateil? Der is dann weg wenn ich nicht drauf aufpasse^^.
Und wie muss ich dann mit dem rechnen, ich kann mir das nicht so ganz vorstellen.

Mal gucken ob ich das noch zusammenkrieg... Hab in den Sommerferien n Ferienjob gehabt und da haben die fast außschließlich mit Festkomma gerechnet(DSP). Hab das aber noch nie gamacht. Nur mal gesehen. Also alle Angaben ohne Pistole...äh... Gewähr...

Delphi-Quellcode:

var
  int1: Integer; // 32 Bit; passt genau in ein Register
  int2: Integer;
  erg: Integer;
  erg_float: Double;
  shift: Integer;
begin
  // ich definier jetzt einfach mal: positiver Schiebefaktor: shr; negativer: shl
  shift := 0; // ganze Zahl

  int1 := 1024;
  int2 := 512;

  erg := int1 + int2; // ändert nix am Schiebefaktor

  erg := int1 - int2; // ändert nix

  erg := int1 * int2; // 32 Bit * 32 Bit = 64 Bit; hier müsste ggf. geschoben werden um die 64 Bit in die 32 zu kriegen. Sollte aber bei "normalen" Zahlenbereichen überflüssig sein. Delphi meckert schon bei nem Overflow... ;-)

  erg := int2 div int1; // erg is eigentlich 0,5. Passt aber nicht in den Integer rein. Also schieben:
  int2 := int2 shl 1; // int2 anpassem
  shift := +1; // Shiftfaktor speichern; +1, da nach rechts geschoben werden muss um das eigentliche Ergebnis zu erhalten

  erg := int2 div int1; // rechnen; 1024 / 1024 = 1

  // nur zur Verdeutlichung, dass auch das drin is, was soll:
  // in Float umwandeln = zurückschieben:
  if shift > 0 then
    erg_float := erg / Power(2, shift) // "shr für Float"
  else
    erg_float := erg * Power(2, shift); // "shl für Float"
  
  ShowMessage(FloatToStr(erg_float)); // 0,5
end;

Ich hoff ich habs noch richtig behalten aber so scheints zu stimmen. Das is IMHO richtiges Festkomma rechen. So wirds gemacht, wenn man keine FPU hat.

Das hat aber, wie du siehst natürlich mehrere Nachteile:
- ewig langwierige Rechnerei :-(
- blöd, wenn man mehr als 32 Bit shiften muss... :roll:
- man muss immer wissen, in welchen Größenordnungen sich die Zahlen befinden uind demnach schieben, sonst gibts Ungenauigkeiten(Hätt ich oben nicht geschoben, wär das Ergebnis 0;
- wichtig is, dass alle Zahlen die selben Schiebefaktoren haben. Wenn nicht, darfst du das auch noch berücksichtigen...

Ob das das ist, was du willst, weiß ich nicht. Das Ganze nur in Festkomma zu speichern und mit Gleitkomma zu rechnen macht aber IMHO keinen Sinn, da sich dadurch nicht die Vor- sondern nur die Nachteile addieren: hoher Aufwand(Festkomma) und langsam, ungenau(Gleitkomma).

Generell fragt sich, ob es Sinn macht auf Float zu verzichten. Wenn man nicht dazu gezwungen ist(keine FPU), sollte man IMHO auch die Floats nutzen...

Wenn es wirklich auf die Geschwindigkeit ankommt, gibts bestimmt noch andere einfacherere Optimierungsmöglichkeiten...

Zitat:

Ich dachte halt Festkomma weils schneller zu behandeln ist (Integer) und es keinen 2-Byte-Gleitkommatyp gibt (Speicherbedarf).
Aber ich hab grad festgestellt dass sich selbst mit Single (4 Byte) der Speicherbedarf eigentlich in Grenzen hält.

Was hast du denn zu proggen, dass es dermaßen auf den Speicherplatz ankommt? In Zeiten von mehreren hundert MB RAM noch auf 1,2 Bytes mehr oder weniger gucken? :gruebel:

mfg

Christian

[SnuffMaster23]

Das sieht richtig gut aus! :thumb: :thumb: :thumb:

Aber du hast mich jetzt endgültig überzeugt, Festkomma muss nicht sein, FPU kann ich voraussetzen und Single tuts leicht.

Das ganze kommt hinterher eh als Ganzzahl in einzelne Bytes, ich will nur etwas genauer rechnen:
1 => 255
0,5 => 127
0 => 0 *g*

Und ich will mit Kommazahlen rechnen weils einfach viel leichter wird.
Wenn ich mit den Bytes rechne muss ich bei ner Multiplikation immer durch 65535 teilen, bei ner Division mit 255 malnehmen.

Das mit dem Speicherplatz sind nicht 1, 2 Bytes mehr oder weniger sondern eher 1, 2 MegaBytes ;) aber das ist ja auch zu verkraften.

[Khabarakh]

Delphi 2006 + überladene Operatoren. Natürlich nicht einmal annähernd so schnell wie die primitiven Float-Typen, aber fast genauso leicht zu benutzen ;) .

@r2c2: Ich habe von der Materie nicht viel Ahung, aber bist du mit deinem "Shift-Faktor" nicht wieder in den Bereich der Floatpoints gewandert :gruebel: ?

[r2c2]

Zitat:

Zitat von SnuffMaster23

Das ganze kommt hinterher eh als Ganzzahl in einzelne Bytes, ich will nur etwas genauer rechnen:
1 => 255
0,5 => 127
0 => 0 *g*

Das hab ich jetzt nicht ganz verstanden. Das kommt eh in Bytes? :shock: Das sind dann doch deine Festkommas. Mit 8 Bit und Shift-Faktor 7. Wenn du aber genau rechnen willst(so versteh ich dich momentan), dann frag ich mich, warum du Festkomma nehmen willst. :gruebel: N Festkomma is net genauer als n Fließkomma. Die Genauigkeit bestimmt sich IMHO aus der Größe der Mantisse. Hier (bei nem Byte) hast du ne Mantisse von 8 Bit. Bei nem Single eine von 23 :!:. Und bei nem Extended von 64. Wenn du n Festkomma-Integer nimmst(siehe mein Post oben) von 32 und wenn du statt dem Integer n Int64 nimmst, auch wieder 64. Jeweils is natürlich evtl. noch n Vorzeichen-Bit zu beachten...

Vielleicht sagst du uns mal, was du genau vor hast. Wo willst du denn nun genau, schnell oder speicherschonend sein...

Zitat:

Zitat von Khabarakh

@r2c2: Ich habe von der Materie nicht viel Ahung, aber bist du mit deinem "Shift-Faktor" nicht wieder in den Bereich der Floatpoints gewandert :gruebel: ?

Bei ner Gleitkommazahl is IMHO Mantisse und Exponent für *jede* Zahl separat bestimmt. Bei ner Festkommazahl is der Shiftfaktor(= Exponent) für alle bzw. den gerade betrachteten Teil der Zahlen gleich. Dass der Shiftfaktor geändert wird, liegt daran, dass Festkomma * Festkomma keine Festkommazahl ergibt bzw. dass das, was rauskommt, n anderen Shiftfaktor hat(das is wie beim schriftlichen Multiplizieren in der Grundschule). Das Anpassen der Shiftfaktoren kann außerdem sinnvoll sein, wenn man z.B. 32-Bit-Werte in 16 Bit packen will. Einfach schieben und Shiftfaktor ändern. Klar is das ungenau, aber es ist die einzige Möglichkeit, wenn man nur 16 Bit-Ganzzahlen verarbeiten kann... Geht nu mal nich anders...

Auch hier gilt wieder: Ich hab das noch nie gemacht. Nur mal gesehen. Alle Angaben sind also wie immer ohne Gewähr, nachlesen können Sie die Lottozahlen... äh... Festkommazahlen und Gleitkommazahlen u.a. in der Wikipedia...

mfg

Christian

P.S.: Wenns dir wirklich auf die Geschwindigkeit ankommt, verabschiede dich vom Dividieren *halb im Spaß und halb im Ernst spricht* :zwinker:

[Khabarakh]

Ich kann es mir immer noch nicht vorstellen :zwinker: . Ein Fixed-Point-Typ hat eine einmalig festgelegte Anzahl von Stellen vor dem Komma (also < 1) und von Nachkommastellen, daran wird IMO nie etwas geändert. Vor Allem: Wie willst du "den gerade betrachteten Teil der Zahlen" definieren, speichern? Am Ende läuft das auf das Speichern des Shiftfaktors=Exponenten innerhalb jeder Variable hinaus => Floatpoint.

[r2c2]

Angenommen du hast 5 Messwerte. Alle liegen in einer anderen Größenordnung. Die musst du verrechnen und am Schluss kommt wieder n Wert raus.

Mit Gleitkommas funktioniert das so:
- alle Werte verrechnen
- die FPU macht das schon...
- Wert am Ende ausgeben

Mit Festkommas geht das folgendermaßen:
- Alle Werte normieren, d.h. auf einen gemeinsamen Shiftfaktor bringen(wie bei der Bruchrechnung)
- Mit den Mantissen-Werten(und nur mit denen) als Ganzzahlen rechnen
- Den Wert, der an Schluss wieder rauskommt muss dann wieder angepasst werden
- dann erst ausgeben

Angenommen du hättest keinen variablen Shiftfaktor, dann hieße das, du rechnest nur mit Integern ohne Shiftfaktor. Das geht auch. Aber nur sehr begrenzt, da du so nicht multiplizieren kannst:
Wenn du z.B. ne 2 hast: 00000010 und willst die Quadrieren geht das: 00000100. Das is aber Integer. Hast du jetzt 0,5: 00000010(Dein Shiftfaktor(den hast du zwangsweise, auch, wenn du ihn nicht änderst; ohne den gibts nämlich kein Komma) wäre dann 2). Willst du jetzt quadrieren hast du ein Problem, weil du immer noch bei deinem Shiftfaktor bleiben willst: 00000100(=1). Also 0,5*0,5=1... ähm... ne nich so ganz. Du könntest natürlich sagen, "Dann teil ich eben wieder durch 2^2.", aber das is nix anderes als mein Shiftfaktor, nur mit dem Nachteil, dass du irgendwann über den rechten Rand hinausschiebst: Quadriere nochmal und du kannst einpacken: 00000001 * 00000001 = 00000001. Dann willst du noch um eins schrieben und erhälst 00000000. Nachteil: Du hast 8 Bit(oder eben so viel du hast) ungenutzt gelassen und dein Wert is im Nirwana verschwunden. Ich nehm mal an du hast keinen buddhistischen Wert. Der wird sich also nicht so sehr darüber freuen... :roll:

Im Prinzip is das also nix anderes als Emulation von Float. Deshalb sollte man auch, wenn man Floats zur Verfügung hat mit Floats rechnen(Ausbahmen bestätigen die Regel)...

mfg

Christian

[SnuffMaster23]

@Khabarakh: Wie ich bereits sagte, es gibt keine Zahlen über 1. Also reicht es doch wenn das Komma "zwischen" dem ersten und zweiten Bit sitzt.

@r2c2: Das Festkomma ist insofern genauer als Gleitkomma weil keine Bits für den Exponenten gebraucht werden ;)
Ich wollte Festkomma nehmen weil

• ich dann auch nen kleinen 16-Bit-Typ nehmen kann (überflüssig wie ich ja festgestellt habe, 32 Bit sind auch zu verkraften)
• 16 Bit halt genauer sind als 8
• im Bereich von 0-1 leichter zu rechnen ist als von 0-255 (1 * 0.8 ergibt 0.8, 255 * 204 aber nicht 204 ;))
• ich das noch nie gemacht hab => Herausforderung :D

Aber mittlerweile find ich die Herausforderung nicht mehr so spannend^^ und die Floats haben doch irgendwie die größeren Vorteile.
Drum hab ich ürsprünglich auch gefragt ob Delphi nen neuen Datentyp schluckt, dann könnte ich den Rest ja ganz normal programmieren ;)

[r2c2]

Wie genau muss es denn sein? N Single hat im Bereich von 0..1 ne Auflösung von 1/8388608. Das ist also ungefähr 0,00000012. IMHO doch schon recht genau... :wink: Aber so wie ich das sehe, bist du je eh schon zu Float bekehrt... :mrgreen:

//Nachtrag:

Zitat:

Drum hab ich ürsprünglich auch gefragt ob Delphi nen neuen Datentyp schluckt, dann könnte ich den Rest ja ganz normal programmieren :wink:

Wie schon angesprochen: Geht ab D2006. Is aber nicht besonders schnell...

mfg

Christian

[SnuffMaster23]

Soo genau müssen "Zwischenergebnisse" wohl nicht sein wenns am Schluss nur ne Auflösung von 1/256 = ca. 0,0039 gibt.
Ich wollte ja erst 16 Bits nehmen, 10 würden ja schon reichen :D

Und D2006 hab ich nicht, da wärs mir eh viel zu langsam^^

[Khabarakh]

@r2c2: Festkommatypen haben einfach einen statischen Wertebereich, daran lässt sich nix ändern. Dass 0,25² bei einem Q6.2-Typen (also mit der Auflösung 0,25) im Nirvana verschwindet, liegt in der Natur der Sache. Kann ich diese Einschränkung nicht gebrauchen, greife ich zu Floats.
Dein Typ wiederum macht nach einiger Überlegung - sorry ;) - überhaupt keinen Sinn mehr. Schon 8² schlägt bei deinem 8-Bit-Beispiel durch einen Überlauf fehl, durch deinen Shiftfaktor werden die festen Fixed-Point-Grenzen unkontrollierbar - abhängig von dem Binärwert und dem Faktor (eigentlich wohl eher Exponent ;) ) - hin- und hergeschoben. Die Verwendung des Typs ist damit quasi unmöglich, Float Types (und das _ist_ dein Typ einfach, wie du schon selbst am Schluss erwähnt hast) sind ohne normierte Mantisse einfach unsinnig und unbrauchbar.

[r2c2]

Hallo Khabarakh,

Zitat:

Festkommatypen haben einfach einen statischen Wertebereich, daran lässt sich nix ändern. Dass 0,25² bei einem Q6.2-Typen (also mit der Auflösung 0,25) im Nirvana verschwindet, liegt in der Natur der Sache. Kann ich diese Einschränkung nicht gebrauchen, greife ich zu Floats.

Du hast mein Argument noch nicht verstanden. Wenn ich keine FPU hab(wie z.B. auf nem DSP) bleibt mir nix anderes übrig, als auf Floats zu verzichten :roll:

Zitat:

Dein Typ wiederum macht nach einiger Überlegung - sorry :wink: - überhaupt keinen Sinn mehr.

Du musst dich nicht entschuldigen. Wir diskutieren hier über den Sinn und Unsinn unterschiedlicher Umsetzungen von Reelen Zahlen. Und ohne andere Meinungen, gäbs keine Diskussion...

Zitat:

Schon 8² schlägt bei deinem 8-Bit-Beispiel durch einen Überlauf fehl,

Warum?

Delphi-Quellcode:

int1 := 8;
int2 := 8;
Shift := 0;
erg := int1 * int2;
// am Shift-Faktor ändert sich nix, da 0+0=0 ist...

Wo ist der Überlauf?

Zitat:

durch deinen Shiftfaktor werden die festen Fixed-Point-Grenzen unkontrollierbar

unkontrollierbar nicht, aber man muss extrem aufpassen. Da hast du Recht. So zu rechnen is nicht einfach. Wenns aber nicht anders geht(ich erwähne hier mal wieder den DSP), hat man keine andere Wahl.

Zitat:

(eigentlich wohl eher Exponent :wink: )

Ich weiß, dass das eigentlich n Exponent is. Trotzdem haben die das Teil in der Firma "Shift-Faktor" genannt. Kann ich nix für...

Zum Verwendungszweck:
- Float: Immer, wenns geht
- Festkomma ohne variablen Shift-Faktor: Mir fällt kein sinnvolles Einsatzgebiet ein
- Festkomma mit variablem Schiebefaktor: wenn keine FPU da is

Letzterer Punkt impliziert zwar schon, dass es unter Delphi, was ja nur unter Win läuft und Win nur mit FPU funktioniert, wenig Sinn macht auf Floats zu verzichten, aber das war ja auch schon gesagt...

mfg

Christian

[Khabarakh]

Zitat:

Zitat von r2c2

Hallo Khabarakh,

Zitat:

Festkommatypen haben einfach einen statischen Wertebereich, daran lässt sich nix ändern. Dass 0,25² bei einem Q6.2-Typen (also mit der Auflösung 0,25) im Nirvana verschwindet, liegt in der Natur der Sache. Kann ich diese Einschränkung nicht gebrauchen, greife ich zu Floats.

Du hast mein Argument noch nicht verstanden. Wenn ich keine FPU hab(wie z.B. auf nem DSP) bleibt mir nix anderes übrig, als auf Floats zu verzichten :roll:

Du hast mein Argument nicht verstanden: Es gibt nichts anderes (sinnvolles, s.u.) als Fixed Point und Float Point. Habe ich keine FPU, muss ich sie entweder emulieren (was wohl höchstens auf Taschenrechnern verkraftbar wäre) oder Fixed Point benutzen.

Zitat:

Delphi-Quellcode:

int1 := 8;
int2 := 8;
Shift := 0;
erg := int1 * int2;
// am Shift-Faktor ändert sich nix, da 0+0=0 ist...

Wo ist der Überlauf?

(Huppsala, eigentlich meinte ich 4² ^^, was aber irrelevant ist)Ich bezog mich auf dein 0,5-Beispiel, in dem 4 = 000100(,)00 wäre => Peng. Natürlich, mit einer geschickten Wahl des Shiftfaktors lässt sich der Überlauf verhindern, aber mit welchem Algorithmus soll dein Typ diesen am Besten ermitteln? Die Antwort ist schon gefunden: IEEE 754.

Zitat:

unkontrollierbar nicht, aber man muss extrem aufpassen. Da hast du Recht. So zu rechnen is nicht einfach.

Ich möchte es jedenfalls nicht benutzen *g* . Noch ein anderes Beispiel: 0,5.
Ganz egal, welchen Shiftfaktor ich wähle, spätestens nach achtfacher Multiplikation mit 1 (!) ist bei 8-Bit Schicht im Schacht.

Zitat:

Zitat von r2c2

- Festkomma ohne variablen Shift-Faktor: Mir fällt kein sinnvolles Einsatzgebiet ein

Auch wenn das Sparen der paar Bits pro Variable heutzutage wohl nicht mehr relevant ist, ist diser Thread hier doch ein schönes Beispiel. Bei Fixed Points mit Shift-Faktor und mehr als vier mathematischen Operationen würde Snuffmaster wohl durchdrehen, ich würde es ganz bestimmt :zwinker: .

Es gibt sicher ein paar Anwendungsgebiete für "Shifted Fixed Points", aber da dabei wohl zu jeder Zeit die Anzahl der Operationen, die Wertebereiche aller Argumente bekannt sein müssen, sind die Gebiete imho schon ziemlich eingeschränkt.
Warum sonst sollte ein dem Dreidimensionalem durchaus mächtiger Handheld wie z.B. der Nintendo DS ausschließlich Fixed Point benutzen, wenn sich Grafikprogrammierer am PC eine Welt ohne Floatpoint gar nicht mehr vorstellen können (und ja, die Theorie der Fließkommazahlen steckt tief im Design heutiger PC-Engines)?

[r2c2]

Zitat:

Zitat von Khabarakh

Du hast mein Argument nicht verstanden: Es gibt nichts anderes (sinnvolles, s.u.) als Fixed Point und Float Point. Habe ich keine FPU, muss ich sie entweder emulieren (was wohl höchstens auf Taschenrechnern verkraftbar wäre) oder Fixed Point benutzen.

Ich hab mir das mit dem Shift-Faktor, etc. nicht ausgedacht. Es wird so gemacht(alles unter der Voraussetzung, ich hab das richtig verstanden). Punkt. Und es ist verkraftbar. Wenn auch aufwändig. Das was ich gesehen hab, war grob gesagt, ne Steuerung für n Elektromotor. Wenn ichs noch richtig im Kopf hab, waren das da > 300 C-Files. Und die waren mitunter ganz schön lang... Es *ist* also möglich und *wird* auch gemacht...

Zitat:

(Huppsala, eigentlich meinte ich 4² ^^, was aber irrelevant ist)Ich bezog mich auf dein 0,5-Beispiel, in dem 4 = 000100(,)00 wäre => Peng. Natürlich, mit einer geschickten Wahl des Shiftfaktors lässt sich der Überlauf verhindern, aber mit welchem Algorithmus soll dein Typ diesen am Besten ermitteln?

Und genau diese geschickte Wahl des Shiftfaktors ist es, die andauernd gemacht werden muss. Das versuch ich doch die ganze Zeit zu sagen... Ohne den is es nämlich dein Festkomma ohne variablen Shiftfaktor...

Zitat:

Die Antwort ist schon gefunden: IEEE 754.

N DSP hat keine FPU. Jedenfalls die, mit denen ich zu tun hatte...

Zitat:

Zitat:

Zitat von r2c2

- Festkomma ohne variablen Shift-Faktor: Mir fällt kein sinnvolles Einsatzgebiet ein

Auch wenn das Sparen der paar Bits pro Variable heutzutage wohl nicht mehr relevant ist, ist diser Thread hier doch ein schönes Beispiel. Bei Fixed Points mit Shift-Faktor und mehr als vier mathematischen Operationen würde Snuffmaster wohl durchdrehen, ich würde es ganz bestimmt :zwinker: .

Ich wahrscheinlich auch. Deshalb programmier ich ja auch für n PC und nicht für n DSP...

Zitat:

Es gibt sicher ein paar Anwendungsgebiete für "Shifted Fixed Points", aber da dabei wohl zu jeder Zeit die Anzahl der Operationen, die Wertebereiche aller Argumente bekannt sein müssen, sind die Gebiete imho schon ziemlich eingeschränkt.

Ich kenn auch nur eins. Das oben genannte. Aber ich kenn eins.

Hier nochmal n Beispiel, warum es sinnvoll ist den Shilftfaktor zu benutzen:

Delphi-Quellcode:

// Voraussetzungen: 
// - keine FPU da
// - es ist genau bekannt in welchen Wertebereichen die gemessenen Größen sich befinden
// - es stehen nur 16-Bit-Datentypen zur Verfügung

var
// zur Verdeutlichung SmallInt; man kann also mit 16 Bit rechnen:
  Wert1: SmallInt; // sehr große Zahl; 2^10 bis 2^14;
  Wert2: SmallInt; // sehr kleine Zahl; 2^-9 bis 2^-6
  Erg: SmallInt;
  Shift: SmallInt;
begin
  // Wir wollen beide Werte multiplizieren; Mit Float kein Problem, aber das steht nicht zur Verfügung...
  Wert1 := GetWert1(Sonstwoher); // Wertebereich bekannt. Impliziter Shiftfaktor -10; unser Beispielwert sei 128 * 2^12 = 512 * 2^10(das 10^10 wird implizit gespeichert durch den impliziten Shiftfaktor)
  Wert2 := GetWert2(Sonstwoher); // Wertebereich bekannt. Impliziter Shiftfaktor +10; unser Beispielwert sei 4 * 2^-7 = 8 * 2^-6
  Erg := Wert1 * Wert2; // 128 * 4 = 512
  Shiftfaktor := 4; // 10 - 6 // muss nicht extra gespeichert werden, da er implizit bekannt ist. Wichtig is aber ne gute Dokumentierung
end;

Wir können also damit rechnen. Hätten wir die - impliziten - Shiftfaktoren nicht, gäb es keine Möglichkeit damit zu rechnen, da entweder der große ider der Kleine Wert nicht in die 16Bit passt...

Ich weiß, das is alles ganz anders, als unter Delphi. Und das is nur ein Beispiel. Bei der programmierung für n 16-Bit-DSP gilt nämlich u.a.:
- es gibt nur 16 Bit. fertig
- jede Mikrosekunde zählt
- Division is verboten
- Wer durch Konstanten teilt, wird geteert und gefedert
- Wer durch 2er-Potenzen teilt, wird gevierteilt
- Die bedingten Sprünge(u.a. die berühmt-berüchtigten ifs) werden in den Tartaros verbannt, wo sie tagein tagaus versuchen einen Stein auf einen Hügel... ähm... ne das macht schon Sisyphos... müssen uns also noch ne geeignete Strafe einfallen lassen :gruebel:

So isses also auf m DSP zumindest so ungefär. Die Strafen könnten auch noch härter sein. Bin mir da nicht sicher...

Zitat:

Warum sonst sollte ein dem Dreidimensionalem durchaus mächtiger Handheld wie z.B. der Nintendo DS ausschließlich Fixed Point benutzen, wenn sich Grafikprogrammierer am PC eine Welt ohne Floatpoint gar nicht mehr vorstellen können

Kann ich mir kein Urteil zu erlauben. Hab noch nie so n Viech in der Hand gehabt, geschweige denn den Quelltext...

Zitat:

(und ja, die Theorie der Fließkommazahlen steckt tief im Design heutiger PC-Engines)

Hab ich nie bestritten...

mfg

Christian