Ich würd eher formulieren: es war ehedem ein Fehler sie kostenlos verfügbar zu machen und anzunehmen, daß der Verkauf der Controller die Kosten einspielt. Wenn der Nutzer seinen Beitrag auf einem oder anderem Weg nicht leistet gibts eben langfristig auch keine Zeitschrift.
Da ich bei der Erstellung der Artikel auch google benutze weiss ich sehr genau was zu einem Thema "kostenlos" im www verfügbar: meist recht wenig was gut aufgearbeitet ist. Auch wikipedia wird wenig Unterschied machen, weil die Themen zu speziell sind.
/ Fractint entstand 1988 als FRACT386, einem durch Verwendung von / Ganzzahl-Arithmetik ... schnell laufenden Fraktalgenerator.
das den Namen wohl von Fractals hat. Das ist aber nicht das Zahlenformat. Das wurde von TI auf Microcontollern Ende 70er bekannt gemacht, geht aber wohl auf Ende der 60er zurück. Programmiersprachen wie RTL/2 anno 1971 hatten schon int frac und real als Zahlentyp.
Ach ja, das war die erste Amtshandlung 1998, als ich meinen 386SX/20 gegen einen K6-266 ausgetauscht hatte: Erst einmal alle Fractint-Presets ausprobieren. Dann habe ich Povray ausprobiert.
Heutzutage hat man nichts, auf das man sich bei einem Rechnerupgrade freuen kann :-|
Gruß Henning (der sich überlegt, ob er anstatt noch DDR-RAM zu kaufen nicht lieber gleich Mainboard+CPU austauscht und DDR2-RAM anschafft...)
Mir wäre nicht bekannt, daß es *das* Zahlenformat gäbe. Aber Fixkomma-Arithmetik (damit startete der Thread ja) war damals *das* herausstechende Implementierungsdetail, das Fractint zum schnellsten Fraktalgenerator machte.
Mittlerweile haben PC-Prozessoren schnelle Fließkomma- Einheiten. Aber die alten Tricks leben weiter, jetzt in Form von SSE-optimiertem Assemblercode.
Ein Datentyp für gebrochene Zahlen (ich vermute, darauf willst du hinaus) ist eine nette Fingerübung. Hab ich vor Ewigkeiten mal in C++ gemacht.
|> Heutzutage hat man nichts, auf das man sich bei einem Rechnerupgrade |> freuen kann :-|
Ich dachte, das ist Microsofts Marktnische. So kann man sich nach einem auf das Software-Upgrade folgende Hardware-Upgrade freuen, daß die Mühle wieder so schnell läuft, wie sie das vor dem Software-Upgrade tat...
TI hat ihn glaube ich in DSPs im Befehlssatz direkt unterstützt. Und FORTH Inc. verwendet ihn in library für Winkelfunktionen. D.h. es gibt im Bereich embedded Controller Anwender, er ist nur nicht sehr bekannt.
Also, "float" ist das Gegenteil(?) von "fix" und "fix" ist:
formatting link
also ein Zahlenformat, das im Wesentlichen eine äquidistanze Abbildung einer von dir gewählten Anzahl sozusagen physikalisch vorhandener bits auf einen ausgedachten, gewünschten Wertebereich leistet.
So kann man bekanntermassen mit n bit (vieles machen aber auch) auf den Zahlbereich (0..2^n - 1) abbilden. Bei Verwendung von z.B. 8bit/Zahl wäre ein Wertebereich von 256 unterscheidbaren Werten abbildbar oder nutzbar; das ist sicher nix Neues erzählt.
Geht mit gleichem Zahlenformat und gleicher Beispielbitanzahl auch anders, z.B. ein bit als Vorzeichenbit verwendet und schon "verschiebt" sich, so könnte man sagen, der Wertebereich, zum Beispiel auf -127..127 (an der Stelle lauert ein Problemchen, hier durch die 'doppelte Zuordnung zu Null' gelöst, es geht natürlich auch anders --- das alles ist aber sicher auch bekannter 'alter Hut':)
Oder man macht noch ganz andere Sachen und benutzt von den n bit nur einen Teil als "Vorkommastelle", Rest als Bruchanteil. Die dazugehörende Polynom- schreibweise ist sicher bekannt (diese altindische Erfindung, auf neudeutsch: "positional number system"). Beispiel wieder: Nutzt man von 8 bit nur 4 als Ganzzahlanteil und die restlichen 4 bit als 'Nachkommastelle', kann man auf einen Wertebereich von 0..255/16 abbilden (von 0 bis 15.9375), in 1/16tel Schritten u.s.w. (Auch nix neues, steht ja auch prinzipiell im o.a. zitierten wikipedialink unter "Probleme"). Man könnte vielleicht sagen, durch Wahl der Position des festen Kommas lässt sich die "Granulation" der Abbildung variieren.
Für das praktische Programmiererleben geht es auch noch anders, beispiels- weise kann man je zwei Festkommazahlen als einen Bruch festlegen, etwa je 8 oder gar 16 bit für Nenner und Zähler (wieder auf ganz kleine Controller be- zogen, alles natürlich resourcenabhängig). So ließe sich dann auch die im wiki-link unter "Probleme" aufgeführte "nichtabbildbare" Dezimalzahl 0,7 leicht ganz exakt darstellen (diese sogar mit nur je 4 bit für Zähler und Nenner, also '01111010', aber 4 bit für je Zähler/Nenner ist wirklich sehr wenig für praktische Erfordernisse).
Das ist es, was ich mit dem Begriff "skalieren" meinte. Verwende ich gerne, wenn es möglich/sinnvoll ist, oft spare ich mir dann auch die Implementation von gesondert Festkommamultiplikation und Divisionsroutinen (sagenwirmal je
16 bit) und verwende nur eine einzige Skalierroutine (dann 16/8 bit, wenn's sein muss 32/16) --- egal was kommt, Multiplikation oder Division, es wird einfach immer und nur skaliert).
Approximationen gehen ganz nett mit gewünschter Genauigkeit (genauer gewünscht =>
mehr bit benutzen *und* bessere Approximationen): Die Kreiszahl pi lässt sich so mit der bekannten Approximation 355/113 mit Restfehler in der Gegend von
8.5*10^-8 oder sqrt(2) als 19601/13860 (Restfehler~1.8*10^-9) ausdrücken u.s.w.
Ich vermute mal, dass Rafael solche Zahlen/Datentyp mit 'fractint' meint?
Auch wenn der Name "Festkommaformat" den Blick auf die einmal gewählte und dann festliegende Kommastelle lenkt, scheint mir die wichtigste Eigenschaft dieses Formats (na ja, dann besonders seiner Variationen) die Äquidistanz im Wertebereich zu sein (eigentlich sogar das ganze Bündel von Eigenschaften, das die zugrundeliegende lineare Transformation mitbringt); aber insbesondere diese Eigenschaft erlaubt es, "beliebig genau" zu rechnen (also deine freie Wahl von beliebig) bzw. überhaupt erst eine Genauigkeitsabschätzung insbesondere iterativer Verfahren. Was ja schon von gewisser praktischer Bedeutung ist!
Und genau damit hapert es beim Gegensatz (?): Float = Fliesskommazahl oder Gleitkommazahl, also auch ein Zahlenformat.
formatting link
IEEE754 und andere (hatte mal was über ein 'Karlsruher Verfahren' gelesen, wurde wenn ich mich recht erinnere (was ja hierzugroups nachgewiesenermaßen nicht immer...) so in den 60er Jahren entwickelt; Lektüre hatte mich beein- druckt, hatte mir grob gemerkt: viele Vorteile gegenüber IEEE754 aber wie üblich hat sich nicht das bessere Verfahren durchgesetzt... Quelle hab ich leider verbummelt :\)
Generell: Hier wird mit Mantisse/Exponent gearbeitet, dadurch ist die Abbildung natürlich nichtlinear. Ansonsten siehe link.
Gegenüberstellung (hoffentlich) anschaulich:
- 24bit Festkommaformat bildet auf 2^24 Werte (incl. Null) äquidistant ab, d.h. Genauigkeit bzw. "Granulation" ist leicht angebbar. (Bild dazu: "Millimeterpapier"). Auch leicht abänderbar auf Gewünschtes, denn Festkomma- rechenroutinen lassen sich relativ leicht umschreiben/erweitern.
-24bit Fliesskommaformat bildet genauso auf 2^24 unterscheidbare Werte ab (Definitionsbereich: kein Unterschied. Information = Anzahl der bits und jedes kann bekanntlich nur zwei Zustände annehmen) aber aufgrund der nichtlinearen Abbildungsfunktion/Exponentialfunktion sind diese eben nicht äquidistant; der gesamte Wertebereich erscheint im Vergleich zum Fixpunkt- format "ungleichmäßig gespreizt", mehr oder weniger, je nachdem, wie man die beispielhaften 24 bit auf Mantisse und Exponent aufteilt, jedoch bei z.B. gewähltem erweitertem Wertebereich (mehr bit auf den Exponenten) dann auf Kosten der "Granulation" u.s.w. (Bild dazu: "Logarithmisches Papier"). Das führt natürlich praktisch zu Problemen, wenn man hinterher die "Genauigkeit" der Ergebnisse angeben/abschätzen soll (worst case).
Analogie: Die "Genauigkeit", mit der Mensch Werte aus einem Graphen noch ablesen/abschätzen kann hängt bei linearer Skala nur vom 'spitzen Auge' ab (und eine Lupe/Mikroskop ist leicht beschaffbar), bei logarithmischer Skala nicht nur davon sondern auch vom Ableseort selbst (und wenn man Pech hat, rettet einen selbst das Mikroskop nicht so recht).
Diese Nichtangebbarkeit von Fehlergrenzen nach der Rechenoperation ist der Hauptnachteil, meine ich!
Fließkommaroutinen sind darüber hinaus wie schon erwähnt auf kleineren Rechnern zu langsam und nicht so leicht 'mal eben' auf höhere Genauigkeit abänderbar, dazu kommen dann Probleme mit den ganzen Folgeabsonderlichkeiten des Formats wie z.B. der Behandlung diverser NANs (jeweils u.U. in der Ausprägungsvariante propagierend("quiet" oder nicht)/terminierend), Behandlung von "smudge bit" (microchips IEE745 FP-Bibliothek für PICs implementiert es und ignoriert es anschliessend konsequent, auch ne Art da ranzugehen...) und weiteres mehr.
Ich nutze sie auf uC praktisch nicht, schon das Einbinden der Bibliotheken auf den kleinen PICs wäre unsinnig/unökonomisch. Dazu kommt, dass ich sie einfach nicht brauche (und auch nicht mag, wg. fehlender Fehlerabschätzung, Geschwindigkeitsnachteil und 'Sonderbehandlung der Absonderlichkeiten').
Wann man sie nutzt und wann nicht, muss letztlich der Programmierer entscheiden. Problematisch scheint mir, wenn der Programmierer ohne Überlegung entscheidet, sich z.B. sagt: "ich nehme float, dann brauche ich mir keine Gedanken über den Wertebereich zu machen" oder "ich nehme immer Fliesskomma, dann gibt's keine Probleme mit Typkonversion und Compiler-promotion, die Rechner sind doch heute schnell genug.") Ich fürchte, solche Überlegungen kommen vor.
Nebenbei: Multiplikation geht übrigens u.U. im Fliesskommaformat schneller, da sich auf Addition der Exponenten beschränkt (Normalisierung kommt noch u.U. dazu und Typkonversion natürlich, aber letzteres hat man bei Fixformat auch).
Nicht genau so. Integer hat den Dezimalpunkt rechts am Rand des Datenworts, d.h. man hat nur ganze Zahlen grösser Null. Fract hat den Dezimalpunkt links am Rand des Datenworts, d.h. man hat nur Zahlen kleiner Null. Bei 16 Bit: 32767 = 0,999... ca. fast +1,0
-32767 = -1,0 Wenn man zwei Zahlen multipliziert bleiben sie immer >=1,0. Technisch sind die Additions- und Subtraktionsroutinen identisch mit Integer, für Multiplikation und Division sind geringe Erweiterungen nötig. Die Wortlänge ist fest, man skaliert nicht explizit. Man benötigt aber natürlich genügend Dynamik damit kein Überlauf ( eventuell noch Sättigungslogik einbauen ) oder Unterlauf eintritt. Insofern reichen 16 Bit selten, müssten wohl 24 Bit oder 32 Bit sein. Typische Anwendungen waren Regler oder digitale Filter die wegen fester Wortlänge bequemer programmierbar sind.
Ach so. Dann ist das sozusagen der andere Extremfall von Fixkomma: Komma ganz rechts -> Integer, Komma ganz links -> fract, Fixkomma allgemein: m Bits vor dem Komma, k Bits nach dem Komma, m+k = n = irgendeine Breite, die man gescheit bearbeiten kann.
Klaro, die Intelligenz der Programme pro Byte nimmt exponentiell ab ;-)
Na ich weiss nicht. Die Speicherverwaltung unter DOS-Intel war doch Krampf. Ich sag nur, EMM. Da musste man sich ein config.sys/ autoexec.bat mit Menue basteln, welches dann für jede Anwendung das optimale System zusammengenagelt hat. Der sch**ss EMM hat ungefähr einen Faktor vier an Rechenzeit gekostet, war damit dem modernen Management von Firmen voraus ;-).
Heute muss man über so was nicht mehr nachdenken, auch wenn die Kompensation von Intelligenz mit GHz mir irgendwie quer geht. Dafür kann die Mühle jetzt die Eigenwerte/Vektoren einer
300x300 Matrix in 5 Minuten berechnen, 120'000 Jakobirotationen im 300dimensionalen Raum in doppelter Genauigkeit, oder so ähnlich. Und das in, bitte festhalten, Basic (OK, visual Basic). Dafür hättest du vor Kurzem noch ne Cray gebraucht, ne Stunde auf Y-MP oder dergleichen. Mach das mal unter good old DOS, am besten mit einem 386er.
Und in der Zwischenzeit kann man mit dem andern Core noch PSPice raffeln lassen, kein Problem. Mit dem Core2 wär es noch schneller gegangen, aber bei meinem Privatbudget bin ich auf Sonderangebote angewiesen ;-)
Es gibt die C-Programmierer. Die sind von sich überzeugt, dass sie zu den besten gehören. Sicher der beste der Firma, kein Zweifel. Aber es soll noch einige andere geben, ich glaub in Arizona war noch einer, der ist auch ganz gut.
Dann gibt es noch die OO-Programmierer. Die wissen, dass sämtliche Kollegen in der Firma und vermutlich auch weltweit, das OO-Prinzip nicht einmal ansatzweise verstanden haben.
wenn man erstmal in Assembler programmiert hat, dann ist es in der Regel Essig mit abjetctorientierter Programmierung. Unter Assembler muss man, ob man will oder nicht, sich mit dem Prozessortyp auf der Hardwareebene außeinandersetzen.
Nach ein oder zwei Applikationen mit Assembler ist man komplett versaut und versteht nicht mehr, warum die Exe- oder Bin-Dateien von oO-Programmen und anderen Compilern so groß sein müssen.
Gruß
Manfred
--
Wer glaubt, das Zitronenfalter Zitronen falten,
der glaubt auch das Projektleiter Projekte leiten.
Ah geh. Nur Dialekte aus dem frühen Monolithikum (eventuell sogar noch aus der Zeit diskreter Transistoren im Rechner) wurden gross geschrieben.
formatting link
Muss ein sehr altes FORTRAN gewesen sein, noch vor Fortran, so aus Zeiten der 68er Revolution, wo die Hasch-Schwaden so lange durch die Studi-Hirne waberten, bis C rauskam.
Wirth wollte nie aus Pascal eine tatsächlich technisch angewendete Programmiersprache machen. Er wollte vorallem immer das nächste machen. Modula und Oberon. Aber ich bin natürlich Wirth-Fan, allein schon aufgrund seiner Einstellung gegenüber Gehirnerkrankungen. "C++ is an insult to the human brain." "C ist keine ?high level programming language?. C ist ein mit Syntax verzuckerter Assembler."
Huch? Diese Version stammt noch aus Zeiten vor der Mondlandung.
Rekursionen sind der Anfang aller Ineffizienz.
Meine Meinung. Aber moderne Basic Dialekte sind von Pascal kaum mehr zu unterscheiden. Und Fortran kann man auch fast ohne Änderung übernehmen ;-). Und sehr schnell sind die auch; die sind eh nur ein Präprozessor zu einer Geheimsprache, wie C auch. Ich bin auch der Meinung, dass es ein Fehler ist, erste Programmiererfahrungen mit dem, wie du richtig sagst, überaus schrottigen grossgeschriebenen BASIC, jawoll, mit Zeilennummern, zu machen. Die Gehirnverknotungen kriegt man nie mehr weg. Lieber Pascal.
Ob man je Assemler gemacht haben muss, ich schwanke... Jendenfalls wäre es eine Ernüchterung für die jungen Leuts, mal zu sehen, dass so ein Prozessor in seinem tiefsten inneren weder strukturiert noch objektorientiert arbeitet :-]. Sondern eher mit GO TOs, ätsch.
Ich denke, jedes Problem lässt sich mit einer optimalen Programmier- sprache lösen. Jedenfalls vermeide ich hier eine Vergleich eines Forth-Systems mit einem Apple BASIC (grossgeschrieben) "system" (kleingeschrieben). Forth erleichtert sicher den Einstieg in moderne Sprachen wie postscript ;-)).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.