ADD, SUB, MUL und DIV????

[DITTY]

Hallo COM,

könnt Ihr mir gute Algorithmen empfehlen, um schriftlich zu addieren, subtrahieren, multiplizieren und dividieren?

Die Algos sollten hoch effizient und nicht patentierbar sein, sprich quell offen.

Würde es sich hinsichtlich der Geschwindigkeit lohnen, alles mit char/Strings ,sprich mittels Entscheidungen - if-else/switch - entscheiden zu lassen, von der CPU wirklich rechnen zu lassen (+,-,*,/) oder ein Mischmasch aus beiden?

Ich würde ja mal glatt behaupten, dass das Arbeiten mit char´s schneller und einfacher geht, schließlich wird dabei ja nichts gerechnet, sondern nur entschieden. Zudem belegen char-typen (8-16 Bit) weniger Speicher als int-Typen (16, 32, 64-Bit).

Wie ist denn die Größe des Types String (C++). Char allein recht ja nicht aus, um ganze Wörter bzw. hier größere Zahlen (als Text) abzuspeichern, hiefür muss man entweder zu Char-Arrays oder eben zur String-Klasse greifen.

Die Größe von char-arrays zu bestimmen sollte einfach sein, aber wie ist die Größe (Bit-mäßig) beim Typ String?

###############################

Ich danke vielmals im Vorraus!!

Gruß

DITTY :):)

[Crush]

Ich denke, Du hast da irgendwas falsch verstanden.

1.) Die Grundrechenarten sind nicht patentierbar.

2.) char-Typen belegen deutlich mehr Platz als binäre Integer. Beispiel: mit einer 16-Bit Integer Zahl kann ich 65536 verschiedene Zahlen darstellen. in Characters ist die Zahl "65536" mit nur 8Bit pro Buchstaben schon 5*8 = 40 Bit groß. Bei 16-Bit Charakters ist das von vornherein schon mindestens gleich groß wie der Integer.

3.) Das binäre Zahlensystem ist nicht umsonst das einfachst mögliche Zahlensystem. Ein Oktal oder Dezimalsystem ist deutlich "komplizierter" zu verarbeiten. Das ist der Grund, wieso die Computer damit arbeiten.

4.) Mit if/else/switch kann man nicht sehr effektiv rechnen. Die Operatoren Und/Nicht und Oder mit Bitverschiebefunktionen sind deutlich effektiver und schneller, obwohl gelegentlich auch die anderen Befehle zusätzlich mal benötigt werden.

Wieso Du das ganze auch noch irgendwie schriftlich machen willst, erscheint mir etwas seltsam. Warum?

[flashpixx]

könnt Ihr mir gute Algorithmen empfehlen, um schriftlich zu addieren, subtrahieren, multiplizieren und dividieren?

Die Algos sollten hoch effizient und nicht patentierbar sein, sprich quell offen.

Das kann jeder Prozessor bzw jede Hochsprache und glaube mir, dass ist schon sehr effizient. Eine reine Addition usw. kann man nicht mehr "schneller" machen. Eine Addition und auch Multiplikation bzw Division und Subtraktion nimmt heute gar als "gleich schnell" an. Selbst eine Matrix-Matrix-Multiplikation von mehreren Tausend Elementen ist auf heutigen CPU im Sekundenbereich durchzuführen, obwohl die Komplexität sich in O(cn^3) bewegt, aber der konstanten Faktor c kann man sehr gut optimieren.

Würde es sich hinsichtlich der Geschwindigkeit lohnen, alles mit char/Strings ,sprich mittels Entscheidungen - if-else/switch - entscheiden zu lassen, von der CPU wirklich rechnen zu lassen (+,-,*,/) oder ein Mischmasch aus beiden?

Sicher nicht, da hier erst eine Umwandlung des Character-Byte in ein numerisches erfolgen muss.

Bevor ich Dir jetzt nur schreibe, dass meine Glaskugel in der Spüle ist, gebe ich Dir noch den Hinweis, dass, wenn es sich um Probleme bei der Performance geht, das Problem nicht der Rechner, sondern die Komponente ist, die davor sitzt. Da Du hier nur nach einer einzelnen Lösung fragst, ohne das Problem zu schildern, kann meine Antwort auch nur unzureichend sein. Es wäre für eine umfassende Antwort hilfreich, wenn Du das "große" Problem schilderst

