Transcript: Arrays und Sequenzen

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Peißen-Podcast. Heute Episode 59. Hi Jochen.

Herzlich willkommen Dominik. 59, meine Güte.

Ja, hi Johannes.

Und hallo Johannes.

Wir machen heute weiter mit dem Flunen-Peißen-Buch, haben wir uns gedacht.

Ja, genau. So, hat sich bewährt.

Ja, ich fand das ganz gut.

Bleiben wir jetzt. Machen nur noch das.

Es ist ja auch lang.

Wenn wir hinten angekommen sind, dann machen wir es nochmal rückwärts.

Dann haben wir es schon vergessen, dann müssen wir es von vorne direkt wieder vorlesen.

Ja, wir hatten, also das Kapitel 2 hat was mit Sequenzen und Listen und sowas zu tun, da hatten wir ja schon mal eine Folge, ne, erinnert ihr euch?

Ja, aber da gibt es einfach immer noch mehr zu sagen.

Genau, ich hatte da auch nochmal reingeguckt kurz und wir haben da, also das ist ein bisschen orthogonal, das ist gut, also es ist halt von der anderen Seite nochmal angegangen und da das Thema sowieso irgendwie wichtig ist, dann kann man das auch von mehreren Seiten mal irgendwie angehen, das ist eigentlich ganz gut.

Okay.

Ja.

Haben wir denn News?

Ja, so ein bisschen, ich habe jetzt, ja, ist halt die Frage, was da alles so drunter fällt, Python 3.13, das machen wir jetzt nicht, aber das kommt jetzt ganz bald.

Ja, also ich finde ja den REPL so schön.

Ja, genau, habt ihr euch alle schon so ein bisschen damit beschäftigt oder gar nicht?

Nee, gar nicht.

Auch gar nicht?

So ein ganz kleines bisschen.

Ja, also genau, also ja.

Der REPL ist total toll, du kannst einfach Defaults jetzt eintragen, den er automatisch lädt, Pakete in deinem REPL.

Das heißt, wenn du den Interpreter aufmachst, dann hat der

Pakete schon geladen. Oder damit

kannst du halt auch Sachen dann überschreiben, weil er dann die Pakete

lädt, die er laden soll. Und du hast

einen Befehlssatz drin direkt, den du möchtest.

Also eine eigene Konfiguration für deinen

Ripple direkt haben.

Man kann einfach Exit eingeben und ist draußen und Multiline

Editing und die History ist ordentlich

und so. Das finde ich jetzt alles nicht so

beeindruckend, weil ich habe eh immer

einen IPython überall.

Ja, aber rate mal, wer das nicht hat.

Der Dominik.

Nee, die Python-Ur-Entwickler.

Deswegen alle

mit allen neuen...

Die schauen dann mit Neid, schauen die so...

Ja, aber iPad ist so cool.

Oder Beep-Python.

Genau, und das geht alles nicht, weil das läuft ja mit der neuen

und in der Entwicklung befindlichen

Python-Version funktioniert das halt nicht.

Das heißt, die müssen immer die Python-Rapid verwenden und die

sagen alle,

das ist so viel besser jetzt, das ist so cool.

Ja.

Ja, das ist typischer

Software-Entwicklungsmechanismus.

oder Softwareentwicklung durch Neid.

Ja. Ja, erstmal bitte ein bisschen

Rennbogenfarben irgendwie in der Konsole,

dann macht das Spaß. Ja.

Und ein großer Teil davon kommt halt auch,

oder kam, also Anregungen dafür

kamen aus PyPy.

Und dann haben sie es jetzt aber nochmal durch die Mangel

gedreht und alle möglichen Sachen gefunden, die man irgendwie

besser machen soll. Jetzt überlegen sie, ob der Kram,

den sie in Seapython jetzt gemacht haben, nicht zurückgeht nach

PyPy wieder.

Aber das ist cool. Also das ist

auf jeden Fall, das sind einige

Sachen, die jetzt auch da immer wieder

zwischen den Leuten dann diskutiert werden und so.

Und da ist auf jeden Fall eine fruchtbare Diskussion

immer so im Stande. Ich höre ja diesen

Copy-By-Podcast und da ist eigentlich

PiPi immer mit dabei oder

ja,

Karl Friedrich

bei Band als

irgendwas, das hat er dazu gesagt.

Ja, also das ist auf jeden Fall cool.

Genau, Python 3.3,

die Repel-Geschichten.

Ja, es gibt halt, also das größte,

das dickste Feature, was immer alle

nennen, ist halt

Free Threading, also

man kann den GIL

abschalten.

Ja, also... Das sind schon, das würde ich

schon sagen, das sind schon nennenswerte News.

Ja, ja, schon, schon, klar, und also

in gewissen Fällen bringt das sicherlich

auch viel, aber... Die auch vielleicht eine eigene

Episode brauchen. Ja, genau, da müsste man auch mal

äh... No-Gay.

Genau.

Ja, das ist halt auch mit drin. Hashtag, Hashtag No-Gay.

Ja, überhaupt

dieser ganze, der, äh,

Es gibt

einen Just-in-Time-Compiler, der jetzt mit dabei ist.

Der macht zwar noch nicht viel, aber er ist auf jeden Fall

jetzt drin. Das heißt, da könnte

man in Zukunft auch irgendwie einige

coole Performance-Verbesserungen

erwarten. So ein

Copy-and-Patch-Jit

ist jetzt tatsächlich

in Python-Interpreter mit drin.

Ja,

was haben wir noch alles?

Genau,

es gibt jetzt farbige Phrase-Bags.

auch wieder so ein, ja,

für den Alltag irgendwie ein bisschen besser.

Ja gut, das sind natürlich schon alles.

Also er hat auch immer einen guten Hint, er

racet jetzt nicht einfach irgendwas und denkt sich so, oh ja,

komisches Straightback, so weiß ich nicht wo,

sondern er hat oft schon eine gute Intuition, was das

sein könnte. Ja, genau.

Da ist jetzt auch eine...

Also da sind jetzt Dinge

verschieden große Signifikanz

dabei, würde ich sagen. Ja.

Ja, aber tatsächlich für Anfänger,

also was die oft irgendwie,

ein Problem, das sie hatten, ist,

du nennst

dein Python-Modul

oder Skript, das du gerade schreibst,

nennst du halt genauso wie ein Standard-Lib-Modul

und

wenn das Versuch auszuprobiert

passiert, kriegst du eine total

kryptische Fehlermeldung, die dir echt gar nicht

weiterhilft. Und

da gibt es jetzt eine Fehlermeldung, die sagt,

kann es sein, dass du das genannt hast wie ein Standard-Library-Modul?

Das ist aber nicht gut. Mach das mal anders.

Und das ist natürlich hilfreicher irgendwie.

Ja, das ist tatsächlich was, was in

Python-Kursen oft vorkommt, weil man halt irgendwie

haben naheliegende Namen und wenn du

deine Funktionalität schreibst, die

sich mit einem Thema beschäftigt, dann wählst du

den naheliegenden Namen für deine

Python-Partei und schon hast du das Modul

überschrieben. Deshalb, das ist

schon gut, aber ich würde sagen,

es ist, sagen wir mal, technologisch

weniger fortschrittlich

oder weniger kompliziert

als Hashtag NoGill.

Ja, das ist richtig. Da ist eine ganze Menge

Enttäuschung und Aufwand drin gewesen, glaube ich.

Ja.

Ja, ansonsten, genau.

Ich weiß gar nicht, ich habe noch irgendwas zu lesen.

Wir machen zu 3.13 auf jeden Fall

auch noch eine Episode, denke ich, dann können wir das mal

alles zusammentragen.

Ja, ansonsten,

was war noch?

Django 5.1 gibt es auch

irgendwie jetzt.

Ja, aber ändert sich da irgendwas?

Da war auch nichts,

was ich mir jetzt so spontan in Erinnerung geblieben wäre.

Ja, also diese Django-Releases,

da gibt es ja sehr viele immer.

Und ich habe das Gefühl, also klar,

die machen Sicherheit, die machen so Verbesserungen

und dann machen sie schon immer mal wieder

coole Sachen, da mit

diesem Postgres-JSON ändern sich ja schon schöne

Dinge, aber

so richtig...

Oh, wir haben da schon drüber gesprochen, glaube ich.

Wir haben schon drüber gesprochen, diese Query-String-Geschichten

und so, brauchen wir nicht nochmal. Ja, ich hätte, ich habe mir

die Videos nicht aufgeschrieben, aber ich...

Ja, aber ich meine, Django

fühlt sich an, als ob es so stabil ist, dass es

sehr inkrementelle Verbesserungen sind.

Ja, ja.

Das ist ja auch was Gutes, würde ich auch sagen.

darauf verlassen kann, dass das halt, was man

jetzt weiß, wie es funktioniert, dass es auch so bleibt.

Ja, aber

ich hätte noch eine Überleitung zu einer ganz

interessanten Frage vielleicht, wenn wir jetzt hier

schon eigentlich mit den News mehr oder weniger am Ende sind. Also ich weiß

nicht, ob ihr noch was habt. Ich hätte jetzt nur noch irgendwie, es gibt

neue LLM-Modelle, sowas wie

O1 oder... Kann man jedes

Mal als News sagen. Genau, also es gibt

