Fitten von Zeitkurven

[zegru]

Ich würde gerne Messwerte fitten, die jeweils an einem bestimmten Tag erfasst wurden. Leider gibt es hier eine Beschwerde ("TypeError: float() argument must be a string or a real number, not 'datetime.date'").
Wie macht man es richtig?

Code: Alles auswählen

from datetime import date

import scipy

def linear(x, a, b):
    return a * x + b

measurements = [(date(2024, 12, 1), 10.0),
                (date(2024, 12, 2), 11.2),
                (date(2024, 12, 3), 14.3)]

values_x = [measurement[0] for measurement in measurements]
values_y = [measurement[1] for measurement in measurements]

popt, pcov = scipy.optimize.curve_fit(linear, values_x, values_y)
print(popt)
print(pcov)

[noisefloor]

Hallo,

die Antwort steht ja quasi schon in der Fehlermeldung... du übergibst für das Datum / den X-Wert ein `date` Objekt, damit kann scipy.optimize.curve_fit aber nichts anfangen, weil ein String oder eine Zahl erwartet wird.

`date` Objekte kennen die strftime-Methode, damit kannst du einen String bauen:

Code: Alles auswählen

>>> from datetime import date
>>> now.strftime('%Y-%m-%d')
'2024-12-19'
>>>

Alternative könntest du, wenn das Datum eine Zahl sein soll, auch direkt das Datum als Zahl schreiben: 20241219 für den heutigen Tag. Plan B für die Zahl wäre, einen Unix Timestamp zu nehmen. Der beinhaltet aber immer eine Uhrzeit, d.h. die müsstest mit `datetime` Objekten arbeiten:

Code: Alles auswählen

>>> from datetime import datetime
>>> now = datetime.now()
>>> now.timestamp()
1734623204.623406
>>>

Gruß, noisefloor

[Sirius3]

@noisefloor: numpy ist so freundlich, Strings in eine Zahl umzuwandeln, aber das bedeutet nicht, dass man auch einen Datumsstring benutzen kann.
Man könnte also mit toordinal() das Datum in die Anzahl der Tage seit 1.1.1 umwandeln.

[narpfel]

20241219 für den heutigen Tag.

Das klingt nicht richtig, weil dann der Abstand zwischen 20241231 und 20250101 größer ist als der Abstand von 20250101 zu 20250102.

[snafu]

Man könnte also mit toordinal() das Datum in die Anzahl der Tage seit 1.1.1 umwandeln.

Nur aus Interesse: Wieso ist der dabei schon so weit im nächsten Jahr?

Code: Alles auswählen

In [25]: dt.now().toordinal() / 365
Out[25]: 2025.3150684931506

[sparrow]

@snafu: Da sind wohl einige Jahre dabei, die mehr als 365 Tage haben. Ich glaube, je 400 Jahre gibt es 97 Schaltjahre.
Damit wäre die Länge eines Jahrs im Durchschnitt 365,2425.

[noisefloor]

Hallo,

Das klingt nicht richtig, weil dann der Abstand zwischen 20241231 und 20250101 größer ist als der Abstand von 20250101 zu 20250102.

Mathematisch richtig, wobei das ja "nur" die numerisch Darstellung des Strings ist. Wenn es äquidistant sein muss, dann ist wohl in der Tat `toordinal` oder ein Unix Timestamp die bessere wohl.

Gruß, noisefloor

[DeaD_EyE]

Nur aus Interesse: Wieso ist der dabei schon so weit im nächsten Jahr?

Der Kalender, den sich die Herrscher ausgedacht haben, ist vollgestopft mit Fehler, die dann nachträglich korrigiert worden sind. Deswegen haben wir dieses Durcheinander. Deswegen haben wir die Schaltjahre. Schaltsekunden gibt es auch, aber die werden, soweit ich weiß, nicht berücksichtigt, wenn man mit einem Kalender arbeitet. Da es noch nicht kompliziert genug ist, haben wir Menschen Zeitzonen erfunden, die dann durch politische Herrscher geändert werden: https://www.timeanddate.com/news/time/archive.html


