Warum haben Tupel keine .index(x)-Methode?

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Benutzeravatar
Goswin
User
Beiträge: 363
Registriert: Freitag 8. Dezember 2006, 11:47
Wohnort: Ulm-Böfingen
Kontaktdaten:

Warum haben Tupel keine .index(x)-Methode :o ?

Diese Frage stelle ich aus reiner Neugier, da meiner Meinung nach eine .index(x)-Methode für Tupel so naheliegend ist. Natürlich habe ich kein echtes Problem damit, da ich ja zum Beispiel

Code: Alles auswählen

Tupel = (2,3,5,7,11,13,17,19)
ind = list(Tupel).index(7)
schreiben kann, und vieleicht sogar eine eigene Tupel-Klasse mit einer zusätzlichen Methode schreiben kann. Aber ist so etwas performant?
Benutzeravatar
BlackVivi
User
Beiträge: 762
Registriert: Samstag 9. Dezember 2006, 14:29
Kontaktdaten:

Man könnte es ganz einfach machen oO

Code: Alles auswählen

class MyTuple(tuple):
    def index(self, value):
        for j, i in enumerate(self):
            if i == value:
                return j
Aber warum nicht gleich listen nehmen?
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Goswin hat geschrieben:Warum haben Tupel keine .index(x)-Methode?
Hallo Goswin!

Tuppel sind ressourcenschonender als Listen. Dafür muss man aber auch auf ein paar Dinge verzichten.

Und wenn ich mehr brauche als mir ein Tuppel zur Verfügung stellen kann, steige ich auf eine Liste um.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
Goswin
User
Beiträge: 363
Registriert: Freitag 8. Dezember 2006, 11:47
Wohnort: Ulm-Böfingen
Kontaktdaten:

Im von CM zitierten Parallelforum hei3t es unter anderem:
I use tuples
when I already know what goes into them and in what order.
index() and count() are totally useless
when you use tuples (or, indeed, any sequence) in this manner.
Im Gegensatz zu meinem Programm wei3 ich als Mensch natürlich, an welcher Stelle des Tupels mein x liegt, und könnte versuchen, es auch abzuspeichern und im Algoritmus mitzuführen. Aber das geht auch nur, wenn das x als Key zu gebrauchen ist, zum vorherigen Beispiel:

Code: Alles auswählen

Tupel = (2,3,5,7,11,13,17,19)
wo_in_Tupel = {2:0, 3:1, 5:2, 7:3, 11:4, 13:5, 17:6, 19:7}
ind = wo_in_Tupel[7]
Ich hoffe einmal, dass das trotz des zusätzlichen Dictionarys effizienter ist als eine Listenabfrage. Oder?
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Goswin hat geschrieben:Ich hoffe einmal, dass das trotz des zusätzlichen Dictionarys effizienter ist als eine Listenabfrage. Oder?
Wohl kaum.

Hast du eigentlich was gegen Pythoncode-Tags?
Benutzeravatar
Goswin
User
Beiträge: 363
Registriert: Freitag 8. Dezember 2006, 11:47
Wohnort: Ulm-Böfingen
Kontaktdaten:

OK CM, ich drücke mich mal besser aus:
Ich hoffe, dass trotz eines zusätzlichen Dictionary-Aufbaus 100000 Dictionary-Abfragen effizienter sind als 100000 Listenabfragen. Und falls es weniger Abfragen sein sollten, hoffe ich, dass es zumindest nicht viel langsamer ist.

Danke für den Hinweis, das es Textobjekte (?) gibt, die Tags hei3en, und mit welchen man das Problem unter Umständen auch angehen kann; ich habe sie soeben in meinem Pythonbuch entdeckt und werde sie mir bei Gelegenheit anschauen. Wie sollte ich etwas gegen eine Sache haben, von der ich nicht einmal gewu3t habe, das sie existiert! Ich komme halt aus einem gaaanz primitiven, nicht objektorientierten, und sehr lückenbehafteten C-Hintergrund.
lunar

Goswin hat geschrieben:Danke für den Hinweis, das es Textobjekte (?) gibt, die Tags hei3en, und mit welchen man das Problem unter Umständen auch angehen kann; ich habe sie soeben in meinem Pythonbuch entdeckt und werde sie mir bei Gelegenheit anschauen. Wie sollte ich etwas gegen eine Sache haben, von der ich nicht einmal gewu3t habe, das sie existiert! Ich komme halt aus einem gaaanz primitiven, nicht objektorientierten, und sehr lückenbehafteten C-Hintergrund.
Uh? Was hat das den mit Python als Programmiersprache, bzw mit deinem Programmiersprachen-Hintergrund zu tun?

Es geht darum, Code im Forum farblich aus zu zeichnen. Dafür brauch man kein Buch, dafür muss man sich einfach mal nur die Knöpfe anschauen, die beim Posten so über dem Textfeld sind. Die haben nämlich auch einen Sinn, weißt du...
Benutzeravatar
HWK
User
Beiträge: 1295
Registriert: Mittwoch 7. Juni 2006, 20:44

