Algorithmus verbessern

[The_S]

Sry, ich hab keine Ahnung, was ich dem Topic für nen Titel geben soll, geschweigeden, wo es am Besten aufgehoben is.

Ich möchte testen, ob ich von einem bestimmten Datum an (z. B. 14.7.2005) auf ein anderes Datum (z. B. 30.6.2005) komme, wenn ich immer die selbe Anzahl, an Stunden, Tagen, Wochen, ... abziehe. Da diese Differenzen aber sehr groß und "das Abzuziehende" dagegen relativ klein seien kann, hab ich Angst um meine Performance. Momentan fällt mir nur das hier ein:

differenz = -3;
GregorianCalendar now = new GregorianCalendar(jahr, monat, tag);
GregorianCalendar before = new GregorianCalendar(jahrB, monatB, tagB);
while (now.getTimeInMillis() > before.getTimeInMillis()) {
    now.add(Calendar.DATE, differenz);
}
if (now.getTimeInMillis() == before.getTimeInMillis()) {
    return true;
}
else {
    return false;
}

Und das lahmt vermutlich bei unterschieden von mehreren Jahren, aber gleichzeitig immer nur wenige Tage abgezogen werden.

 

[Beni]

???:L

Die Differenz in Millisekunden berechnen.
Die Länge einer Stunde/Tages/Woche... in Millisekunden berechnen.

Differenz modulo (%-Operator) Länge rechnen. Falls es 0 ergibt, geht es :wink:

 

[The_S]

Klingt logisch, glaub ich ???:L . Ich tests grad ma aus!

[edit] funzt perfekt! Danke!

 

[The_S]

Funzt doch net! Fogender Code

import java.util.*;

public class test {
	
	public static void main(String[] args) {
		
		GregorianCalendar eins = new GregorianCalendar(2006, 6, 20);
		GregorianCalendar zwei = new GregorianCalendar(2005, 6, 20);
		long woche = 1000 * 60 * 60 * 24 * 365;
		long diff = eins.getTimeInMillis() - zwei.getTimeInMillis();
		if ((diff % woche) == 0) {
			System.out.println(true);
		}
		else {
			System.out.println(false);
		}
		while (eins.getTimeInMillis() > zwei.getTimeInMillis()) {
			eins.add(Calendar.DATE, -365);
		}
		if (eins.getTimeInMillis() == zwei.getTimeInMillis()) {
			System.out.println(true);
		}
		else {
			System.out.println(false);
		}
	}
}

gibt zuerst false und dann true aus! Oder habsch da jetzt nen Denkfehler drin!?

 

[hugo]

Ist der 20.06.2006 nicht der 366. Tag? Warum das dann mit dem Calendar.add funktioniert, weiß ich nicht. Bin aber auch schon auf das Phänomen gestoßen, dass er dort zusätzlich einen Tag abzieht.

 

[The_S]

Du kannst das auch für 2010 und 2009 oder 2011 und 2010, ... machen! Kommt immer des Ergebnis (hat also nix mit Schaltjahren zu tun (mal davon abgesehen, dass 2005 und 2006 auch kein Schaltjahr ist :wink: )), oder auf was wolltest du jetzt raus mit "366. Tag"?

BTW: GregorianCalendar(2006, 6, 20) ist der 20.7.2006

 

[hugo]

Das mit dem Schaltjahr hatte ich nicht gemeint. Finde gerade nicht die richtigen Worte. Aber bei der Berechnung der Differenz von diff und woche kommen 347 Tage heraus. Warum weiß ich aber noch nicht.

 

[The_S]

Dann geb bescheid, wenn de ne Lösung gefunden hast (ja, ich such auch weiter :wink: ), weil ich nämlich gerade mal rumexperimentiert hab und die vollständige Berechnung mit meiner alten (funktionierenden Methode) bei ca. 5 Berechnungen pro Satz und ca. 1000 Sätzen auf einem 2GHz Pentium 4 mit 1GB Arbeitsspeicher (ka ob der RAM hier relevant is ???:L ) und einem Abstand von 15 Jahren, bei einer Differenz von 2 Tagen probiert hab. Joa, der PC braucht an die 30 Sekunden um das auszurechnen! Das is zuviel!

 

[hugo]

Rein Theroretisch sollte do woche / 1000 / 60 / 60 / 24 = 365 sein. Wenn man sich das aber mal ausgeben lässt kommt man auf 17! :bahnhof:

Bis zu 25 Tagen stimmt der Wert. Ab dem 25. wird auf -24 umgesprungen. Hoffentlich kann mir das mal jemden erklären.

 

[hugo]

Da lag der Fehler näher als man denkt. Wenn man Woche als long berechnen will, sollte man auch die Werte dafür als long bezeichnen. Sonst kommt es zu einem Überlauf bei den int-Werten.

Also wie folgt müsste es heißen:

long woche = 1000l * 60l * 60l * 24l * 365l;

 

[The_S]

Wenn ich das jetzt richtig verstanden habe funktioniert der Algo von Beni, wenn man die Werte alle als long bezeichnet!?