Basic error in numerical sorting of album names

[simoncn]

(13-01-2014 08:55)simoncn Wrote:  Thanks for this helpful summary of the issues involved. I'd like to add a few points:

1) Given that this feature does involve some extra cost, it needs to be optional and it needs to be implemented in a way that doesn't cause overhead for users who don't have the feature enabled. Also, it is very desirable that it doesn't cause overhead when sorting strings that don't contain embedded numbers.

2) It needs to be well specified. For example, is '00' greater or less than '0' and is '01' greater or less than '1'? These strings cannot be considered exactly equal because this would violate the principle that comparison operations should be consistent with equals, as explained on this page. The case of '0' and '00' is relevant for classical music, as there are two Bruckner symphonies with these designations.

3) It needs to be able to be combined with other features, such as the existing 'ignoreThe' capability, and also with any other custom sorting features that might be added in the future.

4) It needs to fit in with the existing design and implementation of MinimServer, without causing too much internal complexity in the code.

I am thinking about a possible approach that might satisfy all the above requirements. As usual with new features like this, I am reluctant to make any commitment that MinimServer will support the feature until I have prototyped a working implementation and convinced myself that it satisfies all the required criteria.

Another requirement that needs to be added is

5) The ability for the user to override numeric sorting for individual items where the number recognition algorithm would produce a sort order that isn't what the user wants.

This isn't as straightforward as it sounds. The user would expect to be able to do this override by adding an ALBUMSORT tag with the value of this tag being used to do an alphabetical comparison. The problem is that it isn't possible to mix numeric and alphabetic comparisons without violating the total ordering contract of the comparison operation: if a is less than b and b is less than c, then a must also be less than c.

To preserve total ordering, it would be necessary to either do numeric parsing of the ALBUMSORT value (which defeats the purpose of the manual override) or convert the parsed numeric values of all other items into equivalent sortable alphabetic values where the numbers are padded with some predetermined number of leading zeros (so 7 might become 00007 and 456 might become 00456). I don't think either of these approaches would be satisfactory.