Wahrscheinlichkeit berücksichtigen...?

[mutetella]

Hallo,

ich habe ja das dumpfe Gefühl, mal wieder von meiner irrsinnigen Performanceangst getrieben zu sein. Aber es hilft ja nichts, ich muss es fragen... :
Bin gerade dabei, eine Abfrage zu möglichen Wiederholungen von Terminen zu schreiben. Ihr kennt das ja aus verschiedenen Kalenderprogrammen:
"Diesen Termin jedes 2. Jahr am 15. und 16. März wiederholen" etc. p. p.
Um zu ermitteln, ob sich an einem beliebigen Datum eben dieser Termin wiederholt, muss ich folgendes prüfen:

• Stimmt der Jahres-Interval?
  Stimmt der Monat?
  Stimmt der Tag?

3 Fragen, deren Ausgang jedesmal entscheidet, ob die nächste Frage überhaupt gestellt werden muss. Und da hab' ich wieder den Teufel im Detail gefunden :
Welche Reihenfolge der 3 Abfragen macht am ehesten Sinn? Anderst gefragt: Wo besteht die größte Möglichkeit, die Abfragefolge durch ein 'False' zu beenden und damit Zeit zu sparen?

Gruß
mutetella

[Hyperion]

"Diesen Termin jedes 2. Jahr am 15. und 16. März wiederholen" etc. p. p.
Um zu ermitteln, ob sich an einem beliebigen Datum eben dieser Termin wiederholt, muss ich folgendes prüfen:

Ich kapiere den großen Zusammenhang hier noch nicht, insbesondere wieso man da etwas prüfen muss / will. Zudem stellt sich die Frage, wie das ganze technisch aufgehangen wurde und ob man dann überhaupt noch die Abfrage zerlegen kann?

[lunar]

@mutetella: Du hast Probleme ... wenn Du weiterhin vor allem über solchen Kleinkram nachdenkst, dann wird Dein Programm nie fertig, sondern nur „gefühlt schnell“.

Wie wäre es, wenn Du das Pferd zur Abwechselung mal von vorne aufzäumst, indem Du erst eine vernünftige, möglichst einfache und vor allem korrekte Lösung implementierst, und erst bei konkreten Problemen mit der Ausführungsgeschwindigkeit darüber nachdenkst, was man verbessern könnte?

[BlackJack]

@mutetella: Ich habe auch das Gefühl die Performanceangst schlägt wieder zu. Wie wahrscheinlich so ein Eintrag nicht angezeigt werden muss, für einen gegebenen Tag, hängt ja auch von den konkreten Werten ab.

Ich würde so wie Du das beschrieben hast, einschränken, also von den "grössten" zu den kleinsten "Werten". Falls das später wirklich Geschwindigkeitsprobleme geben sollte, könnte man auch auf diesen Ebenen die Filterergebnisse cachen, weil die Leute ja in der Regel nicht total wild im Kalender herumspringen.

Also dass man zum Beispiel bei der Anfrage zu 2010-10-08 alle Events für 2010 filtert und vermerkt, dann daraus alle für den 10. Monat und vermerkt, und daraus abfragt welche für den 08. zutreffen. Wenn als nächstes der 09. abgefragt wird, braucht nur nur noch in den Events vom 10. Monat suchen die man sich gemerkt hat. Und wenn die nächste Abfrage für den November ist, kann man immerhin schon mal auf die vorgefilterten Events für 2010 zurückgreifen.

Das würde ich aber wie gesagt erst machen, wenn nachweisbar an dieser Stelle ein Geschwindigkeitsproblem entsteht, bei dem diese Massnahme etwas bringt. Und dann würde ich auch erst einmal schauen ob das Cachen der Jahres-Events nicht schon ausreicht. Man sollte es nicht ohne deutlichen Mehrwert komplizierter machen als es sein muss.

[mutetella]

... insbesondere wieso man da etwas prüfen muss / will.

Nun ja, wenn ein Termin, der z. B. an einem 01.10.2010 zum ersten mal auftaucht, sich dann alle 2 Jahre am 15. und 16. März wiederholen soll, dann soll meine Abfrage prüfen, ob sich z. B. am 15.03.2012 so eine Wiederholung befindet. Dazu prüfe ich eben zuerst, ob sich das Jahr 2012 überhaupt im richtigen Interval befindet, ob der März passt und zuletzt auch noch der 15. Tag ein 'Juhu' auslöst:

Code: Alles auswählen

    def yearly(self, date):
        if self.check_year_interval(date):
            if date.weekday() in self.weekdays and \
                weekday_count(date) in self.weekday_counts:
                return self.check_month_interval(date)
            elif date.day in self.days:
                return self.check_month_interval(date)
        else:
            return False

