20 Jahre Computermuseum der Universität Stuttgart

Zum 20. Jahrestag des Computermuseums der Universität Stuttgart hat das Informatik Forum Stuttgart (infos) zu einem Festkolloquium eingeladen. Der Leiter des Computermuseums, Klemens Krause, hat in einer Live Präsentation einen 50er Jahre Röhrencomputer LGP-30 vorgestellt. Er besteht aus 113 Röhren und 700 Germanium-Dioden und besitzt einen Trommelspeicher von 4096 Worten à 31 Bit. Der Ton der Aufnahme ist leider nicht besonders gut, da ich nur ein Smartphone zur Verfügung hatte.

Ein kleines JavaScript Spielprogramm

In der letzten Woche habe ich durch Zufall ein JavaScript Spielprogramm gefunden. Die Spielidee ist einfach: es gibt ein Array von verschieden farbigen Kacheln. Der Anwender kann diese paarweise auswählen – was dazu führt, dass die beiden Kacheln vertauscht werden. Dabei können aber nur direkt benachbarte Kacheln getauscht werden. Wenn es mehr als 3 zusammenhängende gleichfarbige Kacheln in einer Zeile oder Spalte gibt, war der Spielzug gültig und es werden einem Punkte dafür gut geschrieben.

Das Original war mit einer recht kurzen Zeitschranke versehen. Ich wollte aber wissen, ob das Spiel zwingend irgendwann zum Ende kommt, weil es keine weiteren Kombinationen mehr gibt, die durch einen einfachen Austausch zu erreichen wären. Mein erster Versuch dazu war, dass ich im Browser versucht habe, den Timer stillzulegen. Das Programm hat sich aber gegen Veränderungen gewehrt, deshalb habe ich mich entschlossen, es gleich nachzuprogrammieren.

Meine Version hat keine Zeitbeschränkung und zudem auch eine Hilfefunktion. Wenn man an einem Punkt nicht weiter weiß, kann man sich über eine Tipp Funktion eine Möglichkeit markieren lassen – falls es noch eine gibt. Ich habe noch nicht beobachtet, dass die Tipp-Funktion eine Möglichkeit übersehen hat. Schon nach kurzer Zeit hat sich gezeigt, dass es im Allgemeinen ein Ende gibt. Manchmal schon nach 200 Spielzügen. Ich habe aber auch schon 1500 Spielzüge überstanden, ohne dass ein Ende absehbar war. Ich gehe aber davon aus, dass sich jedes Spiel irgendwann in einer Situation befindet, in dem es keine weiteren gültigen Spielzüge mehr gibt.

Das Spiel ist komplett in html / CSS / JavaScript programmiert. Es gibt noch nicht mal eine Image Datei. Es wird auch kein Framework, wie z.B. JQuery, verwendet. Ich wollte auch mal ausprobieren, wie gut man zu Fuß mit Animationen zurecht kommt. Das eine oder andere könnte man mit CSS Animationen noch besser machen. Für mich war der aktuelle Stand aber gut genug.

Die Animationen, wie z.B. das Verschieben der Kacheln sowie ein- und ausblenden des Hilfe-Dialogs werden über Timer-Callback Funktionen durchgeführt. Das Skript ist relativ kurz und hat deshalb nur drei Klassen: das Spiel-Objekt, das Gitternetz im Spiel und ein Kachel-Objekt. Insgesamt etwa 100 Zeilen CSS für die Formatierung und 600 Zeilen JavaScript für die Spielausführung.

THM-Flip: hier geht’s zum Spiel

ThmFlip

Ultraschall Sensor

Ich wollte schon seit längerer Zeit mal etwas mit einem Ultraschall Sensor machen. Also habe ich mir bei Reichelt kurzerhand ein Sender – Empfänger Paar gekauft und mal an meinen Signalgenerator sowie Oszilloskop angeschlossen.

Meine naive Annahmen, dass ein Ultraschallempfänger so eine Art Mikrofon für hohe Frequenzen und ein Sender ein Lautsprecher für hohe Frequenzen sei, hat sich aber schnell zerschlagen. Naiv deshalb, weil ein Blick in das Datenblatt zeigt, dass beide Komponenten relativ Schmalbandig um die 44 kHz arbeiten. Das deutet darauf hin, dass hier stark mit Resonanzeffekten gearbeitet wird.

