From: Paul Louden <paulthenerd_at_gmail.com>
Date: Wed, 18 Mar 2009 16:22:14 -0500

Dominik Riebeling wrote:
> 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).
>
I agree that it could be unintentional, but disagree that "numeric
sorting" matters in this case - if you have a mix of random songs, why
does 03 need to be between 2 and 4? Meanwhile, if someone intentionally
prefixes something with a 0, they intend for it to be first, so it
should be. This sounds like a case of "let's make the unimportant case
work one way, while choosing to break the case where people make
intentional changes."
> 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 is originally based on a natural sorting algorithm, which does a
lot more than numbers it seems. My understanding was the original intent
was to simply fix 1, 10, 2, 3, 4 into 1, 2, 3, 4, 10. I don't see why
this *should* ignore leading zeros. I don't think we should ever assume
any part of a filename is unintentional. I think assuming numbers are
written as a human normally does is fine (1, 2, 3, 10, 11, 12) but if
someone chooses to add something to alter sorting we should still
respect it. You don't accidentally add a 0, and if there are random
zeros in a mix folder the order of playback almost certainly isn't meant
to be 2, 03, 4, but rather "whatever order" if they just chose to
haphazardly mix them.

Also, which comes first: 001 or 01? If we're going to recognize that 001
has one more zero than 01, why don't we recognize that 00number has more
zeros than 0number, even if the two numbers are different?
> 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 expect people will number disks 1.01 - 1.12 rather than 1.1, 1.2,
1.10, 1.12. This is only my personal assumption, but if that's the case,
our current method works for it.
> I'm pretty sure I've missed some of my points right now :) What do
> people think about this sorting thing?
>
>
Well, we're currently using an "existing" algorithm. One that *may* be
used in other FLOSS (I don't know, and haven't investigated). To me, the
two sides of the argument are basically "do we want to use it as-is,
such that our sorted lists look the same as lists in other applications,
or do we want to define our own rules for 'natural' list sorting?" Of
course, this is dependent upon research I haven't done (specifically, do
any other applications use this sort algorithm).

Maybe we should just see if various FLOSS file browsers have a common
"natural" sort, and use it, so that our files are likely to show up in
the host's browser the same order as they show up in ours?
Received on 2009-03-18