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.

Mittlerweile habe ich das Projekt abgeschlossen. Das Gerät funktioniert wie erwartet und die Genauigkeit und Kurzzeitstabilität ist gut. Einzig den Quarzoszillator werde ich wohl noch mal austauschen, da er eine zu hohe Temperaturabhängigkeit aufweist. Wenn man ihn mit dem Finger erwärmt, kann man das Messgerät auch als Fieberthermometer verwenden. Sobald ich mal günstig einen 1ppm TCXO mit 25 MHz bekomme wird das besser.

Im letzten Schritt habe ich noch die Spannungsversorgung ergänzt. Als Basis verwende ich ein normales USB Netzteil für die 5 Volt, die ich für die Anzeige und ein Teil der Eingangssignalverarbeitung benötige. Daraus leite ich dann noch mit einem einfachen Linearregler die 3,3 Volt für den Microcontroller ab.

Platine und Bereichsumschalter habe ich dann in ein Gehäuse eingebaut. Da ich keine Befestigungsschrauben auf der Vorderseite haben wollte, habe ich den Taster von der Rückseite her angeklebt. Das wäre beinahe schief gegangen, da ein wenig von dem Kleber auch an die Tastenkappe gekommen ist und diese mit der Frontplatte verklebt hat. Zum Glück konnte ich das Missgeschick mit etwas Geduld und Silikonöl beheben.

Was würde ich nun anders machen?

Im Vorfeld habe ich mir zu wenige Gedanken über den Aufbau der Platine und die Verteilung der Port-Pins gemacht. Da ich zuerst das Anzeigemodul aufgebaut habe, habe ich die Port-Pins danach ausgewählt, dass ich möglichst zusammenhängende Bits für die Bus Signale habe. Dabei habe ich nicht darauf geachtet, dass nur ein Teil der Input-Pins 5 Volt tolerant sind – und genau diese dann als Output verwendet. Zum Glück gibt es das 4-fach AND Gatter 7408 in einer VHC Version als Pegelwandler – allerdings nur im SMD Gehäuse. Die kleinen Pins in einer fliegenden Verdrahtung frei Hand anzulöten ist nicht einfach. Ich muss mir mal einen Vorrat an Adapterplatinen zulegen.

Weiterhin würde ich nun keinen 7447 mehr als 7 Segment Decoder verwenden. Statt dessen würde ich drei zusätzliche Port-Pins spendieren und jedes Segment einzeln per Software steuern. Das würde aber auch dazu führen, dass ich statt der 28 Pin Variante des PIC32 ein 44 Pin Gehäuse verwenden müsste. Und die zusätzlichen Pins würden weitere Zusatzfunktionen erlauben.

Zuletzt würde ich statt der beiden 32 Bit Counter nun vier 16 Bit Counter verwenden, die per Software dann jeweils auf 32 Bit verlängert werden – durch eine Interrupt Routine beim Überlauf. Damit hätte ich dann eine Zwei-Kanal Lösung oder könnte auch das Impuls-Pausen-Verhältnis messen.

Vielleicht werde ich das Projekt später noch mal aufgreifen und verbessern. Im Augenblick bin ich mit dem aktuellen Stand zufrieden und beende das Projekt erst mal.

Wenn eine größere Sicherheitslücke in einer Software auftritt, wird schnell der Ruf laut, dass doch der Hersteller dafür haften müsste. Aber ist das auch gerechtfertigt?

Ich möchte das Problem einmal in die Welt der realen Dinge transportieren. Wenn ein Auto gestohlen wird, kommt dann auch der Ruf nach der Herstellerhaftung? Nein. Selbst eine Wegfahrsperre ist nur ein Schutz vor „Gelegenheitsdieben“. Für ein Profi stellt sie kein Hindernis dar. Das Auto kommt auch komplett ohne Schutz gegen „denial of service“ Attacken. Ein Angreifer kann jedes Auto in wenigen Sekunden in einen nicht mehr fahrbereiten Zustand versetzen. Der Eigentümer kann sich nicht dagegen schützen.

Wenn ein Einbrecher in eine Wohnung einbricht, wird dann der Bauträger verklagt? Auch nicht. Selbst dann nicht, wenn er Schlösser einbaut, die ein Profi in wenigen Sekunden knacken kann.

Wer sich darauf verlassen möchte, dass seine Haustür sicher ist, sollte sich dieses Video nicht ansehen (und auch nicht auf YouTube nach „lock picking contest“ suchen).

Wenn Sie ein Fahrrad kaufen, erhalten Sie es im Allgemeinen sogar komplett ohne Schutz gegen Diebstahl oder Vandalismus. Verklagen Sie den Fahrradhändler, wenn es gestohlen wird? Oder die Reifen zerstochen werden? Auch nicht.

Noch ein Beispiel: ein Safe. Er hat keine Funktion außer eben sicher zu sein. Sie können aber trotzdem keinen Safe kaufen, der absolute Sicherheit garantiert. Sie können nur 30 Minuten, 60 Minuten oder 120 Minuten Schutz kaufen (gegen viel mehr Geld auch länger, aber nicht beliebig lang). Wenn Sie einem Einbrecher ausreichend viel Zeit lassen, wird er jeden Safe knacken.

In der realen Welt haben wir in Kauf genommen, dass es keine absolute Sicherheit gibt. Und wir müssen uns daran gewöhnen, dass das im Bereich der Software ebenfalls nicht möglich ist. Natürlich sollte ein Hersteller bestrebt sein, sein Produkt so sicher wie möglich zu machen. Aber egal wie viel Aufwand man treibt, wenn es etwas wertvolles gibt, wird es immer Kriminelle geben, die sich dieses mit viel Energie und manchmal auch mit Finesse aneignen wollen. Die Situation wird nicht besser, wenn man per Gesetz eine Eigenschaft einfordert, die prinzipiell nicht zu erfüllen ist.