Spezielle Festkommazahl?

[r2c2]

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...
- 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?

mfg

Christian

[SnuffMaster23]

Das sieht richtig gut aus!

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 ?

[r2c2]

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? 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. 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 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 ?

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*

[Khabarakh]

Ich kann es mir immer noch nicht vorstellen . 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...

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

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... Aber so wie ich das sehe, bist du je eh schon zu Float bekehrt...

//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

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

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.