Am Sender reicht schon ein Burst mit nur einer Periode aus, um am Empfänger ein breites Signal zu erzeugen.

Distance 10cm

Distance 5cm

Da ich nicht weiß, wo innerhalb des Gehäuses der Sender bzw. der Empfänger liegt, habe ich bei der Distanzmessung eine Unsicherheit von etwa 5 mm. Da ich auf der Empfängerseite keinen klaren Startpunkt habe, ist es auch schwierig, die Laufzeit exakt zu bestimmen. Am Genausten wäre es vermutlich, wenn man die Hüllkurve ermittelt und dann das Maximum sucht. Allerdings vermute ich, dass hier dann eine Änderung der „Lautstärke“ zu erheblichen Messfehlern führt.

Da das Empfangssignal im Ruhezustand erstaunlich stabil ist, verwende ich den ersten sichtbaren Ausschlag als Messpunkt. Bei Abständen von (ca.) 25, 20, 15, 10 und 5 cm komme ich auf Zeitunterschiede von jeweils ca. 150 Mikrosekunden. Das würde eine Schallgeschwindigkeit von 330 m/s ergeben. Die Abweichung zur echten Schallgeschwindigkeit liegt bei dieser einfachen Ablesemethode im erwarteten Rahmen.

Ich werde in den nächsten Tagen wohl eine Umstellung auf einen Microcontroller machen. Dann ist der Ablesezeitpunkt weniger willkürlich. Zudem kann kann man bei Laufzeiten im einstelligen Millisekundenbereich durchaus 100 Messungen pro Sekunde durchführen und einen Mittelwert bilden. Mal sehen, ob ich dann genauere Daten bekomme.

Besuch im IBM Computermuseum in Böblingen

Ich war heute auf einer IBM Veranstaltung in Böblingen. Am Ende hatten wir das Glück, dass wir noch die nicht öffentliche Computersammlung besichtigen konnten. Leider kam meine einfache Handy-Kamera nicht besonders gut mit der Beleuchtung zurecht, aber es sind doch ein paar brauchbare Bilder entstanden.

Fließkommazahlen und unerfahrene Programmierer

Gestern habe ich auf slashdot.org ein Beitrag eines Programmierers gesehen, der sich darüber beklagt hat, dass von ihm verlangt wurde, eine Steuerberechnung mit JavaScript zu entwickeln. Schließlich kennt JavaScript nur Fließkommazahlen und „jeder“ weiß, dass man damit keine kaufmännischen Anwendungen schreiben kann.

Diese Meinung ist weit verbreitet – gerade in diesen Kreisen. Das weckt bei mir den Argwohn, ob im Bereich kaufmännischer Software verstärkt mäßig erfahrene Programmierer unterwegs sind? Und aus solchen Vorurteilen und mangelnden Wissen resultieren dann BCD Arithmetik-Libraries und BCD Befehle in Prozessoren (BCD = binary coded decimal – zwei Dezimalziffern 0-9 und 0-9 in einem Byte).

Das ist totaler Unfug und zeigt nur einen erheblichen Mangel an (mathematischen) Wissen.

Mythos 1: im Binärsystem kann man Zahlen nicht exakt darstellen, im Dezimalsystem schon.
Fast völliger Unsinn. Es wird immer der Wert 0.1 (als Bruch: 1/10) als Beispiel genommen. Dieser Wert ist im Binärsystem tatsächlich nur gerundet darzustellen, da er dort eine unendliche Periode besitzt. Aber solche Zahlen gibt es im Dezimalsystem auch: 1/3. Dieser Wert lässt sich Dezimal auch nur gerundet darstellen. Prinzipiell gilt für (teilerfremde) Brüche der Art p/q, dass sie eine periodische Darstellung haben, wenn q Primfaktoren besitzt, die in der Basis nicht vorkommen. Das Binärsystem hat nur den Primfaktor 2 in der Basis – wirklich nicht üppig. Im Dezimalsystem sind es 2 und 5 – auch nicht wirklich besser. 1/3 – 1/7 – 1/11 – 1/13… verdammt viele Brüche erzeugen in beiden Systemen eine periodische Darstellung.