Die Funktion toordinal() ist hilfreich (kannte ich noch nicht), wenn man nur ein Datum hat. Bei Datum+Uhrzeit sollte man den Unix-Timestamps nutzen.
Bei historischen Daten vor 1970 muss man sich selbst etwas basteln oder eine Bibliothek nutzen, die das für einen macht.

Code: Alles auswählen

import datetime

def seconds_since_year_one(dt):
    return (dt - datetime.datetime(1, 1, 1)).total_seconds()

[Sirius3]

@DeaD_EyE: wenn Du diesen großen Herrscher meinst, der die Erde um sich selbst und um die Sonne kreisen läßt. Ansonsten sind die Untertanen ganz froh um die Schaltjahre, weil sie sonst irgendwann an Christi-Himmelfahrt ihren Bollerwagen durch den Schnee ziehen müßten und wenn das Bier in der Flasche gefriert, ...

[__blackjack__]

Das kann nicht ganz hinkommen, denn als welcher Herrscher auch immer das Schaltjahr eingeführt hat, drehte sich die Sonne noch um die Erde, oder irgendwelche Göttergehilfen haben die immer über den Himmel gezogen oder so.

[zegru]

Das mit dem Umrechnen in eine timestamp habe ich mir zwar auch schon gedacht. Aber der Nachteil ist halt, die gefittete Funktion mit matplotlib (was ja sehr wohl date kennt, also die Messdaten schon mit Datum darstellt), zum Vergleich drüber zu plotten. Und alles auf timestamps umzustellen ist für Menschen nicht mehr lesbar.

[__blackjack__]

@zegru: Das sind ja zwei verschiedene Dinge — die Form in der gerechnet wird, muss ja nicht die Form sein, in der das Ergebnis dargestellt wird. Man kann Zeitstempel für den Plot dann ja wieder als Datum anzeigen lassen.

[zegru]

Beim Fitting kommen ja diverse Parameter für eine Funktion raus (hier eine lineare Funktion). Wenn man hier Mathematik betreiben möchte (Nullstellen und sowas), wie kommt man dann zum menschenlesbaren Datum statt der Timestamp?

[__blackjack__]

@zegru: Ich weiss jetzt nicht ob ich die Frage richtig verstehe, aber wenn Du Werte als Timestamp hast, dafür hat `datetime.datetime` eine `fromtimestamp()`-Methode um daraus wieder ein `datetime`-Objekt zu machen.

[DeaD_EyE]

@DeaD_EyE: wenn Du diesen großen Herrscher meinst, der die Erde um sich selbst und um die Sonne kreisen läßt. Ansonsten sind die Untertanen ganz froh um die Schaltjahre, weil sie sonst irgendwann an Christi-Himmelfahrt ihren Bollerwagen durch den Schnee ziehen müßten und wenn das Bier in der Flasche gefriert, ...

Es geht doch nicht allein um die Schaltjahre. Die Berechnungen mit einem Kalender sind komplexer als notwendig. Alle Körper mit einer Masse unterliegen der Raumkrümmung, aber die Struktur des Kalenders ist durch Menschen definiert worden.

Wenn es so einfach wäre, mit unserem Kalender zu arbeiten, dürfte es kaum Bugs geben, die etwas mit Datumsangaben, Zeiträumen usw. zu tun haben. Ich kann mich noch an den Hoster erinnern, der seine Kunden gebeten hat, die Server neu zu starten, da ein Bug im Linux-Kernel, ausgelöst durch eine Schaltsekunde, 100% CPU-Last erzeugt hat. Resultat: 1 MW Mehrverbrauch

Banken haben öfters mal bei Zeitumstellungen das Problem, dass Buchungen doppelt sind. Natürlich hat man das behoben, aber nervig ist es trotzdem für alle, die involviert sind.

[__blackjack__]