Phil

[Crush]

Mich macht das mit dem Schriftlichen stutzig. Vielleicht sucht er ja sowas wie die Math Tricks?

[flashpixx]

@Crush:

könnt Ihr mir gute Algorithmen empfehlen, um schriftlich zu addieren, subtrahieren, multiplizieren und dividieren?

Das "schriftlich" hatte ich überlesen, aber ich würde hier sagen, dass man das mit DIV / MOD ohne weiteres realisieren kann bzw durch Schleifen.

Ich würde ja mal glatt behaupten, dass das Arbeiten mit char´s schneller und einfacher geht, schließlich wird dabei ja nichts gerechnet, sondern nur entschieden. Zudem belegen char-typen (8-16 Bit) weniger Speicher als int-Typen (16, 32, 64-Bit).

Woher nimmst Du diese Behauptung? Letztendlich werden auf der Hardware Bitoperationen durchgeführt, für mathematische Operationen gibt es aber spezielle Floating-Point-Strukturen (ALU) auf der CPU, so dass diese in großer Zahl durch Pipelining, wie es z.b. auf den heutigen GPUs state-of-the-art ist, parallel durch geführt.

Wie ist denn die Größe des Types String (C++). Char allein recht ja nicht aus, um ganze Wörter bzw. hier größere Zahlen (als Text) abzuspeichern, hiefür muss man entweder zu Char-Arrays oder eben zur String-Klasse greifen.

Je nach Encoding hast Du pro Zeichen auch 16 Bit (z.B. Unicode). Ein Char bleibt ein 8 Bit Datentyp, ein String ist aber durchaus komplexer. Mit ist aber beim besten Willen nicht klar, warum Du mit Char numerisch rechnen willst

Phil

[DITTY]

2.) char-Typen belegen deutlich mehr Platz als binäre Integer. Beispiel: mit einer 16-Bit Integer Zahl kann ich 65536 verschiedene Zahlen darstellen. in Characters ist die Zahl "65536" mit nur 8Bit pro Buchstaben schon 5*8 = 40 Bit groß. Bei 16-Bit Charakters ist das von vornherein schon mindestens gleich groß wie der Integer.

Nun, hier muss ich mal einlenken. Ein Char bzw. WChar kann die Zahl "65536" schonmal nicht aufnehmen, da dies ein String ist. Hier müsste man dann mit Char-Arrays oder mit String arbeiten. Dementsprechend ist doch meine Behauptung richtig, dass Char-Typen Speicherschonender als Int-Typen sind.

Natürlich sind bei einem 8-Bit-System Char und Int und bei einem 16-Bit-System WChar und Int gleichgroß, bei 32-Bit -und 64-Bit-Systemen hingegen fällt der Unterschied doch recht groß aus.

3.) Das binäre Zahlensystem ist nicht umsonst das einfachst mögliche Zahlensystem. Ein Oktal oder Dezimalsystem ist deutlich "komplizierter" zu verarbeiten. Das ist der Grund, wieso die Computer damit arbeiten.

Naja, der Grund ist ja wohl eher der, dass Computer nur mit 1en und 0en umgehen können, immer. Aber, dass das Binär-System das einfachste ist, sag ich nichts gegen.

Woher nimmst Du diese Behauptung? Letztendlich werden auf der Hardware Bitoperationen durchgeführt, für mathematische Operationen gibt es aber spezielle Floating-Point-Strukturen (ALU) auf der CPU, so dass diese in großer Zahl durch Pipelining, wie es z.b. auf den heutigen GPUs state-of-the-art ist, parallel durch geführt.

Bei Char wird meines Wissens (bitte korregiert mich) nicht gerechnet. Es werden Informationen lediglich entsprechend im Speicher aufbereitet und abgelegt, egal, ob jetzt Chache, RAM oder Festplatte.

Und Fließkommaberechnungen sind im Vergleich zu einfachen Rechnungen doch sehr träge, auch wenn heutzutage mehrere tausend Berechnungen pro sek durchgeführt werden können.

Hinzukommt, dass Fließkommaberechnungen ab gewissen Kommastellen zu ungenau werden und diese Ungenauigkeit von System zu System unterschiedlich stark ausfallen kann.

Wieso Du das ganze auch noch irgendwie schriftlich machen willst, erscheint mir etwas seltsam. Warum?