Das Problem ließe sich hier noch lösen, indem man mit Rationalen Zahlen arbeitet. Das hat aber Grenzen, denn man kann niemanden eine Rechnung schicken, auf der 47/11 Euro gefordert werden. Auf der Rechnung werden also doch nur 4,272727272727272727272727272727… Euro oder gerundet 4,27 Euro auftauchen.

Mythos 2: mit Fließkommazahlen kann man nicht Cent-genau rechnen
Eine double Fließkommazahl (wie sie z.B. von JavaScript verwendet wird) besitzt über 50 Bit für die Mantisse. Das sind mehr als 15 Dezimalstellen. Damit kann man mehr als nur das gesamte Geld dieser Welt auf einen Cent genau darstellen. Man muss lediglich darauf achten, den Fließkommawert bei der Ausgabe zum nächsten Cent hin auf- oder abzurunden.

Wenn die NASA mit Fließkommaberechnungen Satelliten auf Milliarden Kilometer genau steuern kann, dann sollte auch ein mäßig begabter Programmierer in der Lage sein, eine Leberwurst und 200 Gramm Butter abzurechnen. Das ist keine Raketenwissenschaft.

Mythos 3: wenn ich Integer-Werte für Cent-Beträge verwende, habe ich keine Rundungsfehler
Das gilt nur, wenn man sich auf simple Addition, Subtraktion oder Multiplikation beschränkt. Sobald eine Division ins Spiel kommt, ist der Vorteil dahin (ab hier sind es rationale Zahlen). Sieben Prozent Mehrwertsteuer auf mein Buch für 43,21 Euro sind 3,0247 Euro. Natürlich kann ich auch in hundertstel-Cent statt Cent rechnen. Aber das verschiebt das Problem nur und löst es nicht prinzipiell. Sobald ich den Betrag über eine Split-Buchung auf drei Kostenstellen aufteile, ist es mit exakten Werten vorbei.

Mythos 4: in einer Rechnung müssen alle Beträge auf den Cent genau stimmen
Das funktioniert nur, wenn man genügend ungenau hinschaut. Wenn ich auf einer Rechnung die gerundeten Mwst-Beträge zu jeder Rechnungsposition ausweise, wird die Summe der Beträge nur zufällig exakt zum gerundeten Mwst-Betrag der Netto Summe passen. Das Finanzamt weiß das. Jeder vernünftige Kaufmann ebenfalls. Und ein Programmierer sollte das auch wissen.

Fazit: man kann auch kaufmännische Software mit Fließkommazahlen erstellen
Es müssen halt einfach ein paar Rahmenbedingungen beachtet werden. Alle Ausgabewerte sollten auf den nächsten Cent auf- oder abgerundet werden. Sonst passieren so Dinge wie „überweisen Sie 4,272727272727273 Euro auf unser Konto“. Das ist immer für einen Lacher gut, aber genau genommen ist nichts schlimmes passiert. Der Betrag ist unhandlich aber nicht so falsch, dass ein messbarer Schaden entsteht.

Man kann einen Fließkommawert nicht unbesehen als Schleifenzähler verwenden. Dann kann es zu den gefürchteten „one off“ Fehlern kommen, die Schleife läuft einmal zu oft oder zu wenig. Auch hier muss man mit einer geeigneten Skalierung und Rundung arbeiten – dann geht das sehr wohl.

Bei extrem unterschiedlichen Werten kann die Reihenfolge der Berechnung für das Ergebnis wichtig sein: (1.001 * 10 hoch 15 + 0.00000001) – 1.0005 * 10 hoch 15 wird ein anderes Ergebnis liefern als (1.001 * 10 hoch 15 – 1.0005 * 10 hoch 15) + 0.00000001. So etwas kommt in der Physik und in der Mathematik durchaus vor. In kaufmännischen Anwendungen hat man so eine Dynamik eher nicht.