In self.weekdays befinden sich Angaben zu Wochentagen (0 - 6), da es ja auch Wiederholungen wie "Jedes 2. Jahr am 3. Montag im März" gibt, in self.weekday_counts liegen demnach die Wochen (0 - 4). In self.days werden dagegen die fortlaufenden Tage (0 - 31) abgelegt.

... wenn Du weiterhin vor allem über solchen Kleinkram nachdenkst, dann wird Dein Programm nie fertig, ...

Da hast Du sowas von Recht! Aber dieser Kleinkram lässt mir immer keine Ruhe....

Das würde ich aber wie gesagt erst machen, wenn nachweisbar an dieser Stelle ein Geschwindigkeitsproblem entsteht, bei dem diese Massnahme etwas bringt. Und dann würde ich auch erst einmal schauen ob das Cachen der Jahres-Events nicht schon ausreicht. Man sollte es nicht ohne deutlichen Mehrwert komplizierter machen als es sein muss.

Ok, sowas in der Art (wie auch von lunar) musste ich jetzt einfach mal hören! Jetzt kann ich wieder schlafen!

Gruß
mutetella

[Hyperion]

Nun ja, wenn ein Termin, der z. B. an einem 01.10.2010 zum ersten mal auftaucht, sich dann alle 2 Jahre am 15. und 16. März wiederholen soll,

Wie könnte es denn dazu kommen, dass das nicht der Fall ist?

dann soll meine Abfrage prüfen, ob sich z. B. am 15.03.2012 so eine Wiederholung befindet.

Kannst Du nicht einfach bei dem datum nachgucken, ob dieser Termin dort verlinkt wurde? Hängt natürlich von Deiner Datenstruktur ab...

Dazu prüfe ich eben zuerst, ob sich das Jahr 2012 überhaupt im richtigen Interval befindet, ob der März passt und zuletzt auch noch der 15. Tag ein 'Juhu' auslöst:

Code: Alles auswählen

    def yearly(self, date):
        if self.check_year_interval(date):
            if date.weekday() in self.weekdays and \
                weekday_count(date) in self.weekday_counts:
                return self.check_month_interval(date)
            elif date.day in self.days:
                return self.check_month_interval(date)
        else:
            return False

In self.weekdays befinden sich Angaben zu Wochentagen (0 - 6), da es ja auch Wiederholungen wie "Jedes 2. Jahr am 3. Montag im März" gibt, in self.weekday_counts liegen demnach die Wochen (0 - 4). In self.days werden dagegen die fortlaufenden Tage (0 - 31) abgelegt.

Sorry, das ist für mich alles komplett unverständlich so. Speziell mit "Intervall" kann ich hier nichts anfangen...

Zunächst sollte man aber imho über den Sinn des "Prüfens" nachdenken. Ich würde erwarten, dass man entweder direkt über das Datum an den Termin gelangen kann (quasi Datum als Schlüssel) oder aber für einen Termin eine Sequenz von Daten hinterlegt wird, die ich mir angucken kann, oder natürlich auch beides.

[BlackJack]

@Hyperion: Beides geht nicht wenn Du Termine hast wie "Jeden ersten Mittwoch im Monat". Das sind in "beide Richtungen" von heute aus gesehen, unendlich viele. Das Anfangsdatum kann man in der Regel noch dadurch einschränken, dass man keine ersten Mittwoche vor dem Erstellen des Events berücksichtigt, aber für die Zukunft ist da ja offen. Unendlich grosses Dictionary Datum→Event geht halt so nicht und unendliche Liste von Terminen beim Event auch nicht. Also muss man sich was schreiben was ein Datum bekommt und zumindest die sich wiederholenden Events darauf testet, ob sie an dem bestimmten Datum stattfinden oder nicht.

[snafu]

Man sollte es nicht ohne deutlichen Mehrwert komplizierter machen als es sein muss.

Genau das ist IMHO der Punkt. Guter Code löst ein Problem möglichst direkt, d.h. in den meisten Fällen durch den Einsatz von Mitteln, die eine verhältnismäßig geringe Schreibarbeit abverlangen, aber trotzdem leicht nachvollziehbar bleiben. Es ist zwar einerseits schon ganz gut, als Perfektionist an die Sache ranzugehen, weil man sich als ernsthafter Programmierer sicher gewisse Qualitätsstandards setzt, wenn man Code schreibt. Auf der anderen Seite kann man bei übertriebener Perfektion aber leicht das Ziel aus den Augen verlieren. Daher gilt es, irgendwo den Mittelweg für sich zu finden.

Mit der Zeit verbessert man sich ohnehin und würde 1 Jahr alten Code beim neuen Durchsehen ja nicht selten wesentlich anders aufbauen. Das ist aber nichts Schlechtes, sondern etwas Positives, weil es zeigt, dass man in der Entwicklung weiter vorangekommen ist.