Und hier möchte ich ja ansetzen. Für meine späteren Vorhaben benötige ich Funktionen, die mit extrem großen Zahlen umgehen kann.

Datentypen, wie Int, Float und Co. haben stets immer einen Nachteil, sie sind in ihrem Wertebereich beschränkt. Auf dem Blatt-Papier hingegen, könnte man theoretisch bis ins unendliche rechnen, sofern noch Platz auf dem Papier sein sollte. Wenn man mal nachdenkt, rechnet man beim schiftlichen ADD/SUB/MUL/DIV stets nur mit relativ kleinen Zahlen (0...9) und bekommt am Ende eine größere Zahl bzw. kleinere (mit diversen Kommastellen) heraus, welche im Prinzip auch nur als Strings notiert werden. Meine Idee ist, dieses Prinzip auf den Computer zu übertragen. Ich meine, dass beseitigt eine Menge Probleme:

- keine theoretische Grenze beim Wertebereich

- theoretisch unendliche korrekte Genauigkeit (Vorkomma und Nachkomma)

Sowas kann man auf mehreren Wegen realsieren:

- Alles bis zum Max-Wertebereich von Int rechnen lassen und dann weiter mit Char/Stringd durch Entscheidungen (if/else/switch) "berechnen" lassen.

- oder von Anfang an nur mit Char/String und mit Entscheidungen oder mit den Operatoren Und/Nicht und Oder mit Bitverschiebefunktionen.

Beim Ersteren müsste man aber stets die Max-Grenze überprüfen, welche je nach System und Compiler unterschiedlich ausfallen könnte.

###################################

Sicher, es gibt Ansätze, wie z.B. Big-Integer, LongLong etc., bei welchen man mit größeren Werten, statt der üblichen Int,Long Int, umgehen kann. Dennoch haben diese stets eine Grenze in Ihrem Wertebereich und die Genauigkeit kann von System zu System / CPU zu CPU schwanken.

Ich versuche eine Lösung zu finden, wo es theoretisch (sieht man mal vom Speicher ab) keine Grenze in Sachen Wertebereich und Genauigkeit gibt.

Ich denke, dass das Prinzip des schriftlichen ADD/SUB/MUL/DIV hier perfekt geeignet ist. Die Einzige Beschränkung liegt hier wirklich nur in der Länge (damit Speichergröße) des rauskommenden Strings (welcher den Wert darstellen soll).

Gruß

DITTY :):)

PS: Wie ist denn nun das mit der String-Klasse (C++)?

Ist deren Größe unbestimmt und wo liegt ihre Grenze bzw. wie viele max. Zeichen lassen sich in einer String-Variable unterbringen?

[flashpixx]

Und Fließkommaberechnungen sind im Vergleich zu einfachen Rechnungen doch sehr träge, auch wenn heutzutage mehrere tausend Berechnungen pro sek durchgeführt werden können.

Definiere "einfache Rechnung". Bitte belege solche Äußerungen, denn so würde ich das definitiv nicht stehen lassen. Ich bezweifel, dass Du einen Unterschied zwischen einer Addition oder Multiplikation auf heutigen CPUs merken würdest.

Hinzukommt, dass Fließkommaberechnungen ab gewissen Kommastellen zu ungenau werden und diese Ungenauigkeit von System zu System unterschiedlich stark ausfallen kann.

Schreibe mir mal bitte auf ein Blatt Papier die Zahle e oder Pi genau auf. Und auch hier gilt, woher nimmst Du diesen Beleg? Warum soll ein 16 Bit Integer auf verschiedenen Architekturen unterschiedliche genau sein?

Die ist die IEEE 754 / 854 bekannt?

Und hier möchte ich ja ansetzen. Für meine späteren Vorhaben benötige ich Funktionen, die mit extrem großen Zahlen umgehen kann.

Datentypen, wie Int, Float und Co. haben stets immer einen Nachteil, sie sind in ihrem Wertebereich beschränkt.

Die IEEE erlaubt Zahlen bis zu einer Größe von 128 Bit (Gleitkomma).

Auf einem Blatt Papier lässt sich e oder Pi auch nie exakt als Ziffernfolge darstellen, denn Dein Speicher ist "beschränkt".

Sicher, es gibt Ansätze, wie z.B. Big-Integer, LongLong etc., bei welchen man mit größeren Werten, statt der üblichen Int,Long Int, umgehen kann.

