Rockbox mail archiveSubject: how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
how is strnatcmp aka "Interpret numbers while sorting" supposed to sort?
From: Dominik Riebeling <dominik.riebeling_at_gmail.com>
Date: Wed, 18 Mar 2009 22:10:45 +0100
I started wondering how the value "as whole numbers" for the setting
"interpret numbers while sorting" is intended to work. Currently it
seems to get changed in svn quite often. However, I haven't seen a
consensus how this feature is supposed to work (read: sort) gathered,
especially before committing. A recent discussion is here:
Maybe I've missed such a consensus -- in this case someone please
point me to the right direction and ignore this mail :) Changing the
behaviour of this setting frequently is a rather bad thing IMO. We
need to specify how we want it to work and implement it that way.
Doing this kind of "discussion in svn" is a bad thing and can only
lead to confusion among users. We didn't do this for the "study mode"
feature either, even if there was a consensus to change it.
Now, how should this feature sort? From my point of view, I'd expect it to
- treat digits as numbers. A value of "00" equals to zero and thus
gets sorted before the number 1, regardless if that is "1", "01" or
"001". Completely skipping the zero (as it's only leading zeros) is as
broken as to not strip leading zeros -- "003" should equal to 3 and
"01" to 1, thus the latter sorting before the former. A situation
where a folder can contain files starting with "02" and "4" the same
time is something that could happen and still not being intentional
(just think of copying files from various albums to a mix folder).
Either treat digits as number or don't treat them as numbers at all.
- Spaces shouldn't get collapsed. A space is a space, and "interpret
numbers" doesn't tell anything about spaces. At least at some point
during the lifetime of this setting spaces were collapsed. Nothing
that is a number ...
This still leaves some open issues I'm not sure how to deal about:
- how are floating-point numbers to be treated? "1.001" is smaller as
"1.01" when treating as numbers, so on the one hand I'd expect them to
sort that way. On the other hand, recognizing the dot as decimal
separator is broken as well -- not all languages use it as decimal
separator (like german using the comma). Stopping the number-treating
at dots is also kinda broken -- how should a naming be handled as
"discnumber.tracknumber", i.e. like "1.2", "1.10" -- which one has to
be sorted first? The best solution here might be to treat all numbers
as single numbers, regardless if they might be floating point numbers
-- I guess it's more common to have a "1.3" numbering to mark
discnumber.track instead of a floating point number "1.003".
I'm pretty sure I've missed some of my points right now :) What do
people think about this sorting thing?
Received on 2009-03-18