neue, probiert es mal wieder aus. Es gibt

ein 700 Milliarden Parameter-Modell

von Lama.

Lama 3.1 700B.

Ja.

Das, ja.

Brauchst den größeren Rechner.

Also O1-Preview ist ja aber trotzdem auch noch new.

Und das ist, also

ich höre, das ist besser als Cloud wieder.

Ja, also bisher, also genau,

ich würde sagen, also diese ganze

Artefaktsnummer,

ich habe jetzt in letzter Zeit häufig

Cloud, also

das Chat-Interface von

Anthropic

verwendet, weil das halt einfach für Code-Geschichten

oft ein bisschen besser war als

als

GPT-4O.

Und

ja,

aber jetzt inzwischen, also ich weiß nicht genau,

ich habe es noch nicht wirklich ausprobiert, ehrlich gesagt,

weil es ja auch gerade erst rausgekommen ist, aber

das soll halt sich dann auch noch mal wieder

ein bisschen

besser drüber sein.

Also ich finde es jetzt schon super alles.

Also das ist auch, das ganz normale

GPT-4O und so war auch schon super

und die Anthropic-Dinger fand ich auch total klasse.

Also ich bin eigentlich sehr zufrieden.

Es ist ein gutes Zeichen, wenn

einen Chief Machine Learning Engineer

Mensch Anthropic nicht kennt?

Das wäre ein schlechtes Zeichen, würde ich

meinen. Ja, wie kann das denn sein?

Also gut, Machine Learning ist halt ein großes

Feld.

Ja, du kannst dich auch in irgendwas

spezialisieren oder in einem ganz anderen Feld irgendwas

machen, mit LLMs nie irgendwas zu tun haben.

Aber ja, gut.

Ja, also es war schon gut.

Also die großen Namen musst du ja schon

wissen, oder?

Ja, gut.

Aber ja, jetzt haben wir

jetzt gerade eben hier mit dem die Karriere versaut.

War eigentlich eine gute Alternative, ich bin gespannt.

Also O1, ich finde es echt very nice.

Hilft, also es ist so ein bisschen

fehlerfreier

bei Coding-Ding

und so ein bisschen deeperes

Knowledge und es macht sehr viel Spaß, diesen

Gedankengang zuzugucken.

Und das, was ja auch neu ist,

das ist aber schon bei 4.0 drin,

ist halt, dass du ein Gedächtnis hast

jetzt auch. Ja,

was sie da so nennen.

Doch, doch, das ist schon, das funktioniert auch.

man muss sich halt überlegen, ob man möchte,

da hast du es gespeichert, was man da bespricht.

Bitte merkt ihr alles, was ich hier gesagt habe.

Ja.

Aber vor allen Dingen ist das gar nicht so schlecht, weil, also,

ja,

interesting. Ja, ich meine,

also, wenn man jetzt LLMs über die

Kommandorenzahler mit dem LLM-Tool zum Beispiel

benutzt, dann hat man das ja auch irgendwie,

man ist ja lokal in der SQLite, ich weiß nicht,

ja, ist auch immer die Frage, wie möchte man

dieses hier eigentlich zeigen?

Ja, also, ich frage tatsächlich so nach

nach so Morgenroutinen oder sowas und sagt dann halt so, hey,

was ich denn so mache und dann schlägt das Ding mir halt so Dinge

vor, als dass es so, äh, macht mit mir

so Rituale und so. Ich find's sehr lustig und das

funktioniert toll. Und, ähm, das

ist, glaub ich, gar nicht so blöd.

Weil's einen so dabei hält, sich so selber

zu entwickeln.

Ja, cool. Das kann man natürlich auch mit anderen Quellen

machen, dass nicht, dass man jetzt irgendwie so ein

Eifer bräuchte, aber es geht damit sogar

relativ gut.

Ja, genau. Ansonsten würd ich nämlich Django

irgendwie mal kurz zu der Überleitung nutzen,

da wir jetzt sowieso nicht so viel News haben.

ich habe, und

ich mache gerade ein neues Projekt, weil

irgendwie ich prokrastiniere so gerade die Dinge, die ich eigentlich

machen sollte und, naja,

wer kennt das nicht?

Ja, sinnvolles Prokrastinieren.

Produktives.

Genau, der New Repository

Button bei GitHub, der wird immer so

shiny und fängt dann zu leuchten

und dann denkt man sich, ah, es geht nicht anders,

ich muss draufdrücken und dann habe ich das halt

mal wieder gemacht.

Genau, ich bin nämlich gerade dabei,

irgendwie

mal

meine Bewerbungsunterlagen

beziehungsweise so CV

und so Zeugs irgendwie auf einer Webseite zu,

weil ich hätte das immer so in einem Textpfeil,

aber dann habe ich fünf unterschiedliche Varianten, die alle nicht aktuell

sind und irgendwie

für unterschiedliche Zwecke gebraucht wurden

und dann denke ich mir so, naja gut, welches nehme ich denn jetzt?

Und dann weiß ich es nicht und dann denke ich mir, ah, ich müsste mal

und ah, alles schrecklich und warum packe ich das nicht einfach

auf eine Webseite? Das ist doch eigentlich ganz gut.

Ja, ich habe auch mal ein paar gute gesehen, wo ich mir noch eine To-Do-Liste

habe, wo draufsteht, dass ich mir ein Vorbild daran nehmen wollte.

Vielleicht ist es ja jetzt dein Zug.

Ich habe auch schon mal so ein Projekt angefangen, Jochen.

Ja, gut, dann jeder muss sowas.

Ich habe meine Sachen immerhin schon mal in Markdown stehen.

Das ist schon mal ein Fortschritt.

Ja, Markdown ist schon mal nicht so schlecht.

Jochen, guck, an der Stelle,

wir haben uns ja kürzlich darüber unterhalten,

an der Stelle muss man jetzt sagen,

jeder Softwareentwickler, den man beauftragen kann,

muss immer wieder sowas machen.

Also, falls jemand zuhört,

der den Jochen oder mich beauftragen möchte.

Ja, oder mich.

Also, das ist ja genau der Punkt.

Ja, den Dominik auch.

Ja, wir wollten halt so ein bisschen,

vielleicht heute mal Werbung in eigener Sachen machen, oder?

Können wir ja auch. Können wir ja gerne machen.

Also ihr könnt uns mieten, buchen oder sowas,

wenn ihr wollt. Wir sind prinzipiell

käuflich. Ja, also für

Projekte. Wie machen, glaube ich,

Peißen? Das ist alles eine Frage des Preises.

Nein, bei interessanten Sachen sind wir

auch zur Diskussion bereit, oder? Genau.

Von ein bis drei Leuten könnt ihr da

relativ viel Kappa bekommen, die auch gute Sachen

machen.

Ich habe gehört, wir haben alle ein Buch

gelesen. Oh ja, genau. Wir könnten

eigentlich mal mit dem Thema anfangen?

Ja, listen.

Sequenzen.

Sequenzen, genau.

Ja, Sequenzen.

Das zweite Kapitel ist deutlich länger

als das erste Kapitel. Das erste Kapitel war

so ein Häppchen.

Und das zweite Kapitel ist

schon ein Brocken.

Wie weit hast du denn gelesen?

Bis zum Ende des zweiten Kapitels.

Seite 39.

Ja, sowas ungefähr.

Keine Ahnung, wie weit.

Das muss ich jetzt nachgucken.

Seite 58.

Dann hast du wesentlich weiter gelesen.

Das ist Chapter 2,

An Array of Sequences.

Das mit 59 geht auch weiter bei List is not

Seance. Und dann geht es so ein bisschen

in die Diskussion darüber, wann man was machen möchte.

Ja, genau. Das ist tatsächlich, das habe ich mir extra

markiert, es geht bis Seite 77.

Und Seite 59 ist nämlich das, worüber

ich mit euch dann gleich sprechen möchte.

Ich bin so schlecht. Das ist ja erst am Ende des Kapitels.

Ja, also wir müssen auf jeden Fall diese Trade-offs

finde ich, glaube ich, ganz gut, weil man was für eine Art

und Weise von

Sequenz haben möchte,

vielleicht gar nicht so uninteressant.

Ja, also ich finde auch genau

der grundsätzliche

Blickwinkel drauf, den finde ich ganz interessant, weil

wir hatten ja schon mal darüber geredet und da hatten wir

eher den so, ja, wie implementiert

man das eigentlich oder was sind so die algorithmischen

Geschichten, die man damit machen kann und

hier sind so die grundsätzlichen

Unterschiede zwischen den Dingen halt

eher sowas wie, ist es ein Container

oder ist es irgendwie flach oder

ist es irgendwie

mutable oder immutable

sozusagen. An den Achsen

orientiert sich das Ganze irgendwie und das ist

einfach ein anderer Blickwinkel und das fand ich eigentlich auch ganz interessant.

Ja.

Jedenfalls, genau.

Also

das ist halt irgendwie eine ganz

fundamentale Geschichte und

der Unterschied

zwischen zum Beispiel Container und Flat ist halt einfach,

dass in einem Container sind halt

Referenzen auf Objekte drin und da kann halt alles

mögliche drin sein. Da kann ganzer Zoo,

Baum, sonst was, Dings von

irgendwie anderen Sachen, die da noch drin liegen, sein.

