-QM
--
Quantum Mechanics: The dreams stuff is made of
Was there an original ASCII committee? I think not. In fact, wikipedia says it wasn't designed by a standards committee.
I mean, even though C was standardized by a committee, but it was based mainly on K&R C (which is one reason why it became such a great language).
CountZero
"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law
Could have ordered the letters AaBbCc I guess then you could also write [A-z] in a regex. And expressing all uppercase letters would have been so painful to type out that everyone would be using [[:upper:]], which would make most code one step closer to internationalizable in trivial fashion at the cost of weird side effects in a minority of scripts
Makeshifts last the longest.
Yup... '@' befre '#' before '$' ...
It all makes sense after you do this:
#!/usr/bin/perl
use strict;
use warnings;
print "$_\n" for ( sort qw( a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
1 2 3 4 5 6 7 8 9 0
~ ! @ # $ % ^ & * ( ) _ +
` - = [ ] \ ; ' , . /
< > ? : " { } |
) );
And then look immediately at a keyboard. You'll be saying:
Yup...
---hA||ta----
print map{$_.' '}grep{/\w+/}@{[reverse(qw{Perl Code})]} or die while ( 'trying' );
Which came first, the keyboard layout chicken or the ASCII code order egg?
Makeshifts last the longest.
EBCDIC could have won the character code wars. In which case, a regexp such as /[A-Z]/ would include all sorts of unprintable characters...
emc
" When in doubt, use brute force." — Ken ThompsonIf you feel like having your mind blown, take a look at how UTF-EBCDIC works (yes, perl uses it).
Well... why do you think it matters? If you mean to sort numbers you ought to sort them numericaly not lexicaly anyway. Besides you most often do not include the + when writing positive numbers anyway.
I'm not concerned for Perl, but for the next process in the pipeline. It's a data analysis/plotting program I need to feed data to. Some of the plots have a string of numbers in various places, like "25,3,18". This means something if you know that the first field is temperature (25C), the second field is attempt 3, and 18 is the day of the month.
I thought of trying to feed strings instead of numbers, which this system happily accepts. For instance, temperature could be "T=25", and the whole label is more informative. If the label looked like "T=25,A=3,D=18", those with mathaphobia didn't waste precious time working out which is which.
But some of the data have negative values. So "T=-25" sorts after "T=+25". Then some fields have one, two, and three digit values, so "T=10" sorts before "T=5". This can be solved with "T=05". But negative values don't work because of "+" vs. "-".
So I thought of using "N" for negative and "P" for positive. "T=N5" sorts before "T=P5". But "T=N05" sorts before "T=N10"!
My latest thought is to use a sequence number to order the values, because there aren't that many in each field. "0T=-10", "1T=-5", "2T=0", "3T=+5", etc. Since all values are known ahead of time, this encoding can be used to get proper ordering, and field name hints.
Maybe in version 72, this software package will allow a better mechanism for labelling data...
-QM
--
Quantum Mechanics: The dreams stuff is made of
Prefix positive numbers with a 0 instead of a +.
Wont fix the sorting within negative numbers, of course.
Makeshifts last the longest.
If you follow your "T=25,A=3,D=18" form, you can sort numerically easily enough. Let's say you wanted the data in order from lowest to highest temperature, and your data is in @data, with each element being a string of the above form:
my @sorted_by_temp_asc = sort { tricky_sort($a,$b,'T') } @data;
sub tricky_sort {
my ($A, $B, $field) = @_;
my %a_dat = map { split('=', $_, 2) } split(',',$A);
my %b_dat = map { split('=', $_, 2) } split(',',$B);
return ( $a_dat{$field} <=> $b_dat{$field} );
}
The tricky_sort subroutine peforms a numerical comparison on the identified field, thus handling all the +/- sorting the way you want, and without too much twisted logic. Of course, you'll probably want to add more data validation and such before you put this into production -- after all <grail>it's only a model</grail> ;-)
And, it probably goes without saying, but to do a descending sort, just swap the order in which you pass $a and $b to tricky_sort
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet
If I had the choice of sorting it myself, it would be easy. Instead, I have to make the strings sort as numbers, by fudging the strings.
-QM
--
Quantum Mechanics: The dreams stuff is made of
I have a little utility module I use when I get annoyed by the default ASCII sort. Here it is:
This allows you to specify a subset of the default sorting order to "fix" for your own purposes. This particular example (sort + before -) could be "repaired" by:
The side-effects when making modifcations can be truly odd if you don't think carefully, so take care if using this module in production code. Here's a script that illustrates some of the ways I commonly use this utility:
package SortCustom;
my @d_ord = sort (map{ chr($_) } (0..255));
my %d_map = map { $d_ord[$_] => $_ } (0..$#d_ord);
sub csort {
my ($A,$B) = @_;
my $res = 0;
my $ndx = 0;
while ($ndx < length($A)) {
if (length($B) < $ndx) { $res = 1; last; }
my ($cA, $cB) = ( substr($A,$ndx,1) , substr($B,$ndx,1) );
$res = ($d_map{$cA} <=> $d_map{$cB});
last if $res != 0;
}
continue {
$ndx++;
}
return $res;
}
sub set_order {
my $key = \@_;
my @val = sort map { $d_map{$_} } @$key;
my ($low, $hi) = ($val[0], $val[-1]);
for (@$key) { $d_map{$_} = undef }
undef @d_ord;
for ( sort { $d_map{$a} <=> $d_map{$b} } keys %d_map ) {
next unless defined $d_map{$_};
if ( @d_ord < $low || !defined $key ) {
push @d_ord, $_;
}
else {
push @d_ord, @$key;
$key = undef;
}
}
%d_map = map { $d_ord[$_] => $_ } (0..$#d_ord);
}
1;
SortCustom::set_order('+','-');
@set = sort { csort($a,$b) } @set;
use strict;
use warnings;
use List::Util 'shuffle';
use SortCustom;
SortCustom::set_order( '-','+', map { $_, lc $_ } ('A'..'Z') );
my @values = shuffle( ('a'..'z','A'..'Z','+','-') );
my @nsort = sort @values;
my @csort = sort { SortCustom::csort($a,$b) } @values;
for (0..$#values) { printf "%s : %s\n", $nsort[$_], $csort[$_] }
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed [http://en.wikipedia.org/wiki/Trebuchet|trebuchet]
Thats a nice theory, except then the positive numbers will be missorted largest-to-smallest.
Makeshifts last the longest.
I was just pointing out (perhaps too indirectly) that its more complicated that merely getting "+" and "-" in the right order. The direction of sort is differnt for +ve and -ve numbers.