Daten nach Datum aufsummieren

[__blackjack__]

Hm, ich bin auch nicht sooo nah an den beiden Zahlen. Allerdings liegen die beiden nicht mehr auf der gleichen Seite vom aktuellen Punkt auf dem Zeitstrahl.

@viechdokter: `read_csv()` hat gefühlt eine Million Optionen. Eine davon ist das Trennzeichen. Das ist als Voreinstellung das Komma, aber man kann da auch ein Semikolon angeben. Wenn man mit ”deutschen” Zahlen arbeitet, ist es auch manchmal nützlich, dass man den Dezimaltrenner als Komma angeben kann, denn das ist in der Voreinstellung der Punkt. Und einen Tausendertrenner kann man auch angeben. Dann kommt das auch mit Zeilen klar, in denen so etwas wie "1.535.286,42" steht und in eine Gleitkommazahl umgewandelt werden möchte. Und man kann angeben in welchen Spalten Datumsangaben stehen und tatsächlich auch, dass die Bibliothek versuchen soll zu raten wie das Format davon aussieht. Habe ich in meinem Code ja gemacht.

Man kann beim Einlesen auch schon angeben welche Spalten man haben möchte, falls man da Speicher sparen möchte/muss.

[viechdokter]

@__Blackjack__ So, ich habe mich jetzt seit ein paar Tagen tief in Pandas reingewurschtelt und dann versucht, deinen Code nachzuvollziehen. Ich glaube auch zu verstehen, was du da wie machst. Ich hätte da jedoch noch eine Frage zu den Klammern:

In Fällen wie

Code: Alles auswählen

print(covid_df[["Geschlecht", "AnzahlFall"]].groupby("Geschlecht").sum())

wenn es um mehrere Spalten geht, sehe ich immer die doppelte eckige Klammer [[...]].

Bei der Nutzung von .groupby und parse_dates scheint jedoch jeweils EINE eckige Klammer zu verschwinden:

Code: Alles auswählen

data = pd.read_csv(
        ...,
        parse_dates=["Meldedatum", "Refdatum"],
        ...
    )
    

Nur EINE Klammer um zwei Spalten.

Code: Alles auswählen

    data = (
        data[data["Landkreis"] == "SK Braunschweig"][
            ["Meldedatum", "AnzahlFall"]
        ]...

ZWEI Klammern um Datum und Fallzahl.

Code: Alles auswählen

        
        .groupby("Meldedatum")
        .sum()

EINE eckige Klammer weniger, also NULL Klammern. Gibt es da eine Regel?

[__blackjack__]

@viechdokter: Es gibt keine doppelten eckigen Klammern. Die sind alle immer einzeln zu betrachten. Also ``expression[[foo, bar]]`` hat keine doppelten eckigen Klammern sondern das ist ``expression[…]`` und als Wert/Argument wird da ``[foo, bar]`` angegeben. Und die ”Regel” ist, das Pandas schaut was als Index verwendet wird und je nach Typ was anderes macht. Ein Skalar wird als eine Spalte behandelt, eine Liste als mehrere Spalten, eine Sequenz mit Wahrheitswerten, ein Tupel als Schlüssel in einen Multi-Index, und so weiter. Also so ganz grob. Das ist insgesamt ein bisschen sehr magisch und geht eingentlich gegen gute OOP-Praxis.

Beim Aufruf von `read_csv()` ginge ``parse_dates="Meldedatum", "Refdatum"`` nicht weil der Lexer das als zwei Argumente sehen würde, ``parse_dates="Meldedatum"`` gefolgt von ``"Refdatum"`` und das wäre dann auch noch ein Fehler weil nach Schlüsselwortargumenten keine Positionsargumente mehr folgen dürfen.

Bei dem `groupby()` ist das wieder Pandas, das so nett/magisch ist in der Methode zu prüfen was als `by`-Argument übergeben wurde. Ein einzelner Name, eine Liste, eine Abbildung oder ein `Series`-Objekt oder eine Funktion/etwas aufrufbares.

Wenn man selbst etwas implementieren müsste was eine Liste von Zeichenketten verarbeitet, aber dem Aufrufer auch erlauben würde eine einzelne Zeichenkette zu übergeben, würde das so aussehen:

Code: Alles auswählen

def frobnicate(texts):
    if isinstance(texts, str):
        texts = [texts]
    #
    # Now do something with the texts.
    #
    ...

frobnicate("one")
#
# <=>
#
frobnicate(["one"])

Ich würde da eher von abraten so etwas zu machen, nur um dem Aufrufer ein Klammerpaar für die Liste zu ersparen. Letzteres dürfte am Ende der Grund sein warum Pandas das macht: die gehen davon aus, dass das auch viele interaktiv benutzen und nicht nur in Programmen, und die Nutzer von anderen Softwarepaketen in anderen Programmiersprachen sind gewohnt, dass einiges an Magie existiert um Tipparbeit zu sparen. Der Code hinter dem Index/Schlüsselzugriff bei `DataFrame` besteht im Grund aus cirka 50 Zeilen die nacheinander verschiedene Möglichkeiten prüfen was das Argument für ein Typ ist und wie der Wert beschaffen ist, um zu entscheiden welche interne Methode da tatsächlich ausgeführt wird.

[viechdokter]

Einmal Index [...] und einmal eine Liste [...], das macht Sinn. Danke. Schaue ich mir auch nochmal genauer an.

Beim weiteren Stöbern im Titanic-Beispiel von Pandas bin ich auch noch auf eine zweite Schreibweise gestoßen. Man kann wohl die Spaltenüberschriften direkt mit Punkt an den Dataframe heften, ohne die ständigen eckigen Klammern und Anführungszeichen. Für mich sieht das einfacher aus.

Statt:

Code: Alles auswählen

überlebende_Jungen = titanic([titanic["Age"] <= 16] & [titanic["Survived"] != 0] & [titanic["Sex"] == "male"])

kann man wohl auch schreiben:

Code: Alles auswählen

überlebende_Jungen = titanic.loc[(titanic.Age <= 16) & (titanic.Survived != 0) & (titanic.Sex == "male")]

Ich habe mir ein kleines (makabres) Statistikprogramm damit zusammengefummelt, das die Überlebensraten der Kinder unter 16 nach Geschlecht ausrechnet. Ich weiß, ich kann den Code noch straffen, indem ich auf Zwischenvariablen verzichte, aber die Lernkurve in den letzten Tagen war schon steil genug. Ich bin mit dem Ergebnis zufrieden:

Code: Alles auswählen

import pandas as pd
titanic = pd.read_csv("Titanic.csv")
print("Kinder auf der Titanic:")
kinder = titanic.loc[(titanic.Age <= 16), "Name"]
print(kinder.count())
print("Davon Mädchen:")
Mädchen = titanic.loc[(titanic.Age <= 16) & (titanic.Sex == "female"), "Name"]
print(Mädchen.count())
print("und Jungen:")
Jungen = titanic.loc[(titanic.Age <= 16) & (titanic.Sex == "male"), "Name"]
print(Jungen.count())
print("Davon haben überlebt:")
überlebende_kinder = titanic.loc[(titanic.Age <= 16) & (titanic.Survived != 0), "Name"]
# print(überlebende_kinder)
print("Überlebende Kinder: ", überlebende_kinder.count())
print()
überlebende_Mädchen = titanic.loc[(titanic.Age <= 16) & (titanic.Survived != 0) & (titanic.Sex == "female"), "Name"]
überlebende_Jungen = titanic.loc[(titanic.Age <= 16) & (titanic.Survived != 0) & (titanic.Sex == "male"), "Name"]
print("Überlebende Mädchen:")
# print (überlebende_Mädchen)
print (überlebende_Mädchen.count())
print ("Überlebende Jungen:")
# print (überlebende_Jungen)
print (überlebende_Jungen.count())
print ("Überlebensraten für...")
print ("Mädchen ", int((1/ (Mädchen.count() / 100) * überlebende_Mädchen.count())), "%.")
print ("Jungen ", int((1/ (Jungen.count() / 100) * überlebende_Jungen.count())), "%.")

[Buchfink]

Neulich hatte ich auch mal einen Artikel zur Hand, dass es zwei biolgische "Altersstufen" gibt, bei denen die Verschleißerscheinungen sprunghaft steigen. 35 Jahre war einer dieser Punkte und dann später nochmal 70 Jahre (Den Artikel finde ich leider nicht mehr)

NZI - der Vollständigkeit und Korrektheit halber . Heute morgen habe ich den Artikel (zufällig) nochmal gefunden:
https://www.nature.com/articles/s41591-019-0673-2

Es sind sogar drei Altersstufen: 34, 60 und 78.

Tja nun

[viechdokter]

Aging is a predominant risk factor... Mein Opa hat immer gesagt: "Werd bloß nicht alt, mein Junge!"

[Buchfink]

ja, man hat es immer schon irgendwie geahnt, dass das auf Dauer ja nicht gut gehen kann