Seite 2 von 2

Re: Memory Maker

Verfasst: Samstag 28. Mai 2011, 15:07
von Dauerbaustelle
Py-Prog hat geschrieben:Ist das immer noch Spagetti-Code?

Code: Alles auswählen

def finddoublefiles():
    run_again = False
    for filetype in allfiles:
        for to_check_file in allfiles[filetype]:
            for file in allfiles[filetype]:
                if not to_check_file == file and to_check_file[0] == file[0]:
                    if filecmp.cmp(to_check_file[1], file[1]):
                        doublefiles.append(file[1])
                        allfiles[filetype].remove(file)
                        run_again = True
                        break
            if run_again:
                break
        if run_again:
            break
    if run_again:
        finddoublefiles()
Ich hab zwar schon angefangen das anders zu machen aber irgendwie erscheint mir das besser.
Ich hab nie behauptet, dass dein Code spaghetti ist. Aber dass du viel zu viele Einrückungsebenen hast. Immer noch. Reduziere mal die Anzahl an `break`s und dieses `run_again` komplett. Außerdem wirst du mit dieser Rekursion an das Rekursionslimit stoßen bei großen Mengen an Dateien/Ordnern.

Re: Memory Maker

Verfasst: Samstag 28. Mai 2011, 15:18
von Py-Prog
Dann funktioniert es aber nicht, wenn ich einfach die Funktion nochmal aufrufe lösche ich ja was, was später in einer For-schleife wieder aufgerufen werden soll.

Re: Memory Maker

Verfasst: Samstag 28. Mai 2011, 17:50
von Dauerbaustelle
Tja, das ist jetzt die Aufgabe, das funktionierend zu lösen ;-)

Re: Memory Maker

Verfasst: Sonntag 29. Mai 2011, 15:21
von Py-Prog
Dauerbaustelle hat geschrieben:Tja, das ist jetzt die Aufgabe, das funktionierend zu lösen ;-)
Traceback (most recent call last):
File "<pyshell#0>", line ∞, in mind
Solve complex tasks
BrainError: Brain is overloaded

Copyright Py-Prog

(In klartext:
ich lass das so wies ist, was da sonst raus kommt ist noch unübersichtlicher.
Erinnert mich an Mathe ein vereinfachter Term ist auch nicht einfacher zu lösen und braucht mehr zeit.)

Re: Memory Maker

Verfasst: Sonntag 29. Mai 2011, 18:07
von microkernel
Py-Prog hat geschrieben:3)zwei verschiedene Dateien können die Gleiche Hash summe ergeben und ich verschwende die Rechenleistung bei jeder Datei
Nein. Moderne Hash-Algorithmen sind immer kollisionsresistent. Außerdem gibt es auch noch Hash-Algos welche nicht ganz so viel Rechenleistung wie die populären (MD5, SHA256 und etc.) benötigen (z.B.: Bob Jenkins Algorithmus oder SDBM Algorithmus)

Re: Memory Maker

Verfasst: Sonntag 29. Mai 2011, 18:27
von cofi
microkernel hat geschrieben:
Py-Prog hat geschrieben:3)zwei verschiedene Dateien können die Gleiche Hash summe ergeben und ich verschwende die Rechenleistung bei jeder Datei
Nein. Moderne Hash-Algorithmen sind immer kollisionsresistent.
Ja, aber eben nur das und nicht kollisionsfrei. Und es gilt auch nur fuer kryptographische Hash-Algorithmen (dort ist es eine Mindestanforderung).
Zwei Dateien koennen den gleichen Hash ergeben, aber dennoch ist es fuer die meisten Anwendungen trotzdem akzeptabel, wie ja schon angesprochen wurde.

Re: Memory Maker

Verfasst: Sonntag 29. Mai 2011, 18:38
von lunar
@cofi: Versteht man unter einer „kollisionsresistenten“ (aka perfekten) Hashfunktion nicht eine injektive solche? Die wäre dann per definitionem schon kollisionsfrei.

Die Behauptung von "microkernel" wäre dann mithin auch falsch. Eine Hashfunktion, die Elemente einer unendlichen Menge (e.g. beliebige Bytefolgen) auf eine endliche Menge (e.g. Zahlen begrenzter Länge) reduziert, kann niemals injektiv und mithin auch nicht kollisionsresistent sein.

Moderne Hashalgorithmen sind allenfalls (stark) kollisionssicher. Es ist also mit vertretbarem Aufwand unmöglich, zu einer gegebenen bzw. beliebigen Eingabe eine Kollision zu finden. Was nicht heißt, dass solche Kollisionen nicht doch zufällig auftreten können, wie klein die Wahrscheinlichkeit dafür auch immer sein mag.

Re: Memory Maker

Verfasst: Sonntag 29. Mai 2011, 19:04
von cofi
lunar hat geschrieben:@cofi: Versteht man unter einer „kollisionsresistenten“ (aka perfekten) Hashfunktion nicht eine injektive solche? Die wäre dann per definitionem schon kollisionsfrei.
In meiner Welt gilt "kollisionsresistente" Hashfunktion != perfekte Hashfunktion und nur perfekte sind tatsächlich injektiv.

Scheinbar lebt zumindest auch Wikipedia in meiner Welt: http://en.wikipedia.org/wiki/Collision_resistant http://en.wikipedia.org/wiki/Perfect_hash_function

Aber natuerlich sind perfekte Hashfunktionen auch kollisionsresistent ;) Und beim Rest bin ich auch bei dir.

Re: Memory Maker

Verfasst: Sonntag 29. Mai 2011, 19:09
von lunar
@cofi: Na, dann will ich mich auch mal in Deine Welt begeben ;) Danke für die Aufklärung.

Re: Memory Maker

Verfasst: Montag 30. Mai 2011, 11:48
von mkesper
Ich würde da pragmatischer vorgehen. Wenn die Größe identisch ist, kannst du davon ausgehen, dass Dateien mit gleichem md5-Hash auch den gleichen Inhalt haben. Notfalls prüfst du noch die ersten 1024 Bytes.

Re: Memory Maker

Verfasst: Mittwoch 1. Juni 2011, 16:43
von Py-Prog
Wenn es jemand schafft einen Algorithmus zu entwickeln der einen Hash zurück gibt der niemals gleich ist, der ist dann Reich, weil das eine Extreme Komprimierung wäre!!!!!!!!

Re: Memory Maker

Verfasst: Mittwoch 1. Juni 2011, 16:48
von Leonidas
Dann ist das aber kein Hashalgorithmus sondern ein Kompressionsalgorithmus. Der Sinn von Hashes ist ja gerade nicht umkehrbar zu sein.

Re: Memory Maker

Verfasst: Mittwoch 1. Juni 2011, 16:53
von Py-Prog
Aber das ist es ja eben, ein Hash hab viel weniger Möglichkeiten als z. B. eine 4 MB große Datei.
Und des halb wird es immer gleiche Hash geben können.

Re: Memory Maker

Verfasst: Mittwoch 1. Juni 2011, 17:18
von Leonidas

Re: Memory Maker

Verfasst: Mittwoch 1. Juni 2011, 19:14
von HerrHagen
@Py-Prog: Ja. Aber wenn zwei Dateien einen unterschiedlichen Hash haben weißt du, dass sie unterschiedlich sind, ohne, dass du die Datei komplett vergleichen musst. Wenn du auf Nummer sicher gehen willst, musst du nur noch die Dateien mit dem selben Hash-Wert auf Gleichheit prüfen.