[python-users] Geschachtelte Listen

Di Jun 25 21:29:43 CEST 2019

Hallo Dirk,

was mir noch nicht klar ist, ist warum die Listen überhaupt gespeichert
werden. Laut deiner Beschreibung ist die Anzahl der Elemente und die Anzahl
der Schachteln von Interesse. Wofür muss die Liste aufgebaut werden? Kann
man nicht die Infos direkt beim Aufbau mitzählen und dann den Inhalt
jeweils direkt verwerfen? Oder wofür wird die Struktur später noch benutzt?

Grüße
Jochen

Dirk Hünniger via python-users <python-users at uni-koeln.de> schrieb am Di.,
25. Juni 2019, 19:31:

> Diese Nachricht wurde eingewickelt um DMARC-kompatibel zu sein. Die
> eigentliche Nachricht steht dadurch in einem Anhang.
>
> This message was wrapped to be DMARC compliant. The actual message
> text is therefore in an attachment.
>
>
> ---------- Forwarded message ----------
> From: "Dirk Hünniger" <dirk.hunniger at googlemail.com>
> To: "Dr. Mark Asbach" <mark.asbach at pixolus.de>
> Cc: pyCologne <python-users at uni-koeln.de>
> Bcc:
> Date: Tue, 25 Jun 2019 19:31:19 +0200
> Subject: Re: [python-users] Geschachtelte Listen
> Hallo Mark,
>
> jetzt komme ich endlich mal dazu mir deine Lösung genauer anzuschauen.
> In der Tat löst sie genau das von mir angegebene Beispiel maximal
> speichereffizient. Mein Beispiel lautete ja:
>
>
> [1,2,3,4,[5,6,7,8,[9,10,11,12]]]
>
> ich brauche aber auch den Fall:
>
> [1,2,[3,4,5,6],7,[8,9,10,11],12]
>
> sprich die sublisten müssen an beliebiger Stelle und in beliebiger Zahl
> sowie beliebiger Verschachtelung auftreten können. Das war an meinem
> Beispiel in der Tat ungeschickt formuliert. Vielleicht hat ja  noch
> jemand eine Idee wie man diesen allgemeineren Fall effizient lösen kann.
>
> Viele Grüße Dirk
>
> On 6/24/19 12:52 PM, Dr. Mark Asbach wrote:
> > Hallo Dirk,
> >
> >> vielen Dank für deine Anwort. Die Sache mit den 8 Byte pro Pointer
> hatte ich schon so befürchtet. Als Lösung würde mir dann noch einfallen den
> Speicher sehr manuell zu verwalten und bei jedem Rose Element die Länge der
> Subliste mit anzugeben. Man braucht ein Bit um zwischen Rose und Leaf zu
> unterscheiden. Sowie 8 Byte für die Nutzdaten je Leaf und 8 Byte für die
> Länge je Rose. Wenn ich den bei mir auftrenden Spezialfall das die
> Nutzdaten Unicode Zeichen sind, sowie die Tatsache das immer weniger 1
> ExaByte Ram vorhanden sind nutze, komme ich mit 8 Byte pro Rose bzw Leaf
> aus. Wäre dann halt nur ein sehr schlecht wartbarer prozduraler Ansatz.
> Daher werde ich wohl einfach weniger Daten in der Speicher laden müssen.
> > Unicode (4 byte pro Zeichen) oder UTF-8-Folgen?
> >
> > Es bringt immer etwas, bei solchen Knobel-Fragen auch die
> Problemstellung zu beschreiben - manchmal liegen sinnvolle Lösungen eher
> auf der High-Level-Beschreibung eines Problems. Ich vermute aus Deinen
> Sätzen nun folgendes: Du parsed Text, der Sonderzeichen aus dem
> Unicode-Alphabet enthalten kann, und möchtest diesen Text zerlegen, so dass
> sich zwischendurch Substrings im Speicher ergeben. Mit dem Vorschlag von
> Klaus zusammen könnte man das so angehen, dass Du als Datenhalter eine
> Klasse definierst, die aus einem String plus einer folgenden Subliste
> besteht, ggf. auch aus einem Array aus solchen Paaren.
> >
> > Deine Textbeschreibung aus der ursprünglichen Mail sieht aber
> eingeschränkter aus. Für Dein eingeschränktes Beispiel gibt es ausreichend
> speichersparende Möglichkeiten, bei denen ich ohne Aufwand mit Python an
> 150% des Speicherplatzes einer kompakten C++-Repräsentation rankomme. Ich
> habe Deine C++-Version noch um einen Aufruf von reserve() ergänzt, damit
> sie keinen überflüssigen Heap braucht und dann alle vier Varianten (Deine
> ist jeweils die _1) verglichen. Um den Fußabdruck eines nackten Pythons
> abzuziehen, habe noch ein „Leeres“ Skript entsprechend gemessen. Außerdem
> habe ich Dein Python-Beispiel so geändert, dass eine Referenz auf die
> Root-Liste behalten wird, damit Python nicht alles direkt ab dem „r=l“
> verwirft da unreferenziert. Kompiliert mit clang++ auf einem 64bit mac.
> >
> > /usr/bin/time -l python empty.py
> >          0.04 real         0.02 user         0.00 sys
> >     6782976  maximum resident set size
> >
> > /usr/bin/time -l python test_1.py
> >         47.50 real        45.38 user         2.06 sys
> > 7222611968  maximum resident set size
> >
> > /usr/bin/time -l python test_2.py
> >         49.91 real        49.78 user         0.07 sys
> >    76500992  maximum resident set size
> >
> > /usr/bin/time -l ./test_1
> >          4.01 real         3.77 user         0.23 sys
> >   983851008  maximum resident set size
> >
> > /usr/bin/time -l ./test_2
> >          1.63 real         1.61 user         0.00 sys
> >    43212800  maximum resident set size
> >
> > Grüße,
> > Mark
> >
> ________________________________________
>
> Diese Mail erhalten Sie ueber die Mailingliste python-users der
> Universitaet zu Koeln
> Nachrichten an: python-users at uni-koeln.de
> Abonnement und Benutzereinstellungen:
> https://lists.uni-koeln.de/mailman/listinfo/python-users
> Listenarchiv: https://lists.uni-koeln.de/pipermail/python-users/
>
> pyCologne Homepage: http://pycologne.de/
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-koeln.de/pipermail/python-users/attachments/20190625/c384b459/attachment-0001.html>