Ich gebe Dir mal den Hinweis auf Arbitrary-precision arithmetic - Wikipedia, the free encyclopedia

Dennoch haben diese stets eine Grenze in Ihrem Wertebereich und die Genauigkeit kann von System zu System / CPU zu CPU schwanken.

Wo ist der Beleg? Wenn das der Fall wäre, dann zeig mir mal den Unterschied in meinen Codes und vor allem in der Berechnung auf meinem 32 Bit bzw 64 Bit Systemen.

Ich bitte Dich, dass Du die zum Teil wilden Behauptungen, die Du hier in den Raum stellst, einmal belegst.

Phil

[DITTY]

Definiere "einfache Rechnung". Bitte belege solche Äußerungen, denn so würde ich das definitiv nicht stehen lassen. Ich bezweifel, dass Du einen Unterschied zwischen einer Addition oder Multiplikation auf heutigen CPUs merken würdest.

Ja ok, sorry. Unter "einfacher Rechnung" verstehe ich den Umgang bzw. das rechnen mit natürlichen Zahlen, sprich des types Int, nicht Fließkommazahlen.

Und eine Fließkommaoperation ist nunmal wesentlich aufwendiger oder irre ich mich da. Zudem kommt erschwerend hinzu, dass Fließkommazahlen System- & Compiler-abhängig nach diversen Kommastellen zu ungenau werden und somit auch nicht für Entscheidungen geeignet sind, Int-Werte hingegen schon.

Schreibe mir mal bitte auf ein Blatt Papier die Zahle e oder Pi genau auf. Und auch hier gilt, woher nimmst Du diesen Beleg? Warum soll ein 16 Bit Integer auf verschiedenen Architekturen unterschiedliche genau sein?

Die ist die IEEE 754 / 854 bekannt?

Die Zahl Pi auf ein Blatt Papier zu schreiben wäre rein theoretisch möglich, wenn das Blatt Papier kein Ende hätte. Genau darum geht es mir ja.

Und, wo war hier die Rede von ungenauen Integer-Werten, die Rede war von Fließkommawerten und da schwanken System / CPU / Compiler-abhängig nunmal die Genauigkeiten, dass ist Fakt.

Nicht jeder Standard wird / wurde, selbst in aktuellen Compilern, nicht 100%ig implementiert, sonst ließen sich Quelltexte mit diversen Compilern gleich übersetzen. Komisch dabei, dass sich gewisse Werte bei vermeintlich ein-und-derselben Rechnung unterscheiden können.

Dazu einfach mal verschiedene Compiler austesten. Man wird hin-und-wieder Unterschiede bemerken.

Die IEEE erlaubt Zahlen bis zu einer Größe von 128 Bit (Gleitkomma).

Auf einem Blatt Papier lässt sich e oder Pi auch nie exakt als Ziffernfolge darstellen, denn Dein Speicher ist "beschränkt"

Ich benötige aber Lösungen, die keine Einschränkungen in Sachen Wertebereich und Genauigkeit besitzen. Die einzige Einschränkung soll nur der Speicher darstellen (Cache / RAM / Massenspeicher) und da würden meines Wissens her nur Char-Ketten bzw. String in Frage kommen. Dumm nur, dass sich damit nicht rechnen lässt, nicht direkt.

###############################

Einiges wurde mir beantwortet. Nachwievor ist mir aber unklar, wie der String-Datentyp (C++-Klasse) aufgebaut ist.

Char bzw. WChar haben vordefinierte Größen (8-Bit und 16-Bit), dementsprechend sind Arrays aus Char / WChar entsprechend linear größer.

Nur Angaben bzw. Grenzen des Types String kann ich nicht ausfindigmachen.

Hat jemand vielleicht etwas mehr Erfahrung über diesen Datentyp?

Wo liegen seine Schwächen und Grenzen?

Danke & Gruß

DITTY :):)

[Crush]

Vielleicht nur kurz zum Thema Genauigkeit: Du gibst selber zu, daß die Zahlen als Ints schneller zu berechnen gehen. Man kann auch Integer-Arrays aufbauen und einfach eine entsprechende Position als Bruch darstellen (hab ich früher in Demos gemacht, weil das schneller ging als mit dem Mathecoprozessor). Wie genau das ist hängt dann nur von Deiner Array-Größe ab. Grundsätzlich ist jede Information in Form eines Arrays abbildbar. Das kann kein Argument für eine höhere Qualität oder Genauigkeit des einen Typs gegenüber dem anderen sein. Dies hängt stark vom Wert ab, den man darstellen möchte.