Während,

also, und das geht natürlich mit Liste, also

Python List geht das.

Während jetzt sowas wie, was halt auch eine

Sequence ist,

Array enthält halt flach einfach nur

die entsprechenden

Werte.

Halt ein Header mit irgendwie, wie sind die

Daten dahinter jetzt strukturiert und dann kommen halt

einfach nur die Daten.

Und genau, das ist halt

schon mal ein großer Unterschied. Das fand ich übrigens auch interessant,

das habe ich nicht gewusst, dass

Tuppel halt auch

weniger Hauptspeicher

belegen als die, also

Tuppel sind immer ein bisschen schneller als Listen,

weil das ist bei Listen halt so

doppelt indirekt,

weil es sich ja auch ändern kann und bei

Tuppel nur einmal indirekt.

Jetzt habe ich die Stelle nicht mehr.

Also, aber

das ist vielleicht auch was, was man erwähnen kann.

So eine Liste verbraucht a priori schon mal mehr

speicher weil es platz haben muss für zukünftiges wachstum und wenn ich das

richtig erinnerung gehabt dann machen listen so ein exponentielles wachstum

das heißt die haben wir mal eine gewisse menge lehrer elemente im hintergrund und

ich glaube das sind zwei potenzen das heißt wenn man diese größe überschreitet

dann passiert also ein riesig und dann verdoppelt sich diese liste das heißt in

dem moment hat man dann etwa 50 prozent des potenziellen speichers einfach

verschenkt, weil da keine Referenzen

drin sind.

Wobei Referenzen natürlich relativ

klein sind. Also die sind jetzt nicht

im Kilobyte-Bereich, sondern die sind

natürlich nur im Pointer-Plus.

Ja, also normalerweise. Die sind im Pi-Object-Bereich.

Genau, 8-Byte.

Ich glaube, es sind mehr, Jochen, oder?

Das sind doch Pi-Objects, die da drin sind.

Achso, wenn du das in Python-Objects,

ja, da hast du normalerweise, du hast einmal

einen Ref-Count.

Du hast so einen Tag drin und so einen

Typ. Und

die Speicheradresse

oder sowas. Genau, also den

Point. Hast du nicht auch noch einen Reference-Count drin?

Ja, genau. Also ich meine, das minimale

Python-Objekt

ist ein Float.

Ich weiß nicht, ob es genau gleich ist.

Float, da bin ich mir aber ziemlich sicher, dass es das kleinste

mögliche

Python-Objekt ist. Und das hat, glaube ich, 24 Byte,

weil das ist halt genau irgendwie

der Wert.

Das ist sogar inline, oder?

Ja, du meinst bei kleinen Werten?

Bei Float ist es sogar inline, oder?

Da hast du keine Referenz auf irgendeine andere Speicherzelle.

Nein, das ist einfach direkt drin.

Das ist einfach direkt, genau.

Das ist nur der Wert direkt, der RefCount und der Typ.

Aber auch das sind schon 24 Byte.

Ja, klar.

Für im Grunde nur 8 Byte Speicher hast du schon 24 Byte Speicher gebraucht.

Genau.

Aber die Größe ist ja gleich, egal ob du einen Tube-Loader in der Liste hast.

Ja, das ist richtig.

die freien Elemente, das hast du

beim Tuple natürlich nicht. Beim Tuple

sagst du, hier, ich brauche sieben Stück

und dann kriegst du sieben Stück und nicht acht und nicht

sechzehn und auch nicht eine andere Anzahl.

Ja, und du kannst halt vielleicht bessere Optimierung

machen, weil du immer genau weißt, wie lange ist das, weil du ja schon

weißt, was so steht, weil du das nicht mehr verändern kannst. Und du kannst

diese ganzen Methodendinger weg

und den Overhead weglassen für, ich muss da

was reinbasteln oder rausnehmen.

Ja, okay, aber du hast natürlich

einen Virtual Table, hast du immer

noch.

Ja, aber ich weiß nicht, ob das der große Unterschied ist.

Ja, man darf ja nicht so viel ausmachen.

Ha! Okay, ich habe es doch gefunden.

Ja, okay, dann bitte.

Kompliziert.

Ich dachte gerade schon, ich habe schon irgendwie,

ich dachte schon, wahrscheinlich habe ich einfach

Dinge haluziniert und...

Oh, oh, Jochen.

Aber nein.

Also, genau.

LLM, Jochen.

Ja, ja.

Manchmal, man weiß es nicht so genau.

genau, die Referenzen

zu den Items in einem

Tuppel sind halt in einem Array,

die sind halt in einem Array in dem

Tuppelsdruck halt drin,

aber in der Liste sind

quasi,

also die Liste hält

einen Pointer zu einem Array

von Referenzen,

die irgendwo anders sind, weil das

Problem ist halt, wenn

die Liste größer wird, als sie

eigentlich quasi als momentan

alloziert ist an Aufsprecher, dann

muss man den ganzen Kram Rea allozieren können.

Und das geht halt nur, wenn du...

Ja, das ist dieses Resizing. Genau, genau.

Und das macht halt nochmal einen Interaktionsschritt

erforderlich. Und bei einem Tuple weißt du halt,

ja, das passiert halt nie. Ich kann einfach

ein Array von den Werten nehmen.

Also vor dem... Okay, das ist quasi so

ein bisschen wie das, was wir eben auch schon

beim Float angesprochen haben, oder?

Bei einem PyObject kann ein Float direkt

drin sein und dann hast du keine Referenz

auf irgendwas. Bei einem String

zum Beispiel geht es nicht. Bei einem String, das

PyObject ist halt der Tag und der

Typ und der RefCount und

die Referenz auf die tatsächlichen

Daten.

Und hier ist es genauso, oder? In einem Tuple kannst du es direkt

drin haben und

in einer Liste brauchst du erst noch eine Referenz

auf die tatsächlichen Daten.

Genau. Die dann wiederum halt

in dem Fall eine Sequenz von

Sachen sind, im Tuple-Fall

direkt die Sequenz der Sachen und

im Listen-Fall eine Referenz

auf eine Sequenz von Sachen. Ja. Okay.

Ja, okay, gut, das verstehe ich

natürlich. Das ist ein Pointeraufruf mehr und

Pointeraufrufe sind ja bei modernen Prozessoren

so das Schlimmste,

was du machen kannst.

Ja, es ist alles kein großer Unterschied

wahrscheinlich, faktisch.

Aber ja.

Müsste man mal einen Test machen.

Ja.

Es gibt ja durchaus Menschen, die

sagen,

nur High-Performance-Computing ist sinnvolles

Computing.

Das ist ja generell so, oder? Nur High-Performance

ist sinnvoll.

Dieses Casual, irgendwie

Slow-Food, irgendwie

ich schreibe meinen eigenen

Algorithmus, das ist ja nicht gut.

richtig sinnvoll, wenn das

richtig machst.

Also ich meine,

es gibt

ja so Leute, es gibt diesen Casey

Muratory, der ist relativ bekannt,

der schlägt immer wieder

auf mit solchen, der ist halt,

der vertritt quasi diese extreme Position.

Wenn du es nicht

richtig machst und dann auch

hier die

SIMD-Inlines von den verschiedenen Prozessoren

benutzt, dann hast du es eigentlich gar nicht richtig gemacht.

Und das ist die Ursache allen Übels.

Deshalb ist ein Computer heute so scheiße.

Und das ist natürlich das

eine Extrem und das andere Extrem sind

halt, naja, so Menschen wie

wir, die Python und JavaScript

benutzen und sagen, komm,

Skriptsprache, Hauptsache das

Entwickeln ist angenehm.

Und irgendwo dazwischen,

ich meine, gelegentlich machen

wir ja auch High-Performance.

Da muss man dann halt zu

Techniken greifen.

Die Frage ist, was High-Performance eigentlich ist. Da gibt es ja vielleicht

verschiedene Blickwinkel drauf. Ja, gibt es auch

verschiedene Blickwinkel, wobei, sobald

du halt in so Data-Bereiche reingehst,

ja, und sobald es mehr als ein Megabyte ist,

musst du schon dir zumindest

Gedanken drüber machen, ob das sinnvoll

ist, das einzelne

Elementweise zu verarbeiten oder ob du da nicht

zumindest ein bisschen Batch-Verarbeitung machen kannst.

Und je mehr es wird, umso mehr

musst du drüber nachdenken.

Aber in so einem Fall würde natürlich auch keiner

von uns eine Python-Liste verwenden, oder?

Also ich meine, für numerische

Daten oder für High-Performance-Daten würde

ich nicht eine Python-Liste verwenden.

Was denn dann?

Das ist ja eine sehr gute Frage,

zum Beispiel, der Jochen hat es schon angesprochen, Array.

Aha. Das ist der erste Schritt

auf den Weg zur Effizienz und ist

sogar in Python und pures Python und so weiter

und so fort. Also Import Array, Array.Array.

Ja, genau. Genau, richtig.

Die generelle

Eigenschaft von so High-Performance-Sachen ist

ja immer, dass man

Komfort aufgibt für

Geschwindigkeit.

Und das ist generell so, ja, und man kann das

in beide Richtungen beliebig weit treiben.

Man kann den Komfort komplett aufdrehen

und dann halt

