Berechnungsstrategie

PHuV schrieb:
Warum ist das hier sinnvoll? :confused_alt: Der Sinn erschließt sich mir hier nicht.
Wurde schon sehr hübsch in #18 beantwortet (Performance: Code in der Schleife, die if Abfrage muss für jeden Pixel, also 6000x4000 mal geprüft werden - da macht ein elemeniertes IF schonmal viel aus, je nach Anwendungsfall und das gleiche gilt für andere Operationen, wie Addition, etc.)

KitKat::new() schrieb:
Mir fehlt eher die Anwendbarkeit aufs Problem vom TE
Es ging mir eigentlich nur darum, das Mikro-Optimierung zwar in den wenigsten Fällen Sinn macht, wenn dadurch die Lesbarkeit leidet, es gibt aber eben auch Ausnahmen. High-Performance (Bildbearbeitung, Spiele, Grafikanwendung, etc.) ist eine davon, somit kann man nicht generell sagen, was die bessere Lösung ist, sondern es kommt eben auf den Anwendungsfall an.
 
  • Gefällt mir
Reaktionen: kuddlmuddl
sandreas schrieb:
Wurde schon sehr hübsch in #18 beantwortet
Ja, ich weiß, ich habe es trotzdem nicht verstanden. Tut mir ja leid. Trotz über bald 35 Jahre Programmierung fällt mir kein Beispiel ein, wo ich das jemals hätte brauchen können.
sandreas schrieb:
(Performance: Code in der Schleife, die if Abfrage muss für jeden Pixel, also 6000x4000 mal geprüft werden - da macht ein elemeniertes IF schonmal viel aus, je nach Anwendungsfall und das gleiche gilt für andere Operationen, wie Addition, etc.)
Was hat die If-Abfrage mit den Pixel und 2x identischen Code im Ja und Nein-Fall zu tun?

Ja, ich führe das gleiche aus.
Nein, ich führte trotzdem das gleiche aus.

Sprich, die Prüfung ist unlogisch, wenn ich - egal wie die Bedingung lautet, den Code trotzdem immer ausführen muß. Wie KitKat::new() es bereits sagte, gute Optimizer werfen das sowieso wieder raus.
 
PHuV schrieb:
Ja, ich weiß, ich habe es trotzdem nicht verstanden. Tut mir ja leid. Trotz über bald 35 Jahre Programmierung fällt mir kein Beispiel ein, wo ich das jemals hätte brauchen können.
Zum Beispiel bei Image Thresholding:

https://github.com/lessthanoptimal/...er/binary/impl/ImplThresholdImageOps.java#L42


PHuV schrieb:
Was hat die If-Abfrage mit den Pixel und 2x identischen Code im Ja und Nein-Fall zu tun?
Nicht identisch... das ist ja der Punkt... Im obigen beispiel ist es bei "down=true" <= und bei "down=false" >.

Das wird z.B. genutzt, um ein invertiertes Thresholding-Bild zu erzeugen, wo einmal 0 für ein match steht und einmal 1, je nach übergebener boolscher Variable. Der Code mag nicht elegant sein und man kann das sicher besser lösen, aber als Beispiel wird es so vielleicht nachvollziehbarer.
 
  • Gefällt mir
Reaktionen: kuddlmuddl und PHuV
Gerade bei Loops in JS sind wiederholende Conditions schon deutlich spürbar. Das ist zwar Scripting, sollte aber meines Erachtens berücksichtigt werden.

Noch eine Variante:

Code:
var ergb = 0;
switch(true)
{
    case (Bedingung):
        ergb = c;
    default:
        ergb += a + b;
}
:D
 
Habe jetzt noch weitere Bedingungen erhalten und daraus ergab sich, dass einer Lösung mir Zwischenergebnissen die sinnvollste und nachvollziehbarste ist.
 
Zurück
Oben