Eure besten Quellcode Kommentare...

[Memnarch]

Zitat von Mikkey:

Code:

a := b div 2;

Optimierung im Algorithmus mag ja sinnvoll sein, aber ob eine Shift-Operation schneller als die Teilungsoperation ist, sollte man dem Compiler überlassen.

Yep, ein shr ist in dem Fall schneller als ein DIV. Liegt daran, das eine DIV-Operation(welche direkt in der CPU integriert ist) sehr aufwendig ist, da sie im allgemeinen an das mathematische Problem rangeht.(von +-*/ ist / bzw DIV die langsamste)

mit shr nimmst du bei Dvisionen durch eine Zweierpotenz(2, 4, 8, 16) eine unkomplizierte Abkürzung. ein shr ist vergleichweise schnell erledigt auf der CPU. Die logik dahinter ist einfach unkomplizierter.

EDIT: Und falls jemand fragt: Nein, in einer normalen Anwendung ist das komplett Hupe, ob man div oder shr nimmt(hier würde ich der Lesbarkeithalber eher div empfehlen). Aber mein Softwarerenderer hat's mir gedankt

Grüße
Memnarch

[Mikkey]

@Memnarch: Sei mir nicht böse, aber ein Compiler, der nicht selbst ein "... div 2" durch "... SHR 2" ersetzt (wenn die Ziel-CPU denn damit auch wirklich schneller ist), gehört in die Tonne.

[Furtbichler]

Zitat von Mikkey:

..ein Compiler, der nicht selbst ein "... div 2" durch "... SHR 2" ersetzt ... gehört in die Tonne.

Ich schmeiße JEDEN Compiler in die Tonne, der 'div 2' durch 'SHR 2' ersetzt.

Einfach, weil das falsch ist. Richtig wäre 'SHR 1'.

[Memnarch]

@Furtbichler Danke, wollte genau das schreiben

Und dann gibt ja auch noch die Krux mit dem Arithmetic-Shr/Shl die Delphi nur in BASM implementiert.
In bestimmten Fällen, kann man auch damit hantieren, wenn man sich im Klaren ist, dass SAR anders rundet als IDIV.

Grüße
Memnarch

[silver-moon-2000]

Ja, ich grabe einen alten Thread wieder aus.
Und eigentlich sogar aus einem falschen Grund, denn das Folgende ist kein Kommentar, sondern ein echtes Stück Quellcode...
Aber ich musste so lachen, als ich das gelesen habe, dass ich es denjenigen, die es noch nicht kennen, nicht vorenthalten will .

aus der Funktion "SameValue" (unit math), um Fließkommazahlen auf Gleichheit zu überprüfen:
 Epsilon := Max(Min(Abs(A), Abs(B)) * DoubleResolution, DoubleResolution); an sich nicht wirklich lustig, aber die Definition von "DoubleResolution" gefällt mir einfach wunderherrlich:

Delphi-Quellcode:

const
  FuzzFactor = 1000;
  ExtendedResolution = 1E-19 * FuzzFactor;
  DoubleResolution   = 1E-15 * FuzzFactor;
  SingleResolution   = 1E-7 * FuzzFactor;

FuzzFactor ? einfach genial

[Furtbichler]

Zitat von silver-moon-2000:

FuzzFactor ? einfach genial

Das mag ja für dich ein lustiger Name sein, aber eigentlich ist das nicht nur irgendwie komisch, sondern exakt das, was gemeint ist.

Fuzz(y) = Verschwommen, verwischen.

Es handelt sich also um einen Faktor, der die letzten Stellen der einzelnen Datentypen 'verwischt', sodaß man zwei Werte auf 'Gleichheit' (unscharf!) prüfen kann.

Versuch mal, dafür einen a) besseren Namen und b) deutschen Namen zu finden.

Aber trotzdem: Angenehm lockere Nomenklatur. Aber dafür ist die englische Sprache bekannt.

[silver-moon-2000]

Zitat von Furtbichler:

Zitat von silver-moon-2000:

FuzzFactor ? einfach genial

Das mag ja für dich ein lustiger Name sein, aber eigentlich ist das nicht nur irgendwie komisch, sondern exakt das, was gemeint ist.
[...]
Es handelt sich also um einen Faktor, der die letzten Stellen der einzelnen Datentypen 'verwischt', sodaß man zwei Werte auf 'Gleichheit' (unscharf!) prüfen kann.
[...]

Das ist mir schon klar, worum es mir aber geht, ist Folgendes: Warum geben Sie die Resolution so "genau" an, nur um dann alle(!) so definierten Werte mit dem FuzzFactor zu multiplizieren?
Was ich sagen will: Warum definieren sie die Werte (z.B. 1E-19 ) so präzise, nur um sie im gleichen Schritt wieder zu "verwischen"? Warum definieren sie die Werte nicht gleich um 1E+3 unschärfer?
Als ich das gelesen habe, hat es im ersten Augenblick auf mich gewirkt wie:

Zitat:

<Programmierer1>: Verdammt, der Vergleich funktioniert nicht. Warum???
<Programmierer 2>: [nach 15min heftigem Kopfkratzen] Ich glaube, wir haben damals(TM) die Vergleichsschwellen zu gering gesetzt... Was sollen wir nur machen...
<Programmierer 1>: Ich hab's: Wir setzen einfach die Werte rauf, dann wird's schon klappen!
<Programmierer 2>: Schon, aber wenn sich irgendwann(TM) wieder was ändert, dann müssen wir wieder alle Werte anpacken...
<Programmierer 1>: Stimmt, hhhhhhhhmmmmmmmm...
<Programmierer 3>: Dann macht's doch einfach so: Nehmt 'ne Konstante und multipliziert alle Schwellen damit. Dann könnt Ihr später einfach diese Konstante anpassen.
<Programmierer 1 + 2>: Geniale Idee, danke <Programmierer3>. Aber, wie groß sollen wir die Konstante machen? 10?
<Programmierer 3> Ach, iwo! Nehmt's doch gleich 1000.
<Programmierer 1+2> Aber ist 1000 nicht irgendwie ein bischen groß?
<Programmierer 3>Merkt doch eh' keiner und dann wird's scho' funktionieren... und hey, wenn später ein Update rauskommt, machen wir den Wert einfach kleiner und tun so, als ob wir durch unendliche Schlauheit plötzlich unseren Compiler um den Faktor 10 besser gemacht hätten.

Disclaimer: Dass es in Wahrheit anders abgelaufen ist, ist mir klar, aber dieser Gedankengang hat sich mir eben in diesem Moment aufgedrängt. Ich will den Leuten bei Emba(undVorläufern) nichts unterstellen


Also nochmal zusammenfassend: Ich finde die Bezeichnung nach wie vor genial; aber auch die Tatsache, dass ein genauerer Wert vorgegeben und gleich darauf verwischt wird, entzieht sich meiner Meinung nach nicht einer gewissen Komik.

[himitsu]

Wobei Delphi bei einem Unsigned Integer das DIV (2^x) und * (2^x) entsprechend in ein SHR/SHL optimiert.
> wenn rechts eine Konstante ist
> wenn rechts eine 2er-Potenz steht
> wenn links kein Vorzeichen drin ist