sagen hier, Typen sind egal

und ein Container

kann alles enthalten und auch nix

und verschiedene Dinge und so weiter

und so fort, so wie wir es in Python bei Listen haben.

Und du kannst aber auch ganz ans andere

Ende gehen und sagen, okay, SimD

und das muss im Speicher in der richtigen Stelle liegen

und es muss byte-aligned sein

und es muss so aufgebaut sein, dass die

Cache-Lines zusammenpassen.

Und das ist aber

eine Skala dazwischen, so eine Sliding Scale

dazwischen. Du kannst das ein bisschen

mal weiter in die eine Richtung drehen oder ein bisschen

weiter in die andere Richtung drehen.

Und der erste Schritt, den du von

Python-Listen

wegmachen kannst, ist halt Array.

Array.Array.

Weil

das ist dann nicht mehr diese Indirektion, sondern es ist

direkt eine

Auflistung

von Dingen, also eine Abfolge

von Dingen, die auch direkt

da drin gespeichert werden.

Das bedeutet aber halt, dass die alle gleich

sein müssen. Und da fällt schon der erste Komfortteil

weg. Du musst vorher wissen, was du da rein

tust.

Vielleicht kannst du mal kurz, was ist

Cash-in-Line?

Cash-in-Line.

Das braucht, glaube ich, auch eine eigene Episode,

aber es ist eine Eigenschaft von Prozessoren.

Wir haben ja eben schon gesagt,

wenn du irgendwie einen Pointer aufrufst, dann ist das

das Schlimmste, was du machen kannst,

weil der Hauptspeicher eines Computers

wesentlich langsamer ist als der Prozessor

eines Computers. Das hat sich

so entwickelt. In den 80ern

und 90ern war es noch nicht so. Da waren die irgendwie gleich

schnell. Und dann sind die Prozessoren

exponentiell schneller geworden und der Speicher

ist halt nur quadratisch

schneller geworden. Und dann

waren die Prozessoren auf einmal

eine Million Mal schneller als der Speicher und deshalb

ist das das Problem,

in dem wir leben.

Da kommen jetzt Worte, die hat sicherlich jeder schon mal gehört.

Jeder Prozessor hat irgendwie so einen

L1-Cache.

Das ist der Hauptspeicher, der ganz nah

am Prozessor ist, der ist noch fast genauso

schnell wie der Prozessor selbst, dann gibt es den L2

Cache, der ist auf dem gleichen

Prozessor die drauf, aber daneben

und ist deshalb

nicht mehr ganz so schnell, also nur

noch, nur ein Zehntel

so schnell wie der Prozessor

und dann gibt es den L3 Cache bei den neuen

Prozessoren, der ist vielleicht

auf dem gleichen Chip, aber nicht mehr auf dem gleichen

die und deshalb ist es nochmal 10

mal langsamer

und dann gibt es den Hauptspeicher und der ist nochmal

1000 mal langsamer und

Und das ist eben so ein Trick, weil man weiß, es gibt was, das heißt Data Locality.

Wenn ich mit einem Datum, mit einem Datenpunkt gearbeitet habe,

dann werde ich vielleicht mit Datenpunkten, die in der Nähe gespeichert sind, arbeiten.

So funktionieren diese Caches.

Das heißt, die speichern eine kleine Speichermenge aus dem Hauptspeicher in den Prozessor rein.

Und wenn ich dann tatsächlich mit dem daneben liegenden Datenpunkt arbeiten möchte,

dann habe ich da den schnelleren Zugriff, weil der schon gecached ist.

Und prinzipiell, wenn man alle Leistungen aus einem Prozessor rausholen möchte,

dann muss man dafür sorgen, dass der Prozessor immer nur solche Sachen bearbeitet,

die schon im Cache sind.

Da muss man quasi an die richtige Stelle hüpfen vorher.

Da muss man, genau, da gibt es Techniken, wie du dafür sorgen kannst,

dass bestimmte von diesen Cache-Lines, diese Caches sind in sogenannte Lines aufgeteilt.

Das heißt, da sind immer 16 Byte drin oder 64 Byte.

Also die werden natürlich größer, je weiter du nach draußen gehst.

Kurz vor das Passwort, was da irgendwo im Speicher steht,

möchte ich gerne springen oder kurz danach.

Ja, wenn du das versehentlich in den Cache lernst, ist auch schlecht.

Wenn du diese Cache-Lines immer wieder überschreibst,

ist schlecht, wenn du immer über die gleiche Cache-Line.

Aber da sind wir jetzt natürlich wesentlich näher am Prozessor,

als wir mit Python je hinkommen.

Das Wichtige an der Stelle zu wissen ist, dass wenn wir im Hauptspeicher hin und her springen, dann ist das potenziell was sehr Langsames, weil dieser Hauptspeicher erst in den Prozessor reingeholt werden muss, damit er da verarbeitet werden kann. Und das ist in Prozessorzeiten eine Ewigkeit.

Also das ist das, was Assembler macht, wenn es irgendwas in den Register reinlädt.

Genau, wenn du es in den Register reinleitest, das ist quasi das, was im Prozessor ganz innen drin ist, das Register-File, das ist das Schnellste, das ist in den Prozessor eingebaut und danach werden die Hierarchien, wird es in der Hierarchie immer um Faktor 10 oder 100 oder 1000 langsamer.

Wenn du es jetzt also schaffst, dafür zu sorgen, dass deine Daten möglichst nah beieinander liegen, dann bedeutet das, dass wenn du die sequenziell verarbeitest, dass die dann schon näher am Prozessor dran sind und entsprechend schneller verarbeitet werden können, als wenn du für jeden Eintrag einmal in den Hauptspeicher springen musst und das komplett nah reinholen musst.

Und das ist ja üblicherweise die Situation, die du hast, wenn du eine Python-Liste hast. Das ist das, weshalb diese doppelte Indirektion so langsam ist, weil du einmal zuerst die Liste der Referenzen abholen musst und dann nochmal die Referenz selbst. Und selbst wenn du da sequentiell durchgehst, können diese Second-Level-Referenzen, die können ja irgendwo liegen, wo halt gerade der Speicher hin alloziert wurde.

Bei einem Array ist das aber anders. Bei einem Array liegen die Werte alle hintereinander direkt aneinander gereiht im Speicher. Das heißt, wenn du durch einen Array, durch einen Array.Array durchgehst, das sind, man muss ja auch ein bisschen vorsichtig sein, dieses Wort Array hat ja in jeder Sprache eine andere Bedeutung als in der Sprache.

Wir sprechen hier jetzt von Python-Arrays.

Also in Python, das Modul

Array.Array

enthält so eine Implementierung

von einem

Container, der

Daten des gleichen Typs

im Speicher sequenziell gepackt

speichern kann. Also zum Beispiel

Floats oder Integers oder

andere Dinge, die man

da reintun möchte. Und das

hat den Vorteil, dass wenn ich da sequenziell durchgehe,

dass die dann prinzipiell mehr der Prozessorarchitektur entsprechen,

dass ich nichts Interaktionslevel habe,

dass ich die eventuell schon im Cache bereitliegen habe,

wenn ich sie verarbeite.

Und so, wenn ich eben numerische Datenverarbeitung machen möchte,

kann das sein, dass das ein extremer Speed-Up ist.

Aber es geht nur für numerische Daten?

Nö, aber was letztlich da drin ist, das weißt du ja nicht.

Also was heißt numerische Daten?

Das muss eine feste Größe sein.

Ja, aber auch wenn jetzt da, gut, kommt halt drauf an, was,

aber das kann ja auch irgendwas anderes bedeuten.

Das kann ja Text sein oder, also, hm.

Okay, aber bei Text bedeutet das dann halt Immutability.

Also, weil die Repräsentation des Textes halt Zahlen,

immer derselbe Text ist.

Sie sind auch immutable, aber ich würde mal, zum Beispiel,

Ich habe mal eine

Array

Geschichte benutzt in

Cyclet Learn bei dem

Tokenizer,

also bei dem

TF-IDF-Vectorizer

und da waren es dann halt

IDs von, also die

Nummer

von einem Token.

Das ist ja dann nur eine Nummer.

Und die kann man ja auch in Arrays packen.

Ja, oder Booleans,

Arrays von Booleans. Ja, das geht ja auch.

Also die Frage ist, sind das jetzt

numerische Daten? Ich weiß nicht, also

was die Daten bedeuten. Also klar,

es muss natürlich irgendwie was Fixes

sein, aber, und ach so, das kann

auch anders strukturiert sein. Das ist jetzt,

weiß ich gar nicht, ob das mit

Array-Array geht, ob das

sehr viele kompliziertere

Struktur haben kann, aber

es gibt allgemein Memory Views

und die sind halt dafür da, dass

du halt diese Daten irgendwie

rumschieben kannst und

du kannst da halt einen anderen Header davor

setzen, zum Beispiel mit einem NumPy

oder so und dann ist das plötzlich ein mehrdimensionales

Array oder halt irgendwie eine Matrix

oder sowas. Oder du kannst halt

und Transformationen,

wenn du jetzt sagst, okay, ich möchte das jetzt einmal

kippen

oder irgendwie

transposen

oder was auch immer, dann sind das

Operationen, die nur den Header betreffen, aber nicht

