Seite 2 von 2
Verfasst: Donnerstag 29. Januar 2009, 19:28
von hendrikS
Oh, was sind denn das fuer schwerwiegende Nachteile?
Vielleicht sollte man dann auch mal piddons "netiquette" updaten.
Verfasst: Donnerstag 29. Januar 2009, 20:14
von Leonidas
hendrikS hat geschrieben:Oh, was sind denn das fuer schwerwiegende Nachteile?
Kurz gefasst: Das die Lösung nicht immer optimal sein muss und so Leute die eine viel bessere Lösung wüssten ggf. gar nicht rein schauen. Und gelöste Threads anschauen hat noch niemanden geschadet, dabei kann man eigentlich nur lernen.
hendrikS hat geschrieben:Vielleicht sollte man dann auch mal piddons "netiquette" updaten.
Ja, ich will das demnächst ins Wiki verschieben. Nicht dass das jemand liest aber immerhin kann ich dann besser darauf linken.
Edit: Habe die aktuelle Version etwas angepasst und unter [wiki]Forum/Regeln[/wiki] geschrieben. Werde das in den "Vor dem Posten lesen"-Posts eintragen.
Verfasst: Donnerstag 29. Januar 2009, 21:03
von würmchen
ich hab hierzu mal ein recht interessantes Benchmark gefunden...
http://www.peterbe.com/plog/uniqifiers-benchmark
unterscheidet auch die Geschwindigkeit, ob die Reihenfolge behalten soll usw...
Verfasst: Donnerstag 29. Januar 2009, 21:12
von str1442
Code: Alles auswählen
>>> def f(ls):
... return reduce(lambda a, b: a + [b] if b not in a else a, ls, list())
...
>>> f([1, 1, 2, 1, 3, 4, 5, 6, 4, 5, 6, 9, 11, 9, 9, 12, 9, 14])
[1, 2, 3, 4, 5, 6, 9, 11, 12, 14]
Um reduce() mal wieder benutzt zu sehen
Verfasst: Donnerstag 29. Januar 2009, 21:55
von numerix
str1442 hat geschrieben:Code: Alles auswählen
>>> def f(ls):
... return reduce(lambda a, b: a + [b] if b not in a else a, ls, list())
...
>>> f([1, 1, 2, 1, 3, 4, 5, 6, 4, 5, 6, 9, 11, 9, 9, 12, 9, 14])
[1, 2, 3, 4, 5, 6, 9, 11, 12, 14]
Um reduce() mal wieder benutzt zu sehen
Wobei das jetzt aber keine Lösung der ursprünglichen Problemstellung ist ..
Verfasst: Freitag 30. Januar 2009, 02:25
von BlackJack
Nur mal so nebenbei: Ich finde es fällt nicht unter "premature optimization" wenn man Algorithmen mit quadratischer Laufzeit nicht elegant findet, wenn es Alternativen gibt, die in einer "niedrigeren" Komplexitätsklasse liegen.
Die "list comprehensions" mit `count` finde ich jedenfalls nicht so gut. Das skaliert so überhaupt nicht, und so etwas sollte man sich gar nicht erst angewöhnen.
Habe gestern zum Beispiel so ineffizienten Code in einem Programm ersetzt, das mit ~100 Dateien absolut kein Problem hatte, bei 7000 aber plötzlich eine halbe Stunde gebraucht hat. Jetzt ist auch das nur eine Sache von Sekunden.
Verfasst: Freitag 30. Januar 2009, 02:39
von BlackVivi
Das is nich die Lösung von der Problemstellung ._. Er will die löschen, die doppelt vorhanden sind... Nochmal genau lesen.
Außerdem find ichs ein bissel verwirrend oO set(iterable) ist zum eliminieren von doppelten Einträgen wohl am schönsten.
Verfasst: Freitag 30. Januar 2009, 11:54
von lunar
Ich hab jüngst erst festgestellt, dass einer meiner algorithmen durchs (ineffiziente) stringaneinanderkleben gar nicht so sehr verlangsamt wurde wie durch meine Optimierungsansätze.
Dir ist aber schon klar, dass die Effizienz der String-Konkatenation in CPython auf einem Implementierungsdetail beruht?