(gelöst) Wie kann ich das sortieren?

[tobo]

Tausendertrenner werden einfach ignoriert als seien sie nicht da, wie hier erahnt werden kann:

Code: Alles auswählen

$ printf '102\n1.03\n10.1\n10.0\n1.01\n101'| LC_ALL=de_DE.UTF-8 sort -n
10.0
1.01
101
10.1
102
1.03

Also bei mir werden die Trenner nicht vollständig ignoriert!? Als numerischer Trenner schon, aber der Punkt wandert innerhalb der 101er-Gruppe von links nacht rechts:

Code: Alles auswählen

$ printf '102\n1.03\n10.1\n10.0\n1.01\n101'| LC_ALL=de_DE.UTF-8 sort -n
10.0
101
1.01
10.1
102
1.03

Besser sichtbar hier:

Code: Alles auswählen

$ printf '10.001\n100.01\n1.0001\n1000.1\n10001\n'| LC_ALL=de_DE.UTF-8 sort -n
10001
1.0001
10.001
100.01
1000.1

[Meillo]

Also bei mir werden die Trenner nicht vollständig ignoriert!? Als numerischer Trenner schon, aber der Punkt wandert innerhalb der 101er-Gruppe von links nacht rechts:

Ich wuerde das als Implementierungsbesonderheit werten.

Wenn alle ``Darstellungen'' innerhalb der 101er-Gruppe als zahlenmaessig gleichwertig erachtet werden, dann ist undefiniert in welcher Reihenfolge sie kommen ... ausser du verwendest `-s' (stabilized sort), dann sollten sie in der Reihenfolge der Eingabe erscheinen.

[tobo]

Ich wuerde das als Implementierungsbesonderheit werten.

Wenn alle ``Darstellungen'' innerhalb der 101er-Gruppe als zahlenmaessig gleichwertig erachtet werden, dann ist undefiniert in welcher Reihenfolge sie kommen

Das mag sein. Bei mir tritt diese Besonderheit jedoch in der GNU-, Heirloom, Busybox- und Suckless-Variante von sort auf. Welches sort erzeugte denn bei dir die Ausgabe?

[Meillo]

Bei mir tritt diese Besonderheit jedoch in der GNU-, Heirloom, Busybox- und Suckless-Variante von sort auf. Welches sort erzeugte denn bei dir die Ausgabe?

sort (GNU coreutils) 8.13, auf Debian oldstable. (Es koennte evtl. auch am Locale liegen, k.A.: locale (Debian EGLIBC 2.13-38+deb7u11) 2.13)

Meine Gedanken sind folgende:

Ist der zahlenmaessige Wert von ``10.1'' und ``1.01'' gleich? Wenn ja, dann unterliegt die Reihenfolge nur der Implementierung des Sortieralgorithmuses. Jedenfalls kenne ich keine inhaltliche Logik fuer eine sinnvolle Ordnung dieser zwei invalider Notationen.

Die einzige Regel, die fuer mich Sinn macht, ist das Ignorieren von Tausendertrennern, egal an welchen Stellen sie stehen. (Das ist auch implementatorisch gut umsetzbar ... und damit wahrscheinlich so auch umgesetzt.)

Interessant ist, dass `-nu' die zahlenmaessig gleichen Werte ``10.1'' und ``1.01'' nicht vereint, waehrend ``100'' und ``100,0'' zusammenfallen! ... vielleicht ist das aber auch nur ein undefiniertes Verhalten und die Folge von ``garbage in, garbage out''.

[tobo]

Die einzige Regel, die fuer mich Sinn macht, ist das Ignorieren von Tausendertrennern, egal an welchen Stellen sie stehen. (Das ist auch implementatorisch gut umsetzbar ... und damit wahrscheinlich so auch umgesetzt.)

Würden die "vollständig" ignoriert werden, dann sollte doch die Reihenfolge der 101er im printf entscheidend für die Ausgabe sein!? Wie dem auch sei, habe gerade mal sort (coreutils) aus Wheezy getestet und das Ergebnis ist gleich zu Jessie.

[Meillo]

Die einzige Regel, die fuer mich Sinn macht, ist das Ignorieren von Tausendertrennern, egal an welchen Stellen sie stehen. (Das ist auch implementatorisch gut umsetzbar ... und damit wahrscheinlich so auch umgesetzt.)

Würden die "vollständig" ignoriert werden, dann sollte doch die Reihenfolge der 101er im printf entscheidend für die Ausgabe sein!?

Nur wenn es ein stabiler Sortieralgorithmus ist, den man bei GNU sort mit `-s' erzwingen kann. Siehe (mit Dezimalkomma):

Code: Alles auswählen

:-Q printf '100,0\n100\n' | LC_ALL=de_DE-UTF-8 sort -n 
100
100,0

:-Q printf '100,0\n100\n' | LC_ALL=de_DE-UTF-8 sort -ns
100,0
100

(Interessant ist, dass mit `-u' immer die ``100,0'' ausgegeben wird, egal ob sie mit oder ohne `-s' die erste oder zweite Zahl war. Das mag vielleicht daran liegen, dass sie eine groessere Genauigkeit bietet ... ach, man sollte man in diesen Quellcode reinschauen, das scheint mir eine ganze Menge schwarzer Magie zu sein ...)

Wie dem auch sei, habe gerade mal sort (coreutils) aus Wheezy getestet und das Ergebnis ist gleich zu Jessie.

Das mag viele Gruende haben. Vielleicht wird intern immer qsort(3) verwendet, das je nach Rechnerarchitektur unterschiedlich implementiert ist ... was weiss ich.

Mit `-s' sollte das Ergebnis aber immer gleich sein, weil dafuer definiert ist, dass gleiche Werte in der Reihenfolge der Eingabe auszugeben sind. Ohne `-s' ist die Reihenfolge in dem Fall implementierungsspezifisch. Soweit die Theorie.

[medias]

Nein, so:

Code: Alles auswählen

sed 's/\./,/' bsp.txt | LC_NUMERIC="de_DE.UTF-8" sort -t '(' -k1n -k2 | sed 's/,/./'

Danke für die Hilfe. Ich hatte nicht geahnt das es so schwierig sein würde.

Das mit der 2.100 (in meinem Fall ist das eine Textziffer) ist auch ein Problem wenn ich diese Tabelle nach Excel importiere. Ich weiss noch nicht warum, aber 2.100 wird dabei 2100. ABER 2.99 bleibt 2.99. Sehr dämlich das!