floor Implementierung
-
Ist ja schlimmer als erwartet
Leute, die solchen Code schreiben, gehören entlassen.
-
314159265358979 schrieb:
Ist ja schlimmer als erwartet
Leute, die solchen Code schreiben, gehören entlassen.
Dass man hexadezimal rechnet lass ich mir ja noch einreden, denn teilweise sieht man damit gewisse Dinge wirklich besser als dezimal.
ABER: Ich werde Leute nie verstehen, die so blöde Variablennamen hernehmen.
Wieso kann man nicht einfach sprechende Variablen hernehmen???Auf der Arbeit musste ich mal ein altes C Programm umbauen. Die meiste Zeit habe ich damit verbracht, zu erraten, was s0, s1, s2, i0, i1, i2 denn nun bedeuten soll. Und wenn mans dann mal weiß muss man es sich aufschreiben weil ich mir die Bedeutung nicht merken kann von so doofen Namen.
So ... das war jetzt offtopic aber das musste mal raus
-
314159265358979 schrieb:
Ist ja schlimmer als erwartet
Leute, die solchen Code schreiben, gehören entlassen.
Ach bitte...
Derart grundlegende Mathefunktionen dürfen so schlimm aussehen, wenn es der Performance zu Gute kommt.
-
Naja, es geht hier um einen Sachverhalt, der extrem low-level ist. Zum einen ist eine sinnvolle Benennung in dem Sinne, wie wir sie üblicherweise verstehen (nämlich eine, die die Rolle der Variable im abstrakten Sachverhalt, den wir gerade modellieren, erklärt) ziemlich schwierig, weil es wenig Abstraktion zu erklären gibt - j0 hätte man exponent nennen können, i0 und i1 vielleicht hiword und loword, i gerade noch mask und bei j wird's dann richtig schwierig.
Ich denke, man muss das so sehen: Wenn man in IEEE-754 zuhause ist, erkennt man einen Ausdruck der Form
x = ((y >> kleine_zahl) & 0x[137f]f+) - 0x[137f]f+;sofort als Extraktion des Exponenten. i0 und i1 als Bezeichner für Teile des selben Wertes sind so schlimm für mein Verständnis eh nicht, und der Rest ist elendes Bitmaskengefrickel, bei dem kein Variablenname hilft. Ich gehe ferner davon aus, dass der Code von jemandem geschrieben wurde, der auf dem Gradienten zwischen Mathematiker und Programmierer irgendwo in der Nähe von Don Knuth steht - und Mathematiker sind Variablennamen gewohnt, die genau einen Buchstaben haben. Wenn im Code "hiword" steht, parst der das zunächst als "h * i * w * o * r * d".
-
Der Code hätte auch besser dokumentiert werden können. Beispielsweise wäre eine "Grafik" des Speicherlayouts von doubles am Anfang ziemlich nett.
Und nicht nur die Variablennamen sind schrecklich, auch die Klammernsetzung und die fehlenden Abstände. Einrückungen und Leerzeilen wurden auch gespart.
-
314159265358979 schrieb:
Der Code hätte auch besser dokumentiert werden können. Beispielsweise wäre eine "Grafik" des Speicherlayouts von doubles am Anfang ziemlich nett.
Junge, wenn du in so einer Funktion herumschreiben willst, darf davon ausgegangen werden, dass du IEEE-754 auswendig kennst.
-
314159265358979 schrieb:
Leute, die solchen Code schreiben, gehören entlassen.
Ich würd ihn dann für die harten Probleme einstellen.
-
seldon poste bitte mal noch die ein oder andere Funktion aus dieser Bibliothek.
-
DevilMayCry schrieb:
seldon poste bitte mal noch die ein oder andere Funktion aus dieser Bibliothek.
http://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/ieee754;hb=HEAD
dbl-64 ist für double, flt-32 für float und die ldbl für diverse long double Varianten.
Implementierungen optimiert für x86-64 sind hier http://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/x86_64/fpu;h=7ed9aacca047946dc03db5fd79078c79623f6c1e;hb=HEAD
-
Du kannst dir die ganze Bibliothek herunterholen. Liegt unter ftp://ftp.gnu.org/gnu/glibc/ - mit langer Versionshistorie; die derzeit neueste ist 2.14.1.
Die in C geschriebenen ieee-754-Funktionen liegen darin unter sysdeps/ieee754.
-
Man darf bei der GNU Clib auch nicht vergessen dass der Code auch von einem 20 Jahre alten GCC gefressen werden können soll.
Das hat so einige Auswirkungen auf den Code.