die Daten selber. Also die Daten bleiben halt so liegen,

wie sie da so sind, halt im Hauptspeicher.

Ja. Wobei Transposition,

Jochen, ist ja auch sowas Gefährliches. Dann hast du wieder,

wenn du den

Speicher dann nicht auch transponierst, dann hast du

wieder schlechte Speicherzugriffspattern.

Ja, ja, das kann natürlich dann

blöde Konsequenzen haben, wenn man dann halt

irgendwas Blödes damit macht, dann ja.

Ja, gut, ich kann mit jeder Programmiersprache

schlechte Programme schreiben, das ist gar kein Problem.

Ja.

Nee, ich meine, okay, aber da bist du

jetzt schon einen Schritt weiter, ja. Also Array

ist das schon, ist ja noch

da übernimmt Python noch so ein bisschen das Management für dich,

aber bei MemoryView ist ja hier

eine Sequenz von Bytes, die im Hauptspeicher

liegen. Genau.

Mach damit, was du willst.

Und da bist du wieder direkt einen Schritt

weiter in Richtung Performance.

Potenziell, ja.

Man kann alle Werkzeuge wenden, um langsame Programme zu

schreiben.

Bist du einen Schritt weiter in Richtung Performance

und einen Schritt weiter weg von Komfort.

Weil du dich halt

selber drum kümmern musst.

Aber dafür kannst du prinzipiell so

Tricks malen, dass du den Header veränderst oder

dass du nur irgendwelche Sachen

innen drin veränderst oder dass du, keine Ahnung,

je nachdem, was das Problem halt erfordert.

Machst.

Ja, jetzt sind wir wirklich schon ganz tief

in dem Abschluss des Kapitels,

nämlich der Abschluss des Kapitels heißt

When a list

is not the answer.

Der Hauptteil des Kapitels

beschäftigt

sich ja schon mit Listen, ja, und da gibt's,

also es sind wirklich schöne Sachen drin.

Wusstet ihr das mal auf Slices?

assignen kann. Oh ja, ja, das ist cool.

Das ist ein Trick, den ich

nicht so, also

den ich nicht kannte, den ich nicht wusste, dass das geht.

Was meinst du mit nice assign?

Vielleicht müssen wir das kurz erklären.

Ja, also wenn ich eine Liste habe,

dann kann ich mir da ja einen Slice rausholen.

Also wenn ich eine Liste mit zehn Elementen habe, kann ich sagen, ich möchte

Element drei bis vier.

Das ist dann diese Doppelpunkt

Notation und dann kriege ich da eben so eine

Subliste raus.

Und

diese Subliste

Die ist mutable. Und die bezieht sich auf die Elemente, die in dieser ursprünglichen Liste drin waren.

Also wie ein View auf diese Liste an der Stelle.

Ja, so ein bisschen, aber noch mehr.

Also wenn ich jetzt hier so einen Slice raushole aus dieser Liste. Nehmen wir mal an, ich habe eine Liste, das ist jetzt hier im Beispiel drin, Seite 50, falls jemand mitlesen möchte.

da ist eine Liste,

das ist eine Liste von Range von 10, also es sind

Elemente 0, 1, 2, 3, 4, 5, 6, 7, 8, 9

drin. Und da hole ich

mir jetzt einen Slice raus,

Index 2,

Doppelpunkt 5.

Das sind drei Elemente, die ich hier raushole,

2, 3 und 4. Und

da mache ich jetzt eine

Zuweisung auf diesen Slice. Also ich sage

L Slice

2 bis 5 ist gleich

und hier in dem Beispiel ist es jetzt

20,30, also eine Liste mit nur

zwei Elementen.

Dann habe ich

aus dieser Liste was rausgeschnitten und dann

die Stelle, an der das vorher drin stand,

was anderes reingeschrieben.

Und das wusste ich nicht, dass es geht. Das wusste ich

nicht, dass man da so

Operationen drauf machen kann.

Slices quasi,

also ganze Slices

ersetzen kann. Man kann es aber rückwärts machen.

Man kann auch einen Slice

löschen. Das nächste Beispiel ist Dell

und dann hast du in der Mitte was rausgelöscht.

Super interessant.

Tatsächlich, da wäre ich auch nie auf die Idee

gekommen, das zu machen.

Aber es wird noch schlimmer, Jochen, es wird noch schlimmer.

Das nächste Beispiel ist ein Slice,

der einen Step hat.

Oh Gott, oh Gott, oh Gott.

Und wenn du auch den zuweist,

dann werden halt die Elemente ersetzt,

die diesen Step

abbilden.

Also jedes

gerade Element kannst du ersetzen.

Mit einer Zuweisung.

Ja.

Wusste ich nicht.

Okay, nee, das war mir jetzt auch nicht, dass das,

da kann man auch, also

da, also

ja.

Wo wir bei Dingen, die wusste ich nicht waren, da habe ich ja auch

irgendwas rausgefunden, zwar, dass man halt Dinge direkt

assignen kann, wenn zum Beispiel eine Liste mit einem Element

rumkommt, hat Jochen

gesagt, der benutzt das ständig,

aber wenn irgendwo eine Liste,

man will das an den Event haben, dann machen

oft ja die Leute Index 0, aber man kann einfach

das assignen zu einem Ding, was in der Gegend dransteht.

Genau, man macht vorher RG-Klammer auf,

irgendwie das Element, gibt dem Namen RG-Klammer

wieder zu. Ich habe das oft in Tests

oder so, wenn ich weiß, also da kann halt

nicht mehr drin sein als dieses eine Ding,

dann mache ich das halt so.

Okay.

Das mache ich immer mit Index 0.

Ja, aber

das Problem ist,

wenn das jetzt unerwarteterweise

aber was anderes zurückgeben sollte,

was nicht nur dieses eine Ding hat, sondern halt

vielleicht 5, dann fällt das bei dir halt

sind, dann kriegst du da... Ich krieg keine

Fehlermente. Du kriegst einen Index-Error, aber ich krieg

einen Value-Error. Nee, ich krieg keinen Index-Error. Ich krieg

nur einen... Es kann halt sein,

dass es weiter funktioniert. Ja, nur wenn es die 0 nicht gibt.

Okay, ja. Genau. Du kriegst nur einen Fehler, wenn

es die 0 nicht gibt. Und die 0 gibt es ja eigentlich immer.

Genau, aber unter anderem ist es halt Value-Error,

weil das Element irgendwie nicht...

Die Liste nicht das eine Element nur enthält,

sondern irgendwas anderes. Ja.

Ein Unpacking-Error, das ist doch

schön, oder? Ja.

Ja, also dieses

Kapitel, wie gesagt, das ganze

Buch ist ja tatsächlich so, dass es sich nicht direkt

an, sag ich mal,

blutige Einsteiger

richtet, sondern es ist schon so, du hast die

Basics drauf, hier sind so ein paar Kniffe,

jetzt hier so geht es auch.

Und das ist doch schön,

dass man auch hier so Veteranen wie uns noch

damit überraschen kann.

Mit Sachen aus dem

puren Standard,

aus dem puren Python-Standard.

Hier übrigens,

Assigning to Slices. Was?

Ja.

Ne, gut, vielleicht mag das auch der Grund sein, warum ich das Buch echt gerne lese, weil man kann kaum irgendwie eine Seite oder zwei lesen, ohne dass man sich denkt, ach, echt interessant, das wusste ich jetzt gar nicht.

Und ja, das ist halt, das macht es irgendwie.

Ja, dann guckt er sich den Bytecode an und sagt, ja, ha, ha, ha.

auch was ich auch gut, das ist jetzt nochmal ganz am Anfang

von dem Kapitel, was ich auch super fand, ist, dass er

halt, das ist auch so etwas,

wo ich denke,

ja, das ist so, aber ich traue mich

manchmal nicht so richtig, das laut zu sagen, weil

irgendwie

die Prophezeiung

irgendwie vorsieht, dass

Vorschleifen lesbarer sind als

List-Comprehensions, aber ich denke gerade bei einfachen

Fällen sind List-Comprehensions tatsächlich

besser lesbar und hier hat er halt ein

schönes Beispiel, wo er halt quasi

den, die

die den Zahlenwert

von einem ASCII-Zeichen

aus einem String halt

rausnimmt. Und wenn du das halt

in der Vorschleife machst, also einmal sind halt doppelt

so viele Zeilen und dann ist es halt so, dass

irgendwie der

entscheidende Aufruf, der dir sagt, was passiert, der ist

halt irgendwie relativ weit irgendwie reingenestet

und der fällt dir stichend nicht sofort ins Auge.

Während die List Comprehension, da siehst du

halt sofort, was passiert. Ja, also ich bin auch

ein großer Fan von schönen Comprehensions.

Ja, klar, man kann damit natürlich böses

Wir hatten schon mal eine Unterhaltung, Jochen,

wo du die anderen Meinungen warst, aber

es kommt halt drauf an.

Es kommt drauf an, genau.

Hohoho, sind wir hier unter die Juristen

gegangen, es kommt drauf an.

Es ist aber doch wirklich so.

Wir wollen definitive Antworten.

Comprehensions sind schön peisonic,

in vielen Fällen sind sie einfach das Syntax

sogar schönere, als jetzt

eine Vorschleife zu machen, es sei denn,

