Hallo,

für welche Art von Problemen/Anwendungen
ist lazy evaluation eigentlich besonders gut
geeignet? Und für welche weniger gut oder garnicht?

TIA,
Oliver

On Thu, 2007-05-10 at 15:30 +0200, Oliver Bandel wrote:
> Hallo,
>
> für welche Art von Problemen/Anwendungen
> ist lazy evaluation eigentlich besonders gut
> geeignet? Und für welche weniger gut oder garnicht?

Mal sehn.

Georg Bauhaus wrote:

> On Thu, 2007-05-10 at 15:30 +0200, Oliver Bandel wrote:
>
>>Hallo,
>>
>>für welche Art von Problemen/Anwendungen
>>ist lazy evaluation eigentlich besonders gut
>>geeignet? Und für welche weniger gut oder garnicht?
>
>
> Mal sehn.
>
>

war das eine ernst gemeinte Antwort?

Sowas wie, "das kommt drauf an", oder
"mach es vom Wetter und Deiner Laune abhängig, denn im Prinzip
geht beides genauso gut oder schlecht, es ist Geschmackssache"?

??

Ciao,
Oliver

Oliver Bandel <oliver*first.in-berlin.de> wrote:
>> Mal sehn.
> war das eine ernst gemeinte Antwort?
> Sowas wie, "das kommt drauf an", oder
> "mach es vom Wetter und Deiner Laune abhängig, denn im Prinzip
> geht beides genauso gut oder schlecht, es ist Geschmackssache"?

Nein eher so was "ich befasse mich damit wenn du etwas genauer wirst".

Gruss
Bernd

Oliver Bandel wrote:
> Georg Bauhaus wrote:
>> On Thu, 2007-05-10 at 15:30 +0200, Oliver Bandel wrote:
>>> für welche Art von Problemen/Anwendungen
>>> ist lazy evaluation eigentlich besonders gut
>>> geeignet? Und für welche weniger gut oder garnicht?
>>
>> Mal sehn.
>
> war das eine ernst gemeinte Antwort?

Nein, Lazy Evaluation. Solange keiner ein Posting lesen will, muss man
auch keins schreiben :-)

> Sowas wie, "das kommt drauf an", oder
> "mach es vom Wetter und Deiner Laune abhängig, denn im Prinzip
> geht beides genauso gut oder schlecht, es ist Geschmackssache"?

Gewissermaßen.

Ansonsten sollte natürlich nach etwas Überlegen sofort klar werden, dass
Lazy Evaluation dir gar nichts bringt, wenn vom zu berechnenden Ergebnis
wirklich jedes Bit benötigt wird. Beispiel Audioverarbeitung: eine
Faltung, Kosinustransformation, FFT o.ä. ist heftiges Gerechne, da
werden eine Menge Zahlen mit einer Menge anderer Zahlen verrechnet, und
am Ende kommen viele Zahlen raus, die man i.a. alle haben will. Da will
man schlicht einfach nur "alles rechnen", und keinen Overhead durch
Lazy-Auswertung.

Wo Lazy-Auswertung jetzt nützlich ist? Da fällt mir gleich gar kein
einleuchtendes Beispiel ein. Das liegt sicher auch daran, dass nun mal
99% der real existierenden Software nicht-lazy ist. Allerdings fand ich
z.B. die Operationen mit unendlichen Listen immer recht 'sexy'.


Stefan

Oliver Bandel wrote:
> Georg Bauhaus wrote:
>
>> On Thu, 2007-05-10 at 15:30 +0200, Oliver Bandel wrote:
>>
>>> Hallo,
>>>
>>> für welche Art von Problemen/Anwendungen
>>> ist lazy evaluation eigentlich besonders gut
>>> geeignet? Und für welche weniger gut oder garnicht?
>>
>>
>> Mal sehn.
>>

> war das eine ernst gemeinte Antwort?

Stell dir ein Problem vor, dem du zunächst mit dem Satz
"Mal sehn" begegnest. Was ist das für ein Problem.


Vergleiche den Denkschrittaufwand für eine Aufwandsberechnung
bei Auswertung nach Bedarf mit demjenigen bei unmittelbarer
Auswertung. Was siehst du?

* Stefan Reuther wrote:
> Wo Lazy-Auswertung jetzt nützlich ist?

Lazy gestattet die einfache Trennung von Generierung von Daten und
Verarbeitung. Man kann viele Algorithmen drastisch vereinfachen und gewinnt
dabei noch eine höhere Wiederverwertbarkeit der Programmteile.

Lazy ist immer dann von Vorteil, wenn die genaue Größe der bereitzustellende
Ausgangsdaten nicht vorab ermittelbar ist. In solchen Fällen spart lazy
durchaus massiv Aufwand ein.

Lazy ist erstaunlicherweise auch interessant, wenn es um Ressoucen-
minimierung geht. Der typische Ansatz, Ressoucen schnellstmöglich wieder
freizugeben wird dann durch den Anstatz ersetzt, Ressoucen spätmöglichst zu
belegen.

Generell kann man sagen, daß lazy oder eager keinen Unterschied beim
Programmieraufwand machen, wenn es um maximale Performance oder minimale
Ressoucennutzung geht. Weicht man jedoch von dem Opimium ab, entscheidet die
Erfahrung des Programmierers darüber, ob eager oder lazy schneller zum
Erfolg führen.

In der theoretischen Informatik gibt es darüberhinaus noch Probleme, die
sich lazy, aber nicht eager, berechnen lassen. Das sind aber esoterische
Randaussagen.

Lutz Donnerhacke schrieb:
> [...]

Danke, das war eine sehr schöne Zusammenfassung der für die Praxis
wesentlichen Unterschiede.

Grüße
jo

Lutz Donnerhacke <lutz*iks-jena.de> wrote:
> In der theoretischen Informatik gibt es darüberhinaus noch Probleme, die
> sich lazy, aber nicht eager, berechnen lassen. Das sind aber esoterische
> Randaussagen.

Ooch, gerade wo es interessant wird.

Implizierst Du mit obiger Aussage nicht, dass normal order evaluation
"mehr als turing-vollstaendig" ist? Mit anderen Worten: ich bezweifle,
dass es auch nur ein /Problem/ gibt, dass sich mit normal order
evaluation loesen laesst, mit applicative order aber nicht.

Natuerlich gibt es z.B. im Lambda-Kalkuel Ausdruecke, die, wenn man
applicative order (wie auch immer das auf Deutsch heisst) anwendet,
keine Normalform haben, unter normal order evaluation hingegen schon.
In der Regel laesst sich dies aber z.B. durch eta conversion beheben.

Oder praktisch ausgedrueckt: auch in Sprachen mit eager evaluation
kann man gegebenenfalls lazy evaluation implementieren. Siehe z.B.:

http://t3x.org/bits/streams.html

--
Nils M Holm <n m h * t 3 x . o r g> -- http://t3x.org/nmh/

* Nils M Holm wrote:
> Lutz Donnerhacke <lutz*iks-jena.de> wrote:
>> In der theoretischen Informatik gibt es darüberhinaus noch Probleme, die
>> sich lazy, aber nicht eager, berechnen lassen. Das sind aber esoterische
>> Randaussagen.
>
> Ooch, gerade wo es interessant wird.

Und falsch. Es ist irgendwas mit Komplexitätsklassengrenzen. Ich habe das
nie verstanden.