Bsp:

Byte Wert

Vorkommastelle

0 = 0x80 wäre dann z.B. 1/2 und 0x40 1/4 usw.

Die Zahl wäre also bei 0xc0 = 1/2+1/4 = 0.5 + 0.25 = 0.75

1 - das erste Byte 0-255

2 - das zweite Byte ergibt 0-255 * 256 im Wert

3 ... kann man immer so fort führen.

Willst Du nun z.B. eine Zahl durch 2 Teilen, rollst Du die Werte einfach von oben nach unten um ein Bit nach rechts. Das kann die CPU mit Übertrag ganz leicht realisieren.

Mir sind die komischen Gedankengänge immer noch nicht klar, wie Du genau herleitest, mit dem Dezimalsystem schneller oder genauer zu sein.

Wenn Du eine nahezu unbeschränkte Genauigkeit haben willst, dann probier doch mal sowas wie die GMP oder Bigfloat Mathematik-Libraries aus.

String-Libraries haben übrigens meistens eine maximale String-Länge vorgegeben. Die liegt häufig so um die 1024 Stellen. Das kannst Du meistens prüfen mit int len = max_string; Das hängt von der jeweiligen Implementierung ab.

Bearbeitet 23. Juli 2009 von Crush

[flashpixx]

Und eine Fließkommaoperation ist nunmal wesentlich aufwendiger oder irre ich mich da.

Wenn ich eine Addition mit einem Int oder einem Float mache, werde ich hier kaum einen Unterschied merken. Ich will mal salopp sagen, dass "Bitschubserei" nicht die Performance bringt. Dein Algorithmus ist das Problem nicht die Darstellung Deiner Variablen. Wenn ich einen O(n^2) Algo einsetze und dagegen einen O(n log n) laufen lasse, mit identischen Daten und identischer Hardware, dann werde ich das merken.

Überlege Dir einfach einmal was eine GPU macht, das sind überwiegend floating-Point Operationen und wenn Du etwas spielst, wirst Du ja wohl kaum merken, wie viele Operationen parallel durchgeführt werden.

Zudem kommt erschwerend hinzu, dass Fließkommazahlen System- & Compiler-abhängig nach diversen Kommastellen zu ungenau werden und somit auch nicht für Entscheidungen geeignet sind, Int-Werte hingegen schon.

Es gibt eine Norm für Fließkommazahlen Gleitkommazahl ? Wikipedia

Du wirst in keinem Rechner auf der Welt eine Zahl mit unendlich vielen Nachkommastellen darstellen können. Das ist ganz einfach durch die Mächtigkeit der endlichen bzw unendlichen Mengen gezeigt. Das geht formal einfach nicht und damit wirst Du niemals irgendetwas exakt darstellen können

Die Zahl Pi auf ein Blatt Papier zu schreiben wäre rein theoretisch möglich, wenn das Blatt Papier kein Ende hätte. Genau darum geht es mir ja.

Nein, das ist vollkommen falsch: Du willst auf einer endlichen Menge (Speicher) eine unendliche lange Zahlenfolge (dezimal) darstellen und wie Du selbst siehst, geht das nicht !

Wenn Du unendlich viel Zeit und unendlich viel Speicher hast, dann kannst Du das machen, da beides aber nicht zutrifft, wird es weder auf dem Blatt Papier noch im Rechner gehen.

Und, wo war hier die Rede von ungenauen Integer-Werten, die Rede war von Fließkommawerten und da schwanken System / CPU / Compiler-abhängig nunmal die Genauigkeiten, dass ist Fakt.

Zitat aus dem Wiki

Strenggenommen sind nur die normalisierten Zahlen aus IEEE 754 Gleitkommazahlen. Die denormalisierten Zahlen sind eigentlich Festkommazahlen; diese Sonderfälle wurden für spezielle numerische Zwecke geschaffen.

Nicht jeder Standard wird / wurde, selbst in aktuellen Compilern, nicht 100%ig implementiert, sonst ließen sich Quelltexte mit diversen Compilern gleich übersetzen. Komisch dabei, dass sich gewisse Werte bei vermeintlich ein-und-derselben Rechnung unterscheiden können.