@Goswin
Mit lieben Grüßen von Lunar.
Scheinbar meint er es nicht so wie er es schreibt.
Es gibt Python-Neulinge, die nicht soviel wie er von Python und diesem Forum wissen. Damit die es trotzdem schnell begreifen, hat er halt eine sehr direkt Ausdrucksweise.
Mfg
HWK
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

HWK hat geschrieben:Es gibt Python-Neulinge, die nicht soviel wie er von Python und diesem Forum wissen.
Aber manchmal erstaunt es mich dann doch, dass die Leute nicht auf die Idee kommen, zu gucken was passiert wenn man das Ding mit der Aufschrift "Python" drücken. :?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
Sr4l
User
Beiträge: 1091
Registriert: Donnerstag 28. Dezember 2006, 20:02
Wohnort: Kassel
Kontaktdaten:

Ich fasse alles an was ich nicht verstehe. :-)

PS: Immer diese C Programmiere mit ihrer preformance ;-)
lunar

HWK hat geschrieben:Mit lieben Grüßen von Lunar.
Scheinbar meint er es nicht so wie er es schreibt.
Es gibt Python-Neulinge, die nicht soviel wie er von Python und diesem Forum wissen. Damit die es trotzdem schnell begreifen, hat er halt eine sehr direkt Ausdrucksweise.
Endlich mal jemand, der mich versteht ;)
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

gerold hat geschrieben: Tuppel sind ressourcenschonender als Listen. Dafür muss man aber auch auf ein paar Dinge verzichten.
Was jetzt das eine (weniger Speicherbedarf -- übrigens auch nur, wenn die Liste nicht zuviel overallocated hat, was bei kleinen Listen kaum vorkommt) mit dem anderen (fehlende Methode) zu tun hat, kann ich allerdings nicht erkennen.

MaW: wenn Tupel als "ressourcenschonende Listen" gedacht wären, gäbe es keinen Grund, ihnen kein index() zu geben.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

birkenfeld hat geschrieben:MaW: wenn Tupel als "ressourcenschonende Listen" gedacht wären, gäbe es keinen Grund, ihnen kein index() zu geben.
Hallo birkenfeld!

Ich habe nicht die Zeit und nicht die Lust, mir den Quellcode von Python durchzusehen. Ich gehe nur von meiner ärmlichen Hauslogik aus. --> Ein leichter Rucksack trägt sich einfacher als ein schwerer Rucksack. :roll:

Und der einzige Existenzgrund für ein Tuppel, ist in meinen Augen der, dass man damit weniger Last mitschleppt und dadurch das Programm schneller, kleiner und besser wird. So habe ich das zumindest immer zwischen den Zeilen herausgelesen.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

gerold hat geschrieben:
birkenfeld hat geschrieben:MaW: wenn Tupel als "ressourcenschonende Listen" gedacht wären, gäbe es keinen Grund, ihnen kein index() zu geben.
Hallo birkenfeld!

Ich habe nicht die Zeit und nicht die Lust, mir den Quellcode von Python durchzusehen. Ich gehe nur von meiner ärmlichen Hauslogik aus. --> Ein leichter Rucksack trägt sich einfacher als ein schwerer Rucksack. :roll:

Und der einzige Existenzgrund für ein Tuppel, ist in meinen Augen der, dass man damit weniger Last mitschleppt und dadurch das Programm schneller, kleiner und besser wird. So habe ich das zumindest immer zwischen den Zeilen herausgelesen.
Das ist leider nicht so. Zwar haben, wie gesagt, manche Listen einen höheren Speicherverbrauch als ein entsprechendes Tupel, weil sie mehr Speicher allozieren als nötig, um viele realloc()s zu sparen, aber schneller oder besser wird ein Programm dadurch nicht.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
Benutzeravatar
nkoehring
User
Beiträge: 543
Registriert: Mittwoch 7. Februar 2007, 17:37
Wohnort: naehe Halle/Saale
Kontaktdaten:

@Birkenfeld: Kannst du denn mal kurz und knapp (mit C-Kenntnissen als Voraussetzung) erlaeutern, wie sich Tupel und Lists noch so im Speicher unterscheiden, außer eben das die Liste veraenderbar ist und das Tupel nicht?

Also ich stelle mir das ungefaehr so vor:
Ein Tuple entsteht, indem einfach die zusammenaddierte Bytegroesse des Tuple-Inhalts alloziiert und das entstandene Objekt nicht mehr angefasst wird. Eine Liste brauch unmengen an Zusatzfunktionen. Sie muss sich staendig neualloziieren und ihren Inhalt veraendern koennen. Das muss ein Tuple nicht.