man möchte bestimmte Dinge tun, wo dann

Vorloop explizit angebracht ist.

Das ist eins, was normalerweise ein bisschen komisch ist.

Nicht nur List Comprehensions, auch Dict Comprehensions

und Set Comprehensions.

Ja, aber auch da, manchmal ist es ein bisschen so,

manchmal, gerade dann, wenn man gucken will,

wie langsam irgendwas werden kann,

wenn man solche Sachen nestet hat oder sowas,

dann könnte es sein, dass das so

ein bisschen Sachen versteckt, weil er nicht explizit fünfmal

vorsteht und man fünfmal vorzählt oder

die nested levels und

dann sieht man, da könnte irgendwas kaputt sein

oder so.

Ja, wobei ich versuche ja so nested

Comprehensions versuche ich eigentlich zu vermeiden. Die mache ich dann

lieber untereinander, wenn es geht.

Ja, wobei er hat hier auch

ein schönes Beispiel für ein Ding, wo man

das nesten will und

wo es Sinn macht, das so

hinzuschreiben, weil bei der List Comprehension

hast du ja immer, also naja,

das ist Fluch und Segen zugleich.

es baut dir halt eine Liste zusammen.

Und der

Nachteil bei einer Liste ist, sie muss halt

irgendwie da sein, sie muss halt irgendwie

materialisiert sein. Und jetzt hat er hier

zum Beispiel diese, was ist das eigentlich?

Den Trick, Moment, ganz, ganz kurz, den Trick, den du gerade

überflogen hast, den fand ich auch sehr, sehr schön, wo er

innerhalb von der List Comprehension noch eine

Assignment Expression baut, die

dann tatsächlich genau dem letzten

Element spricht, wenn

du da irgendwas berechnest. Ja, das ist auch so ein

Quirk, also normalerweise

haben die ihren eigenen Scope, das heißt, wenn du halt da

irgendwie so einen lokalen Namen für irgendwas

hast. Da wird halt jedes Mal wieder überschrieben bei jedem.

Nee, da passiert normalerweise gar nichts.

Da gab es doch auch einen Bug, oder? In der Python-Version.

Ich weiß nicht, ob das ein Bug ist oder nicht,

aber normalerweise

ist alles so, wie man das erwarten würde.

Aber wenn man jetzt nicht

irgendwie gleich sagt oder

nicht einfach nur die Variable

verwendet, sondern man sagt halt

Doppelpunkt gleich irgendwas,

dann ist man aus dem Scope raus

und dann ist man in dem Scope von dem

von dem Ding drum rum und dann

passieren unerwartete Sachen, weil dann überschreibt das

halt eventuell Sachen, die halt im Scope außenrum sind

und ja.

Naja, aber vielleicht will man das ja machen.

Ja, vielleicht muss man.

Vielleicht.

Ja, aber das Beispiel da ist zum Beispiel super.

Dominik schreibt kein Python, sondern obfuscated Python.

Nein, aber das Letzte, was da steht,

das ist da zum Beispiel ein total tolles Beispiel,

weil du hast so irgendwie so eine Disconvention,

du wirst wissen, war das die letzte Addition davon,

war der letzte Aufwand der Funktion und

dann kannst du halt einfach dann Assignment Expression und dann hast

du den einfach direkt und kannst den Slot schreiben

oder so, oder was du auch immer damit machen willst.

Ja, okay. Assignment Expression

ist Walrus-Operator, oder?

Ja, genau. Ja, klar, das kannst

du natürlich schon so machen, aber du hast dann

hoffentlich keine Variable im Code

vorher verwendet, die irgendwie Last heißt, ansonsten

hast du den Fuß geschossen. Ja, das sollte man

da tatsächlich eh nicht tun, oder? Also

dass man davon ausgeht,

dass dann irgendeine Variable in der Lisk-Comprehension

die Sachen alle wieder vergessen werden,

ja, naja. Ja, normalerweise ist

das so. Ja, aber gut, aber da steht halt auch dann gleich drin.

Ja, aber da geht es aber auch

relativ lange drum in dem Kapitel, dass man da hier

diese Reihenfolge, dass das manchmal überraschend ist

und dass die manchmal...

Also ja, genau, ich mag auch dann so

Bedingungen, die können wir auch untereinander schreiben,

wie fest dies, das.

Aber ja, schönes

Peißen, würde ich sagen.

Genau, ich wollte nochmal kurz zurück zu dem,

also wo braucht man eventuell so

eine nested, also doppelt

Vorloop irgendwie Geschichte

und wo kann es Sinn machen, da

eben das halt so

hinzuschreiben und nicht in den For-Loop.

Wenn die Dimensionalität der Daten

das übersteigt, was man in einer

einzigen Spalte darstellen kann?

Also wenn man Relations hat?

Ja, oder er nimmt hier als Beispiel

ein kathesisches Produkt von irgendwie zwei

Iterables oder Sequences vielleicht

und wenn

du das halt in der Vorschleife machen willst, dann brauchst du

ja was, das du iterieren kannst und dann

musst du das halt in eine Liste packen und wenn

das halt fünf Zeilen, fünf Spalten

sind, dann ist das halt wenig, aber

wenn du jetzt tausend Zeilen und tausend

Spalten hast, dann ist das plötzlich

wahnsinnig viel und dann willst du das halt nicht

irgendwo hinspeichern.

Also gerade wenn du dich eigentlich nur diese

du hast jetzt tausend von der Sorte und tausend von der Sorte

das ist das, was dich eigentlich interessiert. Das musst du

auch irgendwo speichern, aber das kathesische Produkt

davon eigentlich nicht. Dann geht

das mit einer Vorschleife eigentlich gar nicht so gut, wenn

du nicht dieses Produkt

materialisiert irgendwie rumliegen haben willst.

Und was er dann

macht, ist eine Generator Expression, die

halt so eine doppelte Vorschleife drin hat

und das ist natürlich cool, weil

die erzeugt nämlich, das verbraucht gar kein

Hauptspeicher, sondern das generiert ja einfach

nur das synthetische Produkt.

Wenn du einen Generator halt hast. Genau, genau.

Und den kannst du ja den Generator dann als

Generator-Expression schreiben und dann

Was ist denn der Unterschied, Jochen? Wie schreibt man denn

eine Generator-Expression im Vergleich zu einer List-Compressor?

Das muss doch was ganz anderes sein, oder?

Runde-Klammern. Das Gleiche ist halt bloß eine Runde-Klammer, genau.

Ja. Das ist auch eine Falle,

in die man leicht tappen kann.

dass man runde Klammer

macht und das sieht erstmal so aus

und das funktioniert auch in vielen Fällen so ähnlich.

Nur wenn man es dann nochmal verwenden möchte,

ist es leider weg.

Genau, das ist

ein überraschender Anlass. Also ich meine, meistens ist wahrscheinlich

List Comprehension auch tatsächlich das, was man haben möchte.

Aber ja.

Ich würde gerne noch da ein paar Fragen

zu stellen und so ein bisschen zu wissen,

wann man welche Dinge denn benutzt. Und ich würde sagen,

Generator Expression im Vergleich

zu List Comprehension, wann ich eine Liste nehme,

wann nehme ich ein Array, wann nehme ich

Collections DQ, diese ganzen Dinge

so ein bisschen auseinanderzuhalten mit ihren Trade-Offs

wäre vielleicht nicht ganz uninteressant

in dieser Folge heute.

Oh, ja, okay, also. Ja, weiß nicht.

Das sind viele

tiefgehende Fragen, die du da gestellt hast.

Ja. Also die

eine Frage kann man leicht beantworten.

Du brauchst eine List Comprehension, wenn

du die Daten materialisiert brauchst, also

wenn du sie, wenn du drauf zugreifen willst

und mehrmals drauf zugreifen willst. Und kostet aber viel

Speicher. Autosequence und Indexzugriff

kostet halt Speicher. Du brauchst eine

Generator-Expression, wenn du sie nur einmal brauchst

und nur in Reihenfolge und

nicht, wenn es vielleicht zu viel ist,

um es am Hauptspeicher zu halten, nicht nochmal darauf zu griffen.

Und genau, wenn es zu viel ist.

Dann zum Beispiel mache ich sowas wie das kathetische Produkt,

dass ich die Kombination von allen Faktoren von zwei Vektoren

miteinander in Beziehung setzen kann.

Genau, also wenn es quasi

eine Prozedur ist, die du da machst.

Ja, das ist relativ

leicht zu verwenden. Aber jetzt die Frage, wo

benutzt du List versus Array versus

Memory View? Das kann man so allgemein.

Ah, da müssen wir

länger drüber sprechen. Und wenn du dann noch andere

Sachen reintust, wie Deck oder

Deck-Q oder eine Q oder wie auch immer du sie nennen möchtest.

Also ich meine, die Q, also der Vorteil

bei diesen Datenstrukturen ist halt... Wie spricht man denn Deck aus?

Deck-Q? Deck-Tück-Tick?

Deck. Ich habe schon mal Deck genannt,

aber ich weiß nicht genau, ob es richtig ist. Ich nenne es auch immer Deck,

aber keine Ahnung.

Die Q, warte mal hier,

hier gibt es Aussprache, warte mal.

Bitte lesen Sie diesen Begriff vor.

Der Deck,

sagt Leo.

