Code besser machen



  • Hallo, ich habe einen Algorithmus zur berechnung von Fibonaccizahlen implementiert. Jetzt frage ich mich an welchen Stellen ich das verbessern könnte. Mein Stack läuft schon ziemlich früh über (so bei fib(6000)) und ich bin mit der Übergabe des BigInteger in fibloop nicht so ganz einverstanden. Geht das auch einfacher?

    static BigInteger fibloop(BigInteger p, BigInteger q, int i, int n) {
        if(i > n) return q;
        return fibloop(q, new BigInteger("0").or(p).add(q), i + 1, n);
    } 
    
    static BigInteger fib(int n) {
        return fibloop(new BigInteger("1"), new BigInteger("1"), 2, n);
    }
    

    Btw, warum hat BigInteger keinen Kopierkonstruktor oder eine set-Funktion für BigInteger. Ist irgendwie komisch die Klasse, oder ich kann nicht mit der Doku umgehen (kann auch sein 😉 )

    Schönen Morgen wünscht,

    Tobi


  • Mod

    1. Der Überlauf des Stacks liegt an deiner rekursiven Implementierung des Algorithmus. Ich kann garnicht nachvollziehen, warum du das so gemacht hast. Dein Ansatz ist doch sowieso schon iterativ. Wenn du das auch iterativ (mit einer for-Schleife) implementierst, dann kriegst du wahrscheinlich keine Probleme mit dem Stack.

    2. Nimm keine Konstruktoren, die einen String als Parameter erwarten. Das bremst.

    3. Ich vermute, dass das "add" das Objekt selbst nicht verändert. Statt dem

    new BigInteger("0").or(p).add(q)
    

    dürfte also auch ein

    p.add(q)
    

    ausreichen. ...das ist jetzt aber nur eine Vermutung, muss also vorher getestet werden.

    4. Vermutlich bietet BigInteger statt einem Copy-Konstruktor eine clone-Methode. Aber es wird vermutlich kein Copy-Konstruktor benötigt, weil BigInteger-Objekte vermutlich unveränderlich sind, so wie Strings.



  • Gregor schrieb:

    1. Der Überlauf des Stacks liegt an deiner rekursiven Implementierung des Algorithmus. Ich kann garnicht nachvollziehen, warum du das so gemacht hast. Dein Ansatz ist doch sowieso schon iterativ. Wenn du das auch iterativ (mit einer for-Schleife) implementierst, dann kriegst du wahrscheinlich keine Probleme mit dem Stack.

    Muss es aber leider rekursiv machen -> AUfgabenstellung.

    Gregor schrieb:

    2. Nimm keine Konstruktoren, die einen String als Parameter erwarten. Das bremst.

    Ok, habs mit BigInteger.ONE initialisiert.

    Gregor schrieb:

    3. Ich vermute, dass das "add" das Objekt selbst nicht verändert. Statt dem

    new BigInteger("0").or(p).add(q)
    

    dürfte also auch ein

    p.add(q)
    

    ausreichen. ...das ist jetzt aber nur eine Vermutung, muss also vorher getestet werden.

    Stimmt!

    Gregor schrieb:

    4. Vermutlich bietet BigInteger statt einem Copy-Konstruktor eine clone-Methode. Aber es wird vermutlich kein Copy-Konstruktor benötigt, weil BigInteger-Objekte vermutlich unveränderlich sind, so wie Strings.

    Stimmt auch! Danke, hast mir sehr geholfen 👍 .

    Mfg,

    Tobi


  • Mod

    In 4 Minuten hast du das alles geändert, getestet, überprüft, beantwortet!?!?
    😮 😮 😮 😃


Log in to reply