IT Sky Consulting GmbH
Inzwischen haben die Spam-Kommentare in diesem Blog ein Maß erreicht, das sich manuell nicht mehr vernünftig handhaben läßt.
Deshalb setze ich neu Antispam Bee als Spamfilter ein. Im Gegensatz zum von WordPress mitgelieferten Akismet soll dies europäischen Datenschutzvorstellungen gerecht werden.
Ein bisschen Weiterbildung muss wohl immer wieder mal sein und so schaue ich mir jetzt ein oder zweimal im Jahr eine Konferenz von innen an.
Da es ja hier um Speicherung, Verarbeitung und Übermittlung von Informationen geht, habe ich mich etwas eingehender über die Themen im Zusammenhnag mit der Speicherung interessiert und die Frankfurter Datenbanktage besucht. Wie üblich gab es jeweils noch ein paar Stände, an denen man sich im Rest der 15-min-Pausen noch unterhalten konnte.
Interessante Themen waren „BigData“ und dessen Abgrenzung, die Frage, für welche Zwecke man klassische transaktionale relationale SQL-Datenbanken einsetzt und für welche Zwecke man sich für die vielfältige Welt der „NoSQL“-Datenbanken interessiert und vielleicht für die Lösung fündig wird und wie die Anbieter der klassischen Datenbanken versuchen, auch diesen Bereich abzudecken. Bekommt DB2 eine MongoDB-kompatible Schnittstelle, so dass man für Mongo-DB entwickelte Software mit DB2 statt MongoDB betreiben kann? Oder wie integriert man die verschiedenen Welten miteinander, wenn eine Aufgabenteilung sinnvoll ist?
Datenbank-Security ist ein interessantes Thema gewesen, sowohl in Vorträgen als auch bei Ausstellern. Welche Wege bestehen für Angreifer, die Daten zu lesen oder gar zu verändern und wie kann man das unterbinden oder doch zumindest so weit erschweren, dass das Risiko sehr klein wird?
Wie sieht es mit Clustering aus? Wie kann man die Performance optimieren, wo sind die Grenzen? Das können alle „großen“ Datenbanken, auch mySQL und mariaDB. Aber es gibt verschiedene Wege. Was sind die neuen Features der Datenbanken? Oracle hat zum Beispiel so etwas wie Virtualisierung vorgesehen, was es endlich ermöglichen soll, mit vertretbarem Ressourcen-Aufwand mehrere Datenbankinstanzen zu haben, indem diese als eine Art virtuelle Instanzen in einer Masterinstanz laufen.
Wie nutzt man heutige Hardware optimal oder wie investiert man in Hardware am sinnvollsten, um performante DB-Infrastruktur zu erhalten?
Es war also recht interessant…
Wofür braucht man überhaupt Zufallszahlen? Es gibt recht viele probabilistische Algorithmen, die besser funktinonieren, wenn man „gute“ Zufallszahlen hat. Besonders wichtig sind diese aber auch in der Kryptographie, zum Beispiel zur Generierung von Schlüsseln.
Die Qualität der Zufallszahlen ergibt sich aus der Vorhersehbarkeit des nächsten Werts. Wenn dieser z.B. mit heutigen Mitteln aus bekannten Werten berechnet werden kann oder nur schon dieser berechnete Wert mit höherer Wahrscheinlichkeit zu erwarten ist als bei Gleichverteilung, dann sind die Zufallszahlen nicht mehr optimal. Man kann dann zum Beispiel den „private key“ eines Schlüsselpaars erraten und dadurch die Sicherheit des Verfahrens vermindern.
Nun ist die Frage, ob es wirklichen Zufall in der Natur gibt. Nach heutigen Erkenntnissen glaubt man das und findet als Beispiel den radioaktiven Zerfall. Also müsste nur jeder Rechner einen „Radiumkarte“ eingebaut bekommen und schon hätte man überall gute Zufallszahlengeneratoren zur Verfügung. Doch es gibt einige andere Effekte, die man nutzen kann, z.B. Zenerdioden oder den Luftdruck. Radiowellen aus dem Weltall wären sicher auf den ersten Blick auch gut, aber da diese für jeden empfangbar sind, ist es sehr schwierig, eine Vorhersehbarkeit der Zufallszahlen auszuschließen. Zenerdioden eignen sich wohl auch ganz gut. So kann man recht gute Zufallszahlengeneratoren auf die CPU einbauen: RdRand (en.wikipedia.org) oder rdrand (Intel)
Ist das Thema damit gegessen? Vielleicht, zumindest für viele Anwendungszwecke. Vielleicht traut man dem nicht und braucht dort, wo es wirklich darauf ankommt, noch bessere Verfahren? Auf jeden Fall wird es noch eine Weile dauern, bis man das wirklich verwenden kann. Heute haben das neue Intel-CPUs, wann haben es auch CPUs anderer Hersteller? Wann wird das durch die verschiedenen Betriebssysteme genutzt? Mindestens ein paar Jahre dürfen wir uns noch darauf freuen, dass dieses Feature breit verfügbar ist.
Linux hat einen Zufallszahlengenerator auf OS-Basis, der als /dev/random ansprechbar ist. Dieser nutzt „Zufälligkeiten“ wie Tastatureingaben, Mausbewegungen, vielleicht auch Plattenbewegungen u.s.w. aus. Vielleicht nicht ganz so gut wie rdrand, aber dafür schon lange verfügbar. Vielleicht haben andere Betriebssysteme ähnliche Möglichkeiten.
Wie funktioniert das? Wenn man teilweise zufällige Informationen hat, dann lässt sich das nächste Stück mit einer gewissen Wahrscheinlichkeit vorhersagen. Typisches Beispiel wäre etwa ein Text, der eingegeben wird. Der kann einer abstrakten Sprache angehören, z.B. einer natürlichen Sprache, einer Programmiersprache (mit einer natürlichen Sprache für die Kommentare) oder so etwas. Wenn das einigermaßen fehlerarm eingegeben wird, dann lässt sich ein unvollständiges Wort oft auf nur wenige Arten vervollständigen, so dass von den vielen möglichen Zeichen einige wenige wahrscheinlich sind. Wenn man mal von einem 8-bit-Zeichensatz ausgeht, bringt dieses eine Zeichen vielleicht nur etwa 1 Bit an Information, wenn etwa zwei Vervollständigungen sehr wahrscheinlich sind, statt 8 Bit. Dieses eine Bit wäre idealerweise die Zufälligkeit, also ein Zufallsbit, wenn man es schafft, das herauszudestilieren.
Nun ist es bei eingegebenen Texten etwas schwieriger. Wenn das bekannte Texte sind, etwa weil es abgeschrieben wird, oder wenn es ein ehemaliger Minister schreibt, sogar kopiert wird, dann besteht die Zufälligkeit nur noch in der Auswahl der passenden Texte, aber auch bei selbst geschriebenen Texten schränkt der Kontext ein, was passen würde und was wahrscheinlich ist. Hinzu kommt das Wissen des Schreibers, dessen „Fingerabdruck“, der sich auch in den verfassten Texten (oder Programmen oder was auch immer geschrieben wird) ausdrückt. Vielleicht ist das Wissen eines Menschen groß genug, um für viele Jahre oder sogar ein Leben lang Texte zu produzieren, die genug Zufälligkeit enthalten, aber wenn keine neue Information durch Kommunikation einfließt, ist das doch zu hinterfragen. Aber viele von uns arbeiten in Bürotätigkeiten, die in irgendeiner Form überwiegend darin bestehen, zu kommunizieren oder doch zumindest etwas einzugeben oder zu schreiben. Vielleicht gibt es dabei gänzlich unkreative Tätigkeiten, wo man etwas ausfüllen muss und genau eine Lösung richtig ist. Aber alle auch nur teilweise kreativen Tätigkeiten produzieren Information, die ohne diese nicht da war und würden sich somit als Basis für die Zufallszahlengenerierung grundsätzlich eignen.
Wir brauchen vielleicht den Kontakt zu unseren Mitmenschen, um neue Ideen zu entwickeln. Und nun fließt die aufgenommene Information natürlich wieder ein. Deshalb ist die Zufälligkeit der geschriebenen Textinhalte nicht leicht abzuschätzen und sie sinkt vielleicht um eine Größenordnung, wenn man verschiedene der hier angesprochenen Aspekte zu fassen bekommt oder ignoriert, weil man sie für nicht fassbar hält. Nun kann man die Texte aber verlustfrei komprimieren. Wenn man viel darüber weiß, was wirklich die reine Information (oder der Zufallsgehalt) ist, auf eine Größe, die knapp über diesem Informationsgehalt liegt. Nun kann man auch geschickte „Hash-Codes“ verwenden, die aus den Texten Bytesquenzen generieren, die etwas kleiner sind, als der Informationsgehalt. Wenn das gut gemacht wird, ist das ein brauchbarer Zufallszahlengenerator, der aber für kryptographische Anwendungen sofort einiges an Wert verliert, wenn man aus der Kommunikation der Person nach dem Verfassen des Textes oder gar aus der direkten Verwendung des Textes Rückschlüsse auf diesen ziehen kann.
Wenn der Text öffentlich oder teilweise öffentlich zugänglich wird, zum Beispiel auf einer Webseite erscheint, wie der Text, der hier gerade geschrieben wird, dann besteht die Zufälligkeit nur noch in der Auswahl des Textes von den Milliarden Webseiten, die es gibt, was aber nur noch maximal ein paar Dutzend Bits sind. Und wer will schon eine kreative Tätigkeit nur für die Zufallszahlengeneration ausüben, ohne dass die eigentlichen Ergebnisse dieser Tätigkeit sinnvoll verwendet werden? Und wer will das gar noch bezahlen?
Die Zeitabstände zwischen den Tastatureingaben sind sicher auch so etwas wie ein Fingerabdruck, was individuell den Schreiber erkennen ließe, aber die Zufälligkeit dieser Zeiten lässt sich viel besser nutzen, weil wir das nicht verwenden, um Information zu transportieren. Ich werde mich also auch nicht erinnern, welche Zeitabstände ich zwischen den Zeichen hatte, außer dass der Schreibrhythmus natürlich beim nächsten Mal ähnlich (aber nicht identisch) sein wird. Und die Zeitabstände sind auch nicht auf dieser Webseite nachlesbar.
Diese Fotos mit Negativen, Dias und auf Papier sind heute nicht mehr „in“ und man sieht es alten Fotos an, dass die Farben schlechter werden.
Die Digitaltechnik löst viele Probleme, man kann Bilder ohne Farbverlust beliebig lange aufbewahren und muss beim Abdrücken nicht mehr an den Preis des Filmmaterials denken, weil das einzelne Foto ja fast nichts kostet. Ein bisschen schon, weil die Kamera verschlissen wird, die Speicherkarten nur begrenzt viele Schreibzyklen mitmacht und sogar noch Strom verbraucht wird, aber das kann man alles gegenüber dem Preis von Filmmaterial vernachlässigen. Solche Fragen stellen sich zum Teil auch bei der Video- und Audioaufzeichnung, wo sich lange Zeit analoge magnetische Aufzeichnungsverfahren etabliert hatten, oft gerade dort, wo die Qualitätsanforderungen nicht maximal waren. Ich bleibe mal hauptsächlich bei den Fotos und gehe kurz darauf ein, wenn die anderen Formate spezielle Aspekte berücksichtigt haben sollten.
Aber wie sieht es nun mit der Lebensdauer und den Kosten der langfristigen Archivierung bei Multimediadaten aus? Zunächst braucht man sehr viel Platz, aber bei jedem Baumarkt, Supermarkt und auch im Internet kann man für wenig Geld solche USB-Festplatten mit einigen Terabyte Kapazität kaufen. Also kopiert man die Dateien da drauf und solange es nur wenige sind, hat man dafür Platz und findet die Sachen auch wieder. Oder man speichert die Bilder in der Cloud, wobei dort viele Terabyte auch viel Geld kosten. Wird sich das ändern? Vielleicht, aber vielleicht stoßen wir auch an technologische Grenze, was die Aufzeichnungsdichte betrifft und können keine großen Preissenkungen für Plattenplatz mehr erwarten, bis einmal völlig neue Technologien die magnetische Aufzeichnung ersetzen und vielleicht auch neue Möglichkeiten bieten.
Aber wie sieht es mit der Lebensdauer solcher Multimedia-Dateien aus? Ich glaube, dass die im Durchschnitt sehr viel kürzer ist als bei den alten Verfahren. Was kann alles schief gehen:
* Die Formate. Ein proprietäres Format schafft eine Abhängigkeit von einem Software-Anbieter, den es in einigen Jahren vielleicht nicht mehr gibt oder der kein Interesse mehr hat, das frühere Format zu unterstützen.
* Datenverlust durch Festplattenschaden: Gelegentlich geht eine Festplatte kaputt, was zu Datenverlust führen kann. Backup machen wir alle regelmäßig, aber an dem Tag vor dem Plattencrash hat man es vergessen oder stellt fest, dass die Backups gar nichts kopiert haben oder nicht lesbar sind.
* Datenverlust durch versehentliches Löschen
* Man findet die richtige Datei nicht mehr
* Physikalischer Verlust des Mediums durch Feuer, Diebstahl, Wasserschaden o.ä., aber das kann mit Negativen und Dias auch passieren.
Alle diese Punkte lassen sich lösen, wenn man bereit ist, den Aufwand zu treiben.
So sinnvoll es sein kann, bei Fotos dir proprietären „raw“-Dateien aufzubewahren, so wichtig ist es, bei Bildern, die wirklich wichtig sind, zusätzlich oder stattdessen ein Format aufzubewahren, das standardisiert ist und für dessen Verarbeitung es Open-Source-Software gibt, auch wenn man diese heute nicht verwendet. Wer in 20 Jahren ein Nikon- oder Canon-Raw-Format von 2013 noch lesen kann, ist nicht sicher. Aber png und dng werden wahrscheinlich in 20 Jahren noch lesbar sein. Und auch wenn man heute lieber Photoshop als Gimp oder lieber Lightroom als Darktable verwendet, ist für die langfristige Lesbarkeit von Formaten hilfreich, dass es Opensource-Software gibt, die diese Formate verarbeiten kann und aus deren Quelltexten sich auch in 20 Jahren noch Software erstellen lässt, die das kann, selbst wenn es Photoshop und Lightroom dann nicht mehr geben sollte.
Man muss wohl ein regelmäßiges Backup der Bilddateien machen, um eine gute Chance zu haben, diese in 20-30 Jahren noch zu haben, auch wenn sich absolute Sicherheit nicht erreichen lässt, nicht einmal mit Negativen und Dias. Wenn man nun aber eifrig fotografiert, filmt,…. kommen jedes Jahr Unmengen an Daten dazu. Das heißt, dass der Aufwand, den man so pro Monat für Backups treiben muss, auch immer größer wird. Nur mal als Überlegung: Sagen wir die Bilder sind als DNG etwa 100 MB groß, denn wir wollen ja mit der neuesten Megapixel-Technlogie fotografieren, wenn nicht heute, so doch sicher bald innerhalb der nächsten 20-30 Jahre. Man verwendet 2TB-USB-Festplatten und macht 20’000 Fotos pro Jahr. Da passt ein Jahr auf eine USB-Platte. Das geht noch, aber mit der Zeit hat man eine ganze Sammlung davon und muss wissen, welches Bild wo ist und noch ab und zu Backups machen. Die Platten werden natürlich noch größer, die Bilder aber auch.
Wenn man aber sortiert, also beim Fotografieren ein bisschen nachdenkt, wie wenn man Filmmaterial benutzt, dann die schlechten Bilder löscht oder zumindest nur als JPG aufbewahrt, um aus den Fehlern zu lernen, dann kann eine solche USB-Platte für viele Jahre reichen und der ganze Vorgang bleibt beherrschbar.
Bei Videos ist das alles wohl noch schwieriger. Die Formatvielfalt ist unübersichtlicher, Videos belegen mehr Plattenplatz und es gibt auch sehr viel mehr proprietäre Formate. Man sollte sich aber auch gut überlegen, bevor man auf ein Format mit weniger Information (verlustbehaftete Kompression, Verringerung der Auflösung) wechselt. Interessant ist es auch, wenn man für ein größeres Projekt eine Video-Software beschafft, bei der man den Zugriff auf das Material verliert, sobald man aufhört, die Lizenzen dafür zu zahlen.
Woher weiß man, was in der Datei drinsteht? Sprechende Dateinamen können helfen, aber reichen nicht unbedingt aus. Fotos kann man immer noch recht schnell anschauen, aber wenn es viele sind, dauert das schon zu lange. Bei Videos ist das noch viel schlimmer. Deshalb ist gute Metainformation hilfreich, nach der man suchen kann, also Information, der beschreibt, was auf dem Bild, dem Video, der Tondatei o.ä. drauf ist, am besten strukturiert.
Ruby 2.0 ist seit 2013-02-24 verfügbar:
Rechnen ist ja das, was wir mit den Computern so machen, deshalb heißen sie ja auch Rechner.
Und zum Rechnen brauchen wir die numerischen Typen andauernd, also kann das wohl kein Problem sein, oder?
Es hängt ein bisschen davon ab, was man sich unter numerischen Typen vorstellt. Fließkommazahlen oder irgendeine Art von Ganzzahlen können fast alle, manche sogar beides. Gute Ganzzahlentypen sind aber leider nur selten verfügbar, da die Frage des Überlaufs oft schlecht gelöst ist. Weitere interessante numerische Datentypen sind rationale Zahlen, komplexe Zahlen und Festkomma-Dezimalzahlen.
Doch wie sieht es mit der Integration in die Sprache aus? Man möchte gerne so etwas wie
a = b*c + d*e
schreiben und meint damit, dass eine Zuweisung an a erfolgen soll, die den Wert (b*c) + (d*e) beinhaltet. Wegen „Punktrechnung vor Strichrechnung“ sollte man die Klammern aber weglassen können. Im Fall von Sprachen wie Lisp oder Forth, die eine völlig andere Syntax verwenden, passt diese Infix-Schreibweise natürlich nicht ins Bild und man kann diese Anforderung nicht sinnvoll stellen. In Lisp mit der Präfix-Schreibweise wäre es so etwas wie:
(setq a (+ (* b c) (* d e)))
und in Forth mit seiner Postfix-Schreibweise wäre es etwa so etwas:
b @ c @ * d @ e @ * + a ! .
C, Perl, Ruby, C++, Java, C#, JavaScript, Lua und vielen anderen funktioniert das mit den eingebauten Datentypen recht gut, aber sobald man eigene numerische Datentypen einführt, braucht man so etwas wie „Operator überladen“, was z.B. Lua, Perl, Ruby, C++ und C# können, aber Java und JavaScript nicht. Deshalb fängt man in Java an, für BigDecimal, BigInteger oder eigene Datentypen so etwas wie
a = b.multiply(c).add(d.multiply(e))
zu schreiben, was praktisch unlesbar und damit fehleranfällig ist. Vielleicht kann man sich mit einem Präprozessor behelfen, aber es bleibt ein Gebastel.
Ein anderer Aspekt ist am Beispiel von Java ganz gut zu sehen. Dort soll ja „alles“ ein Objekt sein. Man kann schön Interfaces, Klassen und Methoden schreiben und Verwenden, die sich auf Objekte verlassen, wie z.B. Map. Nun sind diese „primitiven“ Typen leider keine Objekte und man muss diese Wrapper-Klassen wie Integer, Double, Long, Boolean u.s.w. verwenden, was leider umständlich ist, zumal man mit den Wrappern die numerischen Fähigkeiten nicht mehr zur Verfügung hat. Scheinbar wurde das durch Autoboxing und Autounboxing gelöst, aber ich glaube, dass diese Erweiterung mehr Probleme geschaffen als gelöst hat. Nur als Beispiel, was bedeutet
x==y
wenn x und y long oder Long sind? Mal wird die Objekt-Identität und mal der Wert verglichen und ich vergesse immer, ob unboxing oder boxing zum Zuge kommt, wenn man dabei long und Long zusammenkommen lässt. Man kann aber einige spezielle Collection-Klassen finden, die auf Primitive zugeschnitten sind und dadurch ohne Boxing und Autoboxing auskommen, schneller laufen und weniger Speicher verbrauchen. In erster Linie bleibt es aber umständlich, weil man immer wieder diese Sonderfälle für Primitive und zum Teil auch Arrays berücksichtigen muss.
Jeder hat es schon gesehen, dass Leute, die oft gar nicht in direkt Informatik arbeiten, sich mit Tabellenkalkulationen anfreunden und dort sogar in recht kurzer Zeit sehr nützliche Dinge zustande bringen. Solange dies Dinge sind, die nur für eine Person nützlich sind, sind alle glücklich und jeder hat seine eigenen Tabellen, man tauscht sie vielleicht sogar aus (natürlich nur innerhalb der eigenen Organisation).
Wenn die Tabellen aber richtig gut sind, dann baut man sie irgendwann in Geschäftsabläufe ein. Irgendwelche Daten werden an Mitarbeiter XY gemailt, der baut sie in seine Tabellenkalkulation auf Laufwerk C: ein und mailt das Ergebnis weiter. Schön, dass wir EMail haben und auch große Attachments möglich sind. Blöd ist nur, wenn XY mal krank ist oder Ferien hat oder gar die Tätigkeit wechselt. Solange es noch in derselben Firma ist, funktioniert noch alles weiter wie gehabt, aber auch das kann mal vorbei sein. Oder das Laufwerk C: kann man unter Gedächtnisverlust leiden, warum auch immer. Deshalb ist man so professionell geworden, die Tabellenkalkulationsdatei auf dem Netzwerklaufwerk M: statt auf Laufwerk C: zu haben. So wird sie beim Backup berücksichtigt und XYs Stellvertreter kann sie dort auch finden, wenn XY mal nicht erreichbar ist. Vielleicht wird auch ein CMS oder ECM statt des Netzwerklaufwerks eingesetzt, was schon etliche Nachteile der Lösung eliminiert.
Weil das alles immer noch ein chaotisches Gebastel ist, muss aber eine richtige Lösung her. Eine „Enterprise“-Lösung. Man kauft eine professionelle Software oder entwickelt sie selber oder lässt sie entwickeln. Allein die Entwicklung oder die Integration der eingekauften Lösung brauchen schon mehr als zehnmal soviel Zeit wie XY insgesamt benötigt hat, um seine Lösung zu entwickeln, obwohl diesmal Informatikprofis am arbeiten sind. Vielleicht sollten wir all unser Fachwissen vergessen und dadurch die Produktivität um Faktor 10 steigern?
Zunächst einmal muss man die beiden Lösungen vergleichen. Was man gewonnen hat, ist durchaus relevant, z.B.:
Lohnt sich dafür der zehnfache Aufwand? Wenn die Applikation wichtig ist, normalerweise schon. Und die Tabellenkalkulationslösung ist wahrscheinlich sogar hilfreich gewesen, weil sie dazu beigetragen hat, wirklich gut zu verstehen, was man mit der Applikation tun will.
Aber die Frage, ob die Entwicklung der Applikation nicht zu lange dauert, ist schon berechtigt. Gewonnen hat man in diesem Fall schon, dass gut bekannt ist, was entwickelt werden soll. Aber das „wie“ lässt noch viele Möglichkeiten offen. Ist der Entwicklungsprozess gut genug? Werden die Leute optimal eingesetzt? Können sie an der Aufgabe arbeiten oder hauptsächlich an administrativen Aufgaben? Ja, das ist eine sehr berechtigte Frage, vielleicht schreibe ich dazu mal etwas. Wird die richtige Architektur eingesetzt? Ist die Lösung zu kompliziert? Oder zu einfach (und funktioniert nachher doch nicht so)? Wird die richtige Technologie eingesetzt? Ich finde es sinnvoller, ab und zu etwas neues zu lernen als den „goldenen Hammer“ zu pflegen, mit dem jede Schraube wie ein Nagel aussieht.
Konkreter: Für eine Applikation, deren Funktionalität in eine Tabellenkalkulation gepasst hat, ist so ein klassischer „Enterprirse-Stack“ mit Java, EJB, Oracle oder DB2, Weblogic u.s.w. sicher fast immer zu aufwendig.
Ruby wird 20 Jahre alt:
http://ruby20th.herokuapp.com/
Wie ärgerlich ist eigentlich die Tatsache, dass Lua und JavaScript keine „int“s kennen und man stattdessen Fließkommazahlen („double“) verwenden muss?
Natürlich fühlt es sich völlig falsch an und ich möchte die Entscheidung, nur diese 8-byte-Fließkomma-Zahlen als numerischen Typ zu unterstützen, nicht gutheißen.
Aber was bedeutet das nun genau? Bekommen wir nun plötzlich irgendwo 7.999999999 statt 8?
Die Fließkommazahlen sind heute zum Glück standardisiert und fast jede Implementierung hält sich einigermaßen an diesen Standard. Es gibt eine 4-Byte-Variante und eine 8-Byte-Variante. Die 4-Byte-Variante ist nur dann sinnvoll, wenn man dem Entwickler die Wahl lässt, und fast jeder Entwickler nimmt „zur Sicherheit“ lieber die 8-Byte-Variante. Diese Fließkommazahl sieht nun ungefähr so aus:
1 Bit ist das Vorzeichen
11 Bits drücken den 2er-Exponenten aus
52 Bits drücken die Mantisse aus, dazu kommt als 53stes eine führende 1, die man nicht speichern muss, weil sie ja immer da ist.
Damit kann man die ganzen Zahlen von 
bis 
exakt ausdrücken und hat damit etwas, was etwa 54-Bit-Ganzzahlen entsprechen würde. Rein informationsmäßig ist das eine zusätzliche Bit im Vorzeichen und das andere im 2-er-Exponenten codiert. Wenn man also nur addiert, subtrahiert und multipliziert und dabei immer im Bereich von bis bleibt, kann man exakte Ergebnisse erwarten. Natürlich ist es langsamer, aber auch das ist bei heutigen CPUs, die schnelle Fließkommaoperationen seit etwa 20 Jahren standardmäßig (und vorher gegen Aufpreis) in der Hardware eingebaut haben, nicht so tragisch. Wie ist es mit den ungenutzten Bits? Normalerweise stören die nicht, aber wenn man Applikationen entwickelt, die sehr speicherintensiv sind, kann auch so etwa ausnahmsweise mal relevant werden.
Ärgerlicher ist da schon die Division. Hat man bei ints so etwas wie „/“ für die Division mit Abrundung und „%“ für den Rest, wird bei Fließkommazahlen mit „/“ wirklich dividiert und eine neue Fließkommazahl berechnet. Wie rundet man hier ab, um das „int-/“ und das „int-%“ zu bekommen? Es sollte dabei ja trotzdem noch das 6.9999999999999 zu 7 gerundet werden.
Ungefähr so etwas könnte funktionieren:
def divmodf(x, y)
xf = x.to_f
yf = y.to_f
df = if (yf < 0) then
-0.2
else
0.2
end
qf = (xf + df) / yf;
q = qf.floor
r = (yf*(qf-q)).round(0)
return q,r
end
Das ist jetzt in Ruby geschrieben, aber es würde natürlich ähnlich in Lua oder JavaScript funktionieren.