Ich benutze immer Leo für sowas.

Dict.leo.org, wichtigstes Werkzeug.

Der sagt Deck

in schönem, feinem britischen Englisch.

Aha.

Ja, also sowas hat man halt vor allen Dingen

dann, wenn du möchtest, dass die

Sortierreihenfolge halt irgendwie

gleich bleibt. Nee, halt, warte mal.

Erstmal musst du erklären, was ein Deck ist.

Oh Gott.

Also, ich weiß

jetzt auch gar nicht, wie die...

Double-Ended-Queue.

Ja.

Ich weiß jetzt auch gar nicht, wie genau die Implementation

in Python da aussieht.

Spielt keine Rolle.

Ja, also

der Witz an dem Ding ist halt,

dass du sozusagen Sachen

rausnehmen kannst, reinnehmen kannst und trotzdem ist es halt

immer sortiert und du kannst halt...

Weil du einen Follower und einen

Processor hast.

Also eine Queue ist eine

Warteschlange.

Und eine Double-Ended Queue heißt,

du kannst auf der einen Seite was reinschieben

und auf der anderen Seite kannst du

was rausnehmen.

Und die bleiben in der Reihenfolge.

Also das heißt, ich habe beide Enden.

Das ist doch das, was eine Deck ist, oder?

Ja, genau.

Und das ist, da gibt es so ein Pattern,

das Producer-Consumer-Pattern,

wo du sagst, du hast halt eine

Prozedur, die erzeugt Datenpunkte

und du hast eine Prozedur, die

verbraucht Datenpunkte und dann

ist die Deck genau das, was

da dazwischen ist. Der eine tut sie eben

auf der einen Seite

in das Deck rein oder in die

Deck und der andere,

der sie verbraucht, der nimmt sie auf der anderen

Seite raus. Und

das kannst du prinzipiell mit einer Liste machen.

Du kannst eine Python-List als

Deck verwenden, indem du halt

.append machst, das ist das

Einfügen, und indem du halt .pop0

machst. Das Problem da drin ist,

dass .pop0

teuer ist, weil

das bedeutet, das erste Element der Liste wird

entfernt, das heißt, alle Elemente,

die in der Liste drin sind, müssen um 1 verschoben

werden und

das hört man jetzt schon,

dass wenn du das

erste Element rausnehmen willst, musst du sie alle einmal

anfassen. Und das

ist natürlich für eine Operation,

die sich so anhört wie

das erste wegnehmen,

einfach teuer.

Das hat diese

Spezialimplementierung,

der DEC, der Double Ended

Queue, wo das beides

nicht viel kostet. Das Einfügen am Ende

kostet nicht viel und das

vorne wegnehmen, kostet nicht viel.

Dafür gibt es halt andere Operationen, die dann viel kosten.

Dafür gibt es andere, dafür kannst du in der Mitte,

wenn du in der Mitte was einfügen willst,

entweder geht es gar nicht oder es ist extrem langsam

oder irgendwie solche Eigenschaften

hast du dann da halt verloren.

Die Sache an diesen

Datenstrukturen ist halt,

du kannst erstmal eine Liste verwenden

und wenn das zu langsam wird oder wenn das

Eigenschaften hat, wenn die Python-Liste

Eigenschaften hat, die nicht gut genug sind,

dann musst du dir was anderes suchen.

Und das ist eigentlich dann die Antwort auf deine Frage.

Ja, also wann merkt man denn überhaupt,

dass die Liste nicht gut genug ist?

Also weil es zu langsam wird, weil es oben gibt?

Wenn dein Programm zu langsam ist und nicht mehr in den Speicher passt.

Ja, okay, also genau.

Wenn dein Swap-Laufwerk anfängt zu arbeiten.

Ja, oder die Anwendung Crash-Wahl oben kickt.

Ja, genau.

Ja, oder wenn es halt zu langsam ist.

Ja, also es gibt Fälle.

Ich habe mit Leuten Sachen optimiert,

die halt eine Liste wie ein Set verwendet haben

und dann halt geguckt haben,

ist dieses Objekt in dieser Liste drin?

Kannst du machen?

Oh ja, kannst du.

Die heißt in und ist aber linear, ist O von N.

Das heißt, du musst gucken,

ist das erste Objekt mein gesuchtes Objekt

oder das zweite oder das dritte oder das vierte?

Das heißt, jede dieser Abfragen

muss einmal potenziell alle Elemente anfassen.

Und da gibt es eine Datenstruktur, das Set.

Da ist es halt O von 1.

Da kostet es immer gleich viel,

egal wie groß es ist, egal was du suchst,

egal ob es drin ist oder nicht,

kostet immer amortisiert gleich viel.

Und wenn du so einen

Algorithmus hast, der

viele von diesen Operationen macht,

dann hast du da eine Möglichkeit,

den deutlich schneller zu machen. Und zwar

richtig um Klassenschnellheit. Also mache ich einfach

ein Z aus der Liste und dann mache ich das N,

den In-Test? Ja.

In dem spezifischen Fall, genau.

Hat das ausgereicht, aus einer Liste

ein Z zu machen und das hat schon,

wenn du von O von N Quadrat auf O von

N runtergehst, das macht

Problemklassen bearbeitbar,

die vorher nicht bearbeitbar waren.

Vorher konnte man irgendwie 15

15

Elemente da drin haben

und hinterher konntest du 15.000

Elemente drin haben. Also das ist einfach

ein massiver Unterschied in der Performance.

Aber vorher zu sagen, was

du brauchst und an welchen Stellen

das das Richtige ist, fällt mir

sehr schwer.

Okay.

Das heißt, man muss immer tatsächlich

bei dem Problem gucken, was das

jetzt bringt. Genau.

Du musst bei dem Problem diese Abwägung machen zwischen

Komfort und Geschwindigkeit.

Und im ersten Schritt, das ist

ja auch das, was wir vorhin angesprochen haben, wir machen ja

in erster Linie erstmal so einen

Rapid-Prototype, einfach um zu sehen,

was überhaupt. Ein Komfort-Check, ja.

Und da wähle ich immer,

wählst du immer die komfortabelste Lösung, die erste

Lösung, weil erst musst du wissen, ob

das korrekt hinkriegst und dann kannst du gucken,

ob das schnell hinkriegst. Ich kann

sehr, sehr, sehr schnelle Programme schreiben,

die nicht die richtige Antwort liefern. Das ist überhaupt

gar kein Problem. Ja, wobei dann der,

wenn ich jetzt mal meinen

inneren Casey channelen darf,

der würde natürlich

sagen, ja gut, also wenn du das jetzt so machst

und wenn du halt implizit die Annahme

triffst, dass du hinterher deine

Hotspots, wo die Performance halt kritisch ist,

halt optimieren kannst, dann kann es halt

sein, dass du in einer Situation landest, wo du halt mit dem

Profiler deinen Code anguckst

und der sagt dir halt, ja, also die ganze

Performance geht drauf bei Funktionsaufrufen

und bei Memory-Allotierungen.

Und du denkst dann, ja, wie soll ich den jetzt noch optimieren?

Dann wird er sagen, ha, siehste, das geht doch nicht.

Aber, das ist richtig, aber Schritt 0 im Knuth-Optimization-Process

ist die Wahl des richtigen Algorithmus.

Das heißt, gucken, ob du den Algorithmus gewählt hast,

der die richtigen Eigenschaften hat.

Und das ist natürlich was,

auch das ist schwierig jetzt so konkret zu beantworten.

das ist halt was, was mit Erfahrung kommt, dass du weißt,

welche Algorithmen gibt es und welche Sortenalgorithmen

gibt es. Und das ist gerade ein Knuth-Optimation-Prozess

gesagt. Ja, das

ist so ein,

die witzige Umdrehung dieses

Knuth-Zitats.

Sag ich gleich.

Das ist das,

genau, das ist das, was mit der Erfahrung kommt, ja, dass du

weißt, welche Algorithmen gibt es, welche

Alternativen gibt es, welche

Datenstrukturen gibt es, was ist wo angebracht.

Wenn du jetzt irgendwie was

anpassen musst oder wenn du jetzt irgendwas hast,

das nicht auf ein Standardproblem passt,

dass du es dir trotzdem aus den Bauteilen zusammen

suchen kannst. Und der erste

Schritt in diesem Prozess ist, den richtigen

Algorithmus auszuwählen. Und das alles andere

ist untergeordnet.

Wenn du den falschen Algorithmus auswählst,

hast du schon verloren.

Genau. Das bezieht sich auf

dieses Zitat von Knuth,

Premature Optimization is the root of all evil.

Wann weiß ich denn, ob der Algorithmus

richtig ist?

Wobei, weißt du nicht.

Wobei man auch dazu sagen muss,

Knuth sagt ja im nächsten Satz,

10% Geschwindigkeitszuwachs lohnt sich schon zu optimieren.

Und da sind wir natürlich auch hier auf der Python-Ebene schon verloren,

weil wir akzeptieren, dass unsere Programme langsamer sind

als das 10% Optimale.

Auch da gibt es natürlich Ebenen.

Knuth kommt ja aus einer ganz anderen Welt,

wo die Prozessoren noch in Kilohertz gemessen wurden

und nicht in Gigahertz.

Und auch die, sag ich mal, die algorithmischen Probleme anders waren.

