Re: SortBy + Sort Strings with apo.marks + CharacterCode
- To: mathgroup at smc.vnet.net
- Subject: [mg118608] Re: SortBy + Sort Strings with apo.marks + CharacterCode
- From: "Dr Andy D Kucar P2EE4 www.radio4u.com" <andy at radio4u.com>
- Date: Wed, 4 May 2011 06:34:45 -0400 (EDT)
Thank you for your consideration.
In diverse multi disciplinary multi lingual environments
Ones have to produce diverse
{List, Index, Bibliography, Dictionary} items according to
diverse (publishing format, TeX; ASCII, ISO, UTF, MW, PS, HTML ... encoding) requirements,
sorting, collating, linguistic rules, etc.
Having some (additional) options (flexibilities) within say Sort[] command would be of great help.
Thank you
Sincerely, Andy
-----Original Message-----
From: Daniel Lichtblau [mailto:danl at wolfram.com]
Sent: Thursday, April 21, 2011 02:10
To: mathgroup at smc.vnet.net
Subject: [mg118608] [mg118304] Re: SortBy + Sort Strings with apo.marks + CharacterCode
ceo_www.radio4u.com wrote:
> Gentlemen,
>
> Thank you for your answers and help.
> In this email, I'll try to answer the issues raised in the email below,
> and explain further my points.
>
> -----Original Message-----
> From: DrMajorBob [mailto:btreat1 at austin.rr.com]
> Sent: Monday, April 18, 2011 05:50
> To: mathgroup at smc.vnet.net
> Subject: [mg118291] [mg118257] Re: SortBy + Sort Strings with apo.marks + CharacterCode
> #1>#2& makes no sense for Strings, because one string is not greater (or
> less) than another.
> Sort[
> Within the Sort environment, > may be understood as a cardinality Order, CharacterCode number, etc.
> Thus stating "a"<"b" may mean: the letter (character) "a" has smaller CharacterCode number than the character "b",
> "April"< "May" is "sort wise" True, because "A"<"M", or,
> Order["April", "May"]
> 1
> or
> Sort[{"May", "April"}]
> {"April", "May"}
>
> different forms (the first "a"<"b" is NOT implemented, the other two are) for the same meaning, etc.
> Sort[ ] does a good job sorting Strings (and Numbers), according to its own rules.
>
> Sort[{345, "2", 1, "0", "("}] evaluates (and sorts) two different classes: Numbers and Strings
> {1, 345, "(", "0", "2"} any Number precedes a String, Number<String, etc.
>
> One of my programs processes a large input matrix of up to 16 Columns x thousands of Rows,
> The first Column consists of Strings; other Columns being mostly numbers;
> Sort[ ] does it easily (details may come later).
>
> However, new requirements (and new inputs) may require some flexibilities (modifications) of existing Sorting rules.
> This is what I want to discus, ask, put on my wish list for next M.versions
> ]
>
>
> How is "abcccdde ..." a sorting rule?
> The true meaning has been lost in the translation (.nb > .doc > .txt plain text)
> It should read
> abc=E7\[CHacek]\[CAcute]d {d z\&\[Hacek]} =D0e ...
>
> this is a very interesting (possibly messy) subject,
> which may be addressed later.
>
>
> "b- d-(d) h- characters ?" is just incomprehensible.
> In addition to an existing alphabet (more precisely abecedarium, since there is NO Greek (Cadmos, Akkad) letters
alpha,
> beta, yet),
> One may need/wish to introduce her/his own glyphs/symbols/characters, like
> =D0 (D-), d-, b-, h- == \hbar (Planck constant), etc., anything, and be able to place it/them to an appropriate place
in
> the computer memory,
> i.e., assign to them an appropriate CharacterCode, to facilitate a correct Sort[ing]
>
> How to do it?
> Sincerely Andy
This is really jumbled. Ironically, some non-English characters seem to
have been translated in a way that does not play nice with all email
clients.
I think what you are requesting is that Greater et al handle strings via
some ordering based on lexicography. Note also that there are other ways
to order strings, e.g. based on length followed by lexicography. Ald
there would be serious issues with handling of non-alphanumeric
characters, as well as room for dispute as to whether numerals precede
or follow letters.
I look upon this as I would any other can of wriggling fish bait. In any
case, we have no intention of changing or extending inequalities outside
the numeric realm.
Daniel Lichtblau
WOlfram Research