NSArray mit NSURL "Finder like" sortieren

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Schreibe ich so undeutlich oder wollt ihr es nicht verstehen?
    Der verglich mit dem int-wert wird nur angewendet wenn nur die zeichen a-z vorkommen.
    Mir ist schon klar dass das system jetzt hergehen könnte und so sortieren würde: acb anstatt abc, das ist mir aber egal weil meine sortierung laut alphabet lateinischem alphabet geschehen soll. Wenn wie gesagt andere zeichen enthalten sind wird ja eh auf die nomale string-compare methode zurückgegriffen.

  • gritsch schrieb:

    in meinem fall die ersten 8 ascii-zeichen in einen uint64 gepackt.

    gritsch schrieb:

    Und es wäre selbst dann nicht langsamer oder anders sortiert wenn es um non-latin zeichen ginge.

    gritsch schrieb:

    ich verwende den numerischen wert nur wenn die ersten 8 zeichen a-z oder A-Z (werden zu a-z) sind.
    Vielleicht liegt das Missverständnis in der unklaren Beschreibung begründet. ;)
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • macmoonshine schrieb:

    gritsch schrieb:

    Der verglich mit dem int-wert wird nur angewendet wenn nur die zeichen a-z vorkommen.
    Das mag ja für deinen Anwendungsfall auch ausreichen. Für den allgemeinen Fall halte ich das Vorgehen aber für suboptimal, insbesondere wenn little_pixel komplette Pfade und nicht nur in einem Ordner sortieren will.
    du kannst das ganze aber auch auf jede pfadkomponente anwenden und somit sehr viel schneller sortieren!

  • gritsch schrieb:

    mattik schrieb:

    Edit: Ein Beispiel wäre Bild3.jpg, Bild22ü.jpg, Bild111.jpg.
    zu deinem edit: das würde mit der nomalen string-compare methode verglichen weil eben die ersten 8 zeichen der jeweils zwei zu vergleichenden werte nicht nur a-z enthalten!
    Ah, ich hatte noch ASCII aus dem ersten Post im Kopf. Aber man sieht den Punkt: Du verlässt dich auf Annahmen über ein bestimmtes Verhalten (in diesem Fall, dass der String-Vergleichsoperator lateinische Buchstaben in einer bestimmten Reihenfolge sortiert). Mag sein, dass das in deinem Fall machbar ist, bei localizedStandardCompare (der nunmal der Vergleichsoperator für "Finder-like" ist) würde ich meine Hand dafür nicht ins Feuer legen - nicht für alle Locales und nicht für die Zukunft. Und die Last, das sicherstellen zu müssen, würde ich mir nicht an die Backe binden wollen.
    Multigrad - 360°-Produktfotografie für den Mac

  • mattik schrieb:

    gritsch schrieb:

    mattik schrieb:

    Edit: Ein Beispiel wäre Bild3.jpg, Bild22ü.jpg, Bild111.jpg.
    zu deinem edit: das würde mit der nomalen string-compare methode verglichen weil eben die ersten 8 zeichen der jeweils zwei zu vergleichenden werte nicht nur a-z enthalten!
    Ah, ich hatte noch ASCII aus dem ersten Post im Kopf. Aber man sieht den Punkt: Du verlässt dich auf Annahmen über ein bestimmtes Verhalten (in diesem Fall, dass der String-Vergleichsoperator lateinische Buchstaben in einer bestimmten Reihenfolge sortiert). Mag sein, dass das in deinem Fall machbar ist, bei localizedStandardCompare (der nunmal der Vergleichsoperator für "Finder-like" ist) würde ich meine Hand dafür nicht ins Feuer legen - nicht für alle Locales und nicht für die Zukunft. Und die Last, das sicherstellen zu müssen, würde ich mir nicht an die Backe binden wollen.
    bestimmte gegebenheiten muss man immer irgendwo definieren und ich definiere nun mal dass a < b < c < d etc ist. Sieht apple das irgendwann anders wird sich zeigen ob apple damit durch kommt oder doch lieber die sortierreihenfolge verwendet wird die jeder aus der schule kennt...

  • Um noch mal auf den OP zurückzukommen. Ich würde umgekehrt vorgehen:
    1. Einfache Sortierung mit Bordmitteln und ohne Optimierung implementieren.
    2. Time Profiler in Instruments anschmeißen und drüber rödeln lassen.
    3. Kritische Teile ermitteln und durch optimierten Code ersetzen.
    Gerade der Time Profiler kommt manchmal auf Sachen, ich sach es euch... ;)
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    Um noch mal auf den OP zurückzukommen. Ich würde umgekehrt vorgehen:
    1. Einfache Sortierung mit Bordmitteln und ohne Optimierung implementieren.
    2. Time Profiler in Instruments anschmeißen und drüber rödeln lassen.
    3. Kritische Teile ermitteln und durch optimierten Code ersetzen.
    Gerade der Time Profiler kommt manchmal auf Sachen, ich sach es euch... ;)
    Eventuell auch den speicher-verbrauch im auge behalten - unter OS X ja nicht so wichtig wie unter iOS...

  • gritsch schrieb:


    bestimmte gegebenheiten muss man immer irgendwo definieren und ich definiere nun mal dass a < b < c < d etc ist. Sieht apple das irgendwann anders wird sich zeigen ob apple damit durch kommt oder doch lieber die sortierreihenfolge verwendet wird die jeder aus der schule kennt...
    In diesem Fall muss man es nicht definieren, man kann auch einfach das eingebaute Verhalten übernehmen, das wahrscheinlich aus gutem Grund so gemacht ist. Du kannst dir natürlich alles definieren was du willst, die Frage ist nur, ob das in der echten Welt nützlich ist. Ich hätte zum Beispiel keine Lust, mit Spaniern zu diskutieren, die die traditionelle Sortierung eingestellt haben, warum manchmal Mist heraus kommt, weil in der Sortierung das "ch" nach "cz" und das "ll" nach "ly" kommt. Es gibt etliche andere Beispiele aus anderen Bereichen dieser Welt. Natürlich kann man den Unicode Collation Algorithm neu erfinden, muss man aber nicht. Die Fehler haben schon andere gemacht. Ich persönlich stehe nicht darauf, das zu wiederholen, aber das kann jeder so machen wie er will.
    Multigrad - 360°-Produktfotografie für den Mac

  • wie gesagt, es handelt sich in meinem fall nur um englische texte bzw kurze wörter. Wenn man von anderen sprachen ausgehen muss kann man solche optimierungen natürlich nicht so einfach machen.
    das problem war aber früher wie gesagt noch viel extremer weil damals zwar die gleiche datenmenge zu verarbeiten war, jedoch sehr viel langsamere CPUs und weniger RAM vorhanden war. auch die implementierungen haben sich wohl verbessert.
    in den allermeisten fällen sind solche optimierungen eh nicht nötig oder sinnvoll.