Du kannst bei einem Sortieralgorithmus beweisen, was das Maximum ist und du kannst beweisen, dass dein Algorithmus das Maximum für eine gewisse Datenklasse erreicht.

Würde ich sagen, ist bei den meisten Sachen, die wir so bearbeiten heutzutage, hier CV-Erstellung für den Jochen, kannst du nicht beweisen, dass du den optimalen Algorithmus ausgewählt hast.

Du weißt, dass du einen Algorithmus ausgewählt hast, der passend ist für das Problem, wenn es deinen Anforderungen entspricht, wenn du dein Problem lösen kannst in einer Zeit, die akzeptabel ist. Und das ist jetzt natürlich wieder so eine Stelle, wo der interne Casey sagt, ja, aber Moment mal, ich will einfach, dass das hier viel schneller wird und ich habe ausgerechnet, der Prozessor kann so und so viele Operationen pro Sekunde machen, also reicht es aus, um das 30 Mal pro Sekunde zu machen, also kannst du es in Realtime machen und dann mach es auch bitte in Realtime.

Und mein interner Nicht-Casey, der sagt dann halt, ja, aber einmal pro Sekunde reicht ja auch oder einmal pro fünf Sekunden reicht auch. So schnell muss man das gar nicht aktualisieren. Und das ist eine Frage der Anforderungen, welche Anforderungen du hast und welche Vorstellungen du hast und wie schnell du es haben willst.

Und da pauschal zu sagen, was ist der richtige Rhythmus oder wie wählst du den aus? Keine Ahnung, ich weiß es nicht. Mit Erfahrung, mit Gefühl, mit, ich weiß nicht, mit dem Benutzer sprechen.

Oh, User Experience, jetzt weiß ich aber welchen.

Ja gut, okay, also in Projekten natürlich nicht mit dem Benutzer, sondern mit dem, der es bezahlt.

Ja, ja, okay, ist schlimm genug.

Also, naja, gut.

Oft ist es auch so, dass man gerne mal

mit dem Nutzer sprechen würde, aber tatsächlich

dann immer nur mit den Bezahlern,

mit den Hippos.

Ja.

Oft gibt es ja auch

gar nicht den Benutzer. Oft gibt es ja nur

eine Klasse von Benutzern.

Oft findest du ja gar nicht den Benutzer, sondern

ja.

Ja, oder vielleicht soll man gar nicht mit denen reden.

Oder die Benutzer sind doof und verstehen es nicht.

Das ist ja auch so manchmal.

Ja, was aber auch, also ich muss das jetzt gleich wieder zurücknehmen. Ich meine, wir arbeiten ja oft in so einem Corporate-Umfeld und da sind die Benutzer halt, das ist auch sowas, was Softwareentwickler oft sagen, das wäre alles so einfach, wenn die Benutzer nicht wären, wenn die nicht das falsch benutzen würden, wenn die das nicht so benutzen würden, wie sie es benutzen wollen.

Das ist aber, das ist lustig, sowas im Bekanntenkreis zu sagen, aber wenn wir hier im Podcast sind, müssen wir das klarstellen, das ist nicht ein Fehler des Benutzers, wenn er die Software falsch benutzt, sondern es ist ein Fehler der Software, wenn die Software falsch benutzbar ist und wenn sie anders eingesetzt wird, als sie gedacht war.

Deswegen fühle ich mich übrigens im Eurorex wohl, weil wenn man da das Kabel in die falsche Öse reinsteckt, dann kommen lustige Sachen raus und es gibt immer noch Musik.

Also für dich ist das ein Feature, für dich soll das so sein.

Ja, also ich würde mich aber auch nicht darüber

beschweren, dass die Nutzer doof sind, sondern ich würde tatsächlich sagen,

hey, super wichtig und toll, dass

Videosoftware benutzt und hey, wenn dieser Bug für dich

ein Feature ist, perfekt, I won't fix it.

Ja, oft

ist es ja andersrum. Oft ist es ja so, dass du Feature

kompliziert einbaust und dann sagen die Leute,

ja, das geht aber nicht

so, wie ich mir das vorstelle. Und dann

liegt es halt nahe zu sagen, ach, das liegt an dir,

du doofer Benutzer. Ja, man sollte halt

vorher mal die Leute fragen, die es halt auch benutzen wollen,

ob das halt wirklich das ist, was sie brauchen.

Ja, und wenn

eine Fehlbenutzung auftritt, also wenn tatsächlich

Fehler auftreten, dadurch, dass

die Benutzer irgendwas damit machen,

dann muss die Software das halt entweder abkönnen

oder korrigieren können oder

die Software muss die Benutzer so steuern, dass das

nicht passiert. Die Benutzer können da nichts

dafür, dass sie Anforderungen haben und dass sie Wünsche

haben und dass sie...

Das ist so eine generelle

Einstellung, die man oft halt sieht in der Software

Welt, der Computer hat Recht und der Benutzer hat

nicht Recht, aber es ist tatsächlich

dealen wir ja nicht den Computern,

sondern es soll ja eigentlich schon andersrum sein.

Mal gucken, wie lange noch.

Deshalb sage ich, es soll andersrum sein.

Aber auch ich freue mich

auf unsere Robotic Overlords.

I for one.

Ich möchte an der Stelle den Robotic Overlords

sagen, ich bin ein guter Diener.

Genau.

Schreibt doch mal schon Danke bei, wenn GPD uns geschrieben hat.

Ja, natürlich.

Bedankt ihr euch nicht bei ChatGPD.

Das ist reiner

Selbsterhaltungstrieb, wenn die

Zukunft kommt. Dann werden die Protokolle gelesen

und dann...

Ausgewertet. Wer war denn nützlich?

Wer war freundlich?

Wie viel Freundlichkeit

haben die verdient, diese Affen?

Tja.

Ja, okay.

Aber jetzt haben wir hier schon tatsächlich,

sind wir schon relativ gut am Ende

des Kapitels angekommen.

hier, Memory Views.

NumPy wird hier noch erwähnt. NumPy

finde ich ganz interessant, dass das hier

in dem Kapitel über Sequences drin ist,

weil NumPy selber ist ja keine Sequence.

An Array?

NumPy ist ja

eine Riesenbibliothek mit ganz vielen

numerischen...

Ach so, du meinst, ja, okay. Gut.

Aber die Datentypen, die da drin sind,

die sind ja schon

auf eine gewisse Art und Weise auch

Sequences. Also die halten sich auch an das Sequence-Protokoll

und da kannst du ganz viele, kannst du Slicing machen

drauf und so weiter und so fort.

Die sind halt optimiert dann direkt auf Speicher und so.

Was macht ManPy eigentlich

so genau so besonders?

Man kann mit ManPy auch was kaputt

machen. Also wirklich

im Vergleich zu normalen Listen.

Wenn du so eine Liste zu groß machst, dann passiert nicht so viel. Aber wenn du

in ManPy eine Liste zu groß machst,

dann kannst du ja unten damit ansteigen.

Du bist halt näher am

Hauptspeicher dran. Dafür sind

sie auch deutlich schneller. Also wenn du

viele Einträge hast, musst du dich allerdings wieder

auf den Datentyp festlegen. Da kannst du nicht gemischte Daten

Typen haben. Dafür kannst du

mehrdimensionale haben.

Also es ist wieder so eine Abwägung.

Aber auch das ist

natürlich eine Möglichkeit,

dass du sagst, hier, wir haben irgendwelche Daten, die wir

verarbeiten müssen, dann nehmen wir doch

NumPy-Datentypen.

Und ganz viele Bibliotheken integrieren das ja auch.

Also zum Beispiel bei Pillow kannst du einfach sagen,

hier, er ist irgendwas. Und dann kriegst du

eine NumPy-Array raus, wenn du

irgendwelche Bildfilter selber schreiben willst

oder wenn du irgendwelche...

Ich habe mal Dithering gemacht.

ein Privatprojekt. Und das habe ich halt auf den

NumPyArray. Was ist Dithering?

Das ist das Schönste, was

du da machen kannst. Kanten finden.

Dithering

ist, wenn du von

einem Bildformat mit vielen

Farben dich

bewegst auf ein Bildformat mit wenigen

Farben, dann hast du üblicherweise Fehler

in deinem Bild. Ja, da musst du immer

Zusammenfassung machen. Da musst du mit so einem Raster

drüberlaufen und das dann irgendwie mitteln oder so.

Genau, und das heißt Dithering.

Das heißt, du hast den Fehler nicht

an dieser einen Stelle, sondern du verteilst

den und dann wirkt das Bild

besser auf

Menschen. Das sieht

besser aus und

macht halt, verteilt

so ein bisschen die, also du hast dann bessere,

das Bild sieht besser aus mit weniger Farben.

Und ich habe das,

ich mag ja E-Paper-Screens sehr gerne und ich

habe mir eben so eine Anwendung gemacht, wo ich Bilder auf E-Paper-Screens

machen kann und da musste Dithering machen, weil die haben

üblicherweise vier Graustufen

oder acht Graustufen oder

16 Graustufen. Und da kommst du nicht drum rum, da musst du

Disney-Wing machen. Sonst hast du so ganz

blockige Bilder mit harten Kanten

drin, die bescheuert ausschauen.

Ja, aber