From: Chris Jacobs (email@example.com)
Date: Tue Nov 11 2003 - 15:01:37 EST
(1) I distinguish between different kinds of digit 5 even within the same
radix 10 most-significant first positional digit 5 (examples: 5, ٥)
radix 10 units digit 5 (example: ה )
radix 10 tens digit 5 (example נ )
How would the natural sort algorithm handle fractions? Does 123,456 come
before or after 123.456 ?
(3) I don't expect natural sorting to sort in numeric value but if it
is modified to do that anyway then I certainly don't want it to stop doing
that without warning when the format of the numers becomes complicated.
----- Original Message -----
From: Jill Ramonsky
Sent: Tuesday, November 11, 2003 9:58 AM
Subject: RE: Hexadecimal digits?
Look, for one thing I mentioned natural sort of an EXAMPLE of how I think
the digits ten to fifteen should be treated identically to the digits zero
to nine, not the raison d'etre. But could anyone else who wishes to post on
this subject (natural sort) please CONSIDER whether you've actually
understood the subject before posting either strawman arguments or just
plain nonsense. The following are FACTS. As in, mathematical facts. As in, I
can prove them, and so can you, and we will all reach identical conclusions
provided that each step follows logically from the previous ones. Note these
(1) A digit is a digit is a digit. There is no difference between a radix-8
five, a radix-10 five and a radix-16 five. In all cases, the digit is 5.
This is the same digit which you find in radix-6, radix-93 or radix-7654321.
Anyone who suggests there is ANY rationale for having a separate set of
digits for each radix is just plain wrong, and, I would suggest, not a
(2) The natural sort algorithm works identically in all radices. There is
nothing special about radix ten. Furthermore, the same sort order is
guaranteed in all radices. An implementation of a natural sort algorithm
does NOT need to "know" the radix. It does not need to guess. It does not
need to assume. It does not need to infer. It does not even need to care.
All it needs are the functions IsDigit(codepoint) and
GetDigitValue(codepoint). The return value of the latter is only required to
be defined if the return value of the former is true. That's ALL it needs.
(3) Nobody in their right mind would even consider that mixed radices need
to sort in numerical order. Such a thing is absurd. Jim Allen (below) said
"If you want a natural sort using a mixed alpha and numeric string which may
use multiple bases...". Well note the word "if" in that sentence, because it
is very pertinent. *I DON'T*. In fact, NOBODY on this list has proposed that
multiple radices should be intermixable. SO WHAT if one thousand nine
hundred and eleven (777 hex) is greater than nine hundred and ninety nine?
That does NOT mean that "File777" should sort before "File999". In fact,
Nobody, and I stress this because it's starting to annoy me, *NOBODY* on
this thread has supported the use of mixed bases. Certainly not I.
Therefore, anyone who argues against it, is arguing against something which
nobody has proposed. And that seems about as good a definition of "waste of
time" as I can think of.. It is most certainly not an argument against
anything I've said, as I am in complete agreement with the notion that it's
a totally dumb and stupid idea. It's a strawman argument, and it's
sidetracking away from the original issue of whether or not there should
exist Unicode characters for which IsDigit() returns true and for which
GetDigitValue() returns values in the range ten to fifteen.
And finally, please note, Mr Allen, my name is Jill, not Jim. I think you'll
find that in fact _your_ name is Jim, though I can see why that might be
PS. This thread has been and interesting experience. If I do write a letter
of support, do I really have to go to such extremes to point out what I'm
NOT supporting? It would seem so.
This archive was generated by hypermail 2.1.5 : Tue Nov 11 2003 - 16:04:21 EST