Posts by calculator

    Sieht bei mir anders aus:
    a)
    1. Fall: n^3, das log(2) fällt ja weg wegen dem logarithmus dualis
    2. Fall: n^3, wieso lässt du da das sqrt(n^6) denn einfach weg?
    3. Fall streichen


    O, Theta, Omega, Omega.


    b)
    1. Laufzeit n*log(n), a = n weil hier ebenfalls 2^log(n) durch den logarithmus dualis wegfällt, b = n^2 * log(n) weil hier in der Schleife mit b mit n addiert wird. Wieso lässt du hier log(n) weg?
    2. Laufzeit = a = b = 2^n


    Bin mir nicht sicher ob meins so stimmt, du könntest ja noch erklären wie du auf deine Ergebnisse kommst.

    Wie habt ihr das mit den null gemanaged? Bei


    search client0 m
    test_search client0 client3 client5 client1 client2 null client0 client3


    gibts da bei mir ned NullPointerException NaNoNaNed, aber wie ich umgehe ich die?


    try-catch und dann i erhöhen.


    Edit: Natürlich fängst du nicht die NullPointerException ab, sondern die NoSuchDocument Exception.

    An einem einfachen Beispiel mit Zahlen von 1 bis 10:
    Angenommen du startest bei der Wurzel (die natürlich traversiert werden muss), die ist 7. Die nächste Zahl die traversiert wird ist 3, du bist also von der Wurzel aus links gegangen. Die nächste traversierte Zahl ist dann 5, das heißt von 3 bist du nach rechts weitergegangen. So und die nächste traversierte Zahl ist 2, du willst also von 5 nach links weitergehen. Kann aber nicht sein, denn die 2 müsste eigentlich links von der 3 stehen, bei der 3 bist du aber vorhin nach rechts gegangen.


    Am besten aufzeichnen, dann sollte es klar sein.

    Nein, bei mir kommt zum richtigen Ergebnis, ab welcher iteration beibt's bei dir hängen?


    Bei i=25. Dann komm ich auf hx=8, hy=2 und das ist genau der Punkt wo die Areas von Client1, Client4 und Client5 zusammentreffen. Das Dokument liegt aber in Client1, weil die linke Kante von Client1 auf der das Dokument liegt ja zu Client1 gehört.


    EDIT3: ich glaube langsam wirklich an einen Fehler in der Angabe, alle anderen Tests gehen durch wenn man den Vorrang dem lexikalisch größeren Client gibt.


    Ach wirklich? Wenn ich das < bei compareTo in ein > ändere kommt es bei Command#16 zu einer Endlosrekursion, weil immer abwechselnd Client4 und Client5 aufgerufen werden. Das ist nicht der Fall wenn ich den lexikalisch kleineren Client nehme, weil dann zu Client1 gegangen wird.

    Danke, hab das jetz so implementiert, zu deinem Problem: bei mir wird auch client5 statt client4 genommen, bist du sicher, dass beide die selbe distanz haben?


    Also ich habs mir einerseits im Programm ausgeben lassen und andererseits per Hand ausgerechnet, sollte also schon die gleiche Distanz haben :/


    Edit: Habe ich vielleicht die Hashfunktion falsch implementiert? Bei mir sollte Dokument "m" bei i=1 auf hx=5 und hy=2 liegen, kann das wer bestätigen?

    Wie kommst du dazu, dass das "null" mitausgegeben wird?
    Hab den ersten Fehler bei Command10, weil die nulls bei der Ausgabe fehlen, alle anderen ClientIDs stimmen sonst..


    Das null wird immer dann ausgegeben, wenn i erhöht wird. Sprich du findest den Client, der für die Position zuständig ist, die getDocument Methode findet aber das Dokument nicht (und wirft eine Exception - die fange ich selbst ab, keine Ahnung ob das stimmt?!). Und wenn i erhöht wird berechnest du natürlich die Position neu und beginnst wieder von vorne zu suchen.

    Wäre nett wenn mir jemand helfen könnte: Bei Testinstanz 0000 Command#12 sollte dieses Ergebnis herauskommen:

    Code
    1. search client2 m
    2. test_search client2 null client2 client1 client5 client3


    Mein Ergebnis lautet aber:

    Code
    1. search client2 m
    2. test_search client2 null client2 client1 client4 client3


    Also ein Unterschied an Position 4. Jetzt verstehe ich nicht wieso hier Client5 genommen werden sollte anstatt Client4, die beiden haben zur Position von m die gleiche euklidische Distanz, Client4 hat aber eine kleinere lexikographische ID -> meiner Auffassung nach sollte mein Ergebnis stimmen.


    Hat jemand eine Idee?

    Ich versuch dich nochmal mit diesem Vorschlag zu überreden: Das sind ja Zahlen aus dem Nonadezimalsystem, die kann man natürlich ins Dezimalsystem umrechnen. Jetzt ist aber B = 11 und B00 = 3971 (weil 11*19*19), deshalb ist B = B00 nicht der richtige Ansatz. Deshalb sollte meiner Meinung nach am Ende die sortierte Liste, ins Dezimalsystem umgewandelt, eine aufsteigend sortierte Folge von Dezimalzahlen werden - denn im Endeffekt sortieren wir ja genau danach. Ich kann mich natürlich auch irren, bin mir da aber doch recht sicher.

    Also ich hab hier mit führenden Nullen ergänzt, also z.B. B = 00B. So wie im Dezimalsystem z.B. 5 = 005. Ich denke, dass es für Sortieren mit Fachverteilung notwendig ist, dass alle Zahlen mit gleich vielen Stellen angegeben werden, sonst würde das Ergebnis falsch werden, denn wenn du B bei jedem Durchgang in das Fach B legst (bzw erst beim letzten Durchgang in das Fach B) steht es ja nach Zahlen, die eigentlich größer sind als B.


    Glaub ich nicht. n^2 herausziehen ist schon richtig, aber wenn du dann n^(9/4) durch n^2 * logn dividierst bleibt n^(1/4) / logn über, und da wächst der Zähler schneller als der Nenner, man findet also keine Obergrenze -> Omega



    Rechts oben:

    Warum konvergiert logn(n) ^ n gegen 1? Ich da mathematisch etwas schwach. :(


    logn(n) ist selbst schon 1, siehe auch hier: http://www.wolframalpha.com/input/?i=logn%28n%29
    und 1^n bleibt dann natürlich 1.