Aber aendert das etwas an der Geschwindigkeit? Schließlich ist der Abruf eines einzelnen Objektes innerhalb eines Tuples oder einer Liste doch das gleiche. Mache ich also mit einer Liste das gleiche wie mit einem Tuple, sollte es doch speicher- und geschwindigkeitstechnisch keinen Unterschied machen (außer eben bei der erwaehnten Sache mit der Ueberalloziierung, bei großen Listen)... liege ich da richtig?

@Goswin: Ich glaube nicht das es effizienter ist, ein zusaetzliches Dictionary zu bemuehen. Ein einfaches durchlaufen durch eine Liste um ein Objekt darin zu finden, sollte recht schnell gehen... auch bei hunderttausenden Objekten.
Das Dictionary hingegen wuerde riesengroß werden. Ein unnoetiger Klotz den ein bisschen mehr Prozessorlast ohne weiteres ueberfluessig macht.


Gruß
NKoehring
[url=http://www.python-forum.de/post-86552.html]~ Wahnsinn ist auch nur eine andere Form der Intelligenz ~[/url]
hackerkey://v4sw6CYUShw5pr7Uck3ma3/4u7LNw2/3TXGm5l6+GSOarch/i2e6+t2b9GOen7g5RAPa2XsMr2
EyDu
User
Beiträge: 4881
Registriert: Donnerstag 20. Juli 2006, 23:06
Wohnort: Berlin

nkoehring hat geschrieben: Ein einfaches durchlaufen durch eine Liste um ein Objekt darin zu finden, sollte recht schnell gehen... auch bei hunderttausenden Objekten.
Das Dictionary hingegen wuerde riesengroß werden. Ein unnoetiger Klotz den ein bisschen mehr Prozessorlast ohne weiteres ueberfluessig macht.
Da liegst du aber vollkommen daneben ;-) Das Finden eines Elements in einer Liste liegt in O(n), da Suchen in einem Dictionary bei vernünftigen Hashwerten in O(log n) und das macht sich bei vielen (hundert)tausend Anfragen deutlich in der Laufzeit bemerkbar.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

nkoehring hat geschrieben:Ich glaube nicht das es effizienter ist, ein zusaetzliches Dictionary zu bemuehen.
Hallo NKoehring!

Innerhalb eines Dictionaries kann **unglaublich schnell** nach einem Schlüssel gesucht werden. Wenn ich den Index eines Eintrags einer Liste nicht weiß, dann muss diese Liste von oben nach unten durchlaufen werden. Das ist im Gegensatz zur Verwendung eines Dictionaries **unglaublich langsam**. :-)

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
nkoehring
User
Beiträge: 543
Registriert: Mittwoch 7. Februar 2007, 17:37
Wohnort: naehe Halle/Saale
Kontaktdaten:

Ja da habt ihr natuerlich beide recht... Irgendwie hab ich da wohl bloedsinnig gedacht, als ich das schrieb.

Aber dann sollte er das Tuple wegwerfen und ganz auf ein Dict umstellen... ich kann mir jedenfalls nicht vorstellen, warum es sinnvoll sein sollte *beides* mit sich zu fuehren.
[url=http://www.python-forum.de/post-86552.html]~ Wahnsinn ist auch nur eine andere Form der Intelligenz ~[/url]
hackerkey://v4sw6CYUShw5pr7Uck3ma3/4u7LNw2/3TXGm5l6+GSOarch/i2e6+t2b9GOen7g5RAPa2XsMr2
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

nkoehring hat geschrieben:@Birkenfeld: Kannst du denn mal kurz und knapp (mit C-Kenntnissen als Voraussetzung) erlaeutern, wie sich Tupel und Lists noch so im Speicher unterscheiden, außer eben das die Liste veraenderbar ist und das Tupel nicht?
Wie gesagt, nur durch die Überallozierung.
Also ich stelle mir das ungefaehr so vor:
Ein Tuple entsteht, indem einfach die zusammenaddierte Bytegroesse des Tuple-Inhalts alloziiert
Pro Objekt ist das ein Pointer.
und das entstandene Objekt nicht mehr angefasst wird. Eine Liste brauch unmengen an Zusatzfunktionen. Sie muss sich staendig neualloziieren und ihren Inhalt veraendern koennen. Das muss ein Tuple nicht.
Diese neu allozierenden Funktionen rufst du ja nicht auf, wenn du eine nichtveränderliche Liste hast. Die Funktionen an sich belegen ja keinen Platz pro Liste.
Aber aendert das etwas an der Geschwindigkeit? Schließlich ist der Abruf eines einzelnen Objektes innerhalb eines Tuples oder einer Liste doch das gleiche. Mache ich also mit einer Liste das gleiche wie mit einem Tuple, sollte es doch speicher- und geschwindigkeitstechnisch keinen Unterschied machen (außer eben bei der erwaehnten Sache mit der Ueberalloziierung, bei großen Listen)... liege ich da richtig?
Ganz genau.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
Antworten