Dazu einfach mal verschiedene Compiler austesten. Man wird hin-und-wieder Unterschiede bemerken.

Gib einmal dafür einen Beleg an. Java hat wohl eine interne andere Repräsentation. Mal abgesehen von speziellen numerischen Systemen (Cray).

Ich benötige aber Lösungen, die keine Einschränkungen in Sachen Wertebereich und Genauigkeit besitzen. Die einzige Einschränkung soll nur der Speicher darstellen (Cache / RAM / Massenspeicher) und da würden meines Wissens her nur Char-Ketten bzw. String in Frage kommen. Dumm nur, dass sich damit nicht rechnen lässt, nicht direkt.

Warum schaust Du nicht in den Link rein, den Du bekommst

Arbitrary-precision arithmetic - Wikipedia, the free encyclopedia

In computer science, arbitrary-precision arithmetic is a technique whereby calculations are performed on numbers whose digits of precision are limited only by the available memory of the host system. This contrasts with the faster fixed-point arithmetic found in most ALU hardware

Einiges wurde mir beantwortet. Nachwievor ist mir aber unklar, wie der String-Datentyp (C++-Klasse) aufgebaut ist.

Char bzw. WChar haben vordefinierte Größen (8-Bit und 16-Bit), dementsprechend sind Arrays aus Char / WChar entsprechend linear größer.

Du kennst Wikipedia: Zeichenkette ? Wikipedia

Bzw Du kennst den C++ Standard: ISO/IEC JTC1/SC22/WG21 - The C++ Standards Committee

Nur Angaben bzw. Grenzen des Types String kann ich nicht ausfindigmachen.

Hat jemand vielleicht etwas mehr Erfahrung über diesen Datentyp?

Wo liegen seine Schwächen und Grenzen?

Was willst Du hier eigentlich mit der Diskussion bezwecken?

• Willst Du über die Komplexität eines Algorithmus diskutieren? Dann löse dich von der entsprechenden "programmiertechnischen" Ansicht.
  
• Oder soll das eine Diskussion über Datentypen werden? Dann wäre Arbitrary-precision der entsprechende Ansatz
  
• Willst Du über die Darstellungen von Zahlensystem diskutieren? Dann wäre die entsprechenden zahlentheoretischen Überlegungen aus den Körpern im Bereich der linearen Algebra wohl das entsprechende Thema
  
• Willst Du über numerische Lösungen bzw deren Darstellung diskutieren? Dann wirst Du wohl zunächst die numerischen Lösungsverfahren einmal nennen
  
• Willst Du über Mächtigkeiten und deren "endliche" Darstellbarkeit diskutieren? Dann wären aber zunächst diese Mengen zu nennen
  

Deine Diskussion dreht sich immer wieder um den gleichen Punkt, nämlich Deinen Zeichenketten mit denen Du numerische Operationen durchführen willst. Da Du aber weder Dich für die technische Umsetzung noch für die theoretische Sichtweise entscheidest, das Problem auch nicht einmal konkretisierst und auf z.B. gepostete Links nicht eingehst, bleibt die Fragestellung eben offen

Phil

[nic_power]

Hallo,

jede moderne CPU führt sowohl Fliesskomma- als auch Integer Arithmetik komplett in Hardware aus. D.h. eine Nachimplementierung in Sofware bringt absolut nichts (nur einen deutlichen Geschwindigkeitsverlust). In den guten alten Zeiten [tm] konnte man zwar durch eine intelligente Programmierung "per Hand" zwar durchaus was gewinnen, diese Zeiten sind aber vorbei [1].

Gruss

Nic

[1] Beispielsweise war bei einigen SPARC-CPUs die Division von Integer Zahlen nicht in Hardware implementiert. Stattdessen wurde ein Trap ausgelöst über den in die entsprechende Unterroutine verzweigt wurde; in diesem Fall konnte man durch eine Eigenimplementierung unter Umständen (nicht immer!) ein paar CPU Zyklen sparen. In der Praxi führte das dann zu dem interessanten Nebeneffekt, dass Fliesskomma-Divisionen deutlich schneller waren, da diese grundsätzlich von der FPU in Hardware durchgeführt wurden während im Integer-Fall die CPU mühselig "per Hand" rechnen musste.