@DeaD_EyE: Genau so wenig wie das arbeiten mit Zeitpunkten einfach ist, ist die ”Schuld” nicht so einfach zu klären. Das mit den Kalendern ist ja sehr lange und historisch gewachsen und auch ohne das komplette Wissen das wir heute haben. Und wenn man das jetzt “vereinfachen“ würde, gibt es so an die 100% der ganzen normalen Leute die ein umlernen auf was komplett anderes als den Kalender den sie gewohnt sind, alles andere als ”einfach” finden werden. Das würde mindestens eine Generation dauern. Schau Dir an wie viele Leute auch heute noch Geldbeträge in D-Mark umrechnen, weil das immer noch ihr Bezugspunkt ist. Zumal eine Umstellung auch nicht ohne Reibungsverluste funktionieren wird, da wären also auch Unmengen an Fehlern bei der Umstellung zu erwarten.

[sparrow]

@DeaD_Eye: Ja genau! Irgendwas mit Raumkrümmung ist bestimmt viel simpler als eine der Erdumdrehung und der Sonnenumdrehung angeglichenen Zeitmessung.

Die Schaltsekunde ist da um UTC an UT1 anzugleichen. Und sie kann in beide Richtungen auftreten. Die Erdrotation ist nun mal nicht konstant gleich.

Wenn Banken damit ein Problem mit der Zeitumstellung haben, dann ist das kein Problem mit dem Kalender - dann hat da jemand einen Fehler gemacht. Zeitzonen sind in der Softwarenticklung nur interessant um sie in UTC umzuwandeln

Über die Schaltsekunde gibt es übrigens eine ganz gute Folge vom Engineering Kiosk Podcast. Falls jemand von euch sowas mag.

[DeaD_EyE]

@DeaD_Eye: Ja genau! Irgendwas mit Raumkrümmung ist bestimmt viel simpler als eine der Erdumdrehung und der Sonnenumdrehung angeglichenen Zeitmessung.

Nein, nicht simpler, sondern die Erklärung dafür, wieso unser Planet die Sonne unterschiedlich schnell umkreist (umhereiert). Die anderen Planeten haben auch Einfluss (Jupiter, Saturn). Da gibt es übrigens eine coole Serie: 3 Body Problem

Allein aus Pragmatismus sollte man für zeitbezogene Ereignisse immer UTC0 verwenden, aber lokalisiert darstellen.
Ich denke, dass Banken das mittlerweile machen (hoffentlich).

Wenn man aber eine lokalisierte Zeit mit Datum angeben will, kommt es beim Wechsel von Sommerzeit auf Winterzeit (Normalzeit) zu doppeldeutigen Angaben. Deswegen wurde bei der datetime-Klasse das Schlüsselwort fold eingeführt. fold adressiert dann die Uhrzeit nach dem Wechsel von Sommerzeit auf Winterzeit. Zum Glück braucht man das nicht, wenn Ereignisse in UTC0 geloggt werden. Aber wir Menschen verwenden gerne die Lokalzeit und die Eingabe von Daten in Lokalzeit.

[sparrow]

@Dead_Eye Das 3-Körper-Problem spielt in der Trisolaris-Trilogie eher eine Nenenrolle. Die gibt (oder gab) es mal komplett in der ARD Mediathek als Hörbuch. Das kann ich empfehlen.

Was ist denn nun dein großer Wurf, wie man das Kalendersystem besser macht? Wo sind die Fehler, die du nicht gemacht hättest?

[DeaD_EyE]

Was ist denn nun dein großer Wurf, wie man das Kalendersystem besser macht? Wo sind die Fehler, die du nicht gemacht hättest?

Es gibt keinen Grund, überheblich zu sein.

Nicht ich, sondern Leute, die sich intensiv damit beschäftigt haben. Unter anderem vereinfacht es die Algorithmen zur Berechnung von Kalendern, wenn man den Dezember mit Februar tauscht. Ob dazu auch die Korrektur der Anzahl der Tage für jeden Monat zählt, weiß ich nicht mehr.

Für normale Jahre: [30,31,30,31,30,31,30,31,30,31,30,30]
Schaltjahre: [30,31,30,31,30,31,30,31,30,31,30,31]

Aber wie gesagt, ob das zur Verbesserung auch beiträgt, weiß ich nicht. Das kann man feststellen, in dem man für diese Sequenzen die Berechnungen durchführt und wenn diese einfacher sind, als die vorherigen, hat man den Beweis. Die Abweichung zur Erdrotation würde sich nicht ändern.