in reply to Understanding transformation sorts (ST, GRT), the details

I agree with merlyn that it's better to try to grok the ST before the GRT, which, after all, is a special case of the ST. I'm not sure that the ST is always clearer, however.

Interesting that the example of sorting IP addresses is used here, because that was the original scenario in which the GRT was first explored (by Michal Rutka, Uri Guttman, Larry Rosler and myself). We could probably say that it is a canonical example: The data itself is very simple, the string representation cannot be (usefully) used for sorting, and the transformation to and from a meaningfully sortable representation is trivial.

@ips = # note: this converts any "unusual" reps to dotted-quad map { inet_ntoa $_ } sort map { inet_aton $_ } @ips;
Or, to sort lines which have IPs embedded:
@ips = map { substr $_, 4 } sort map { /(\d[.\d]+\d)/; inet_aton($1) . $_ } @ips;

As you can see, this is no less clear than the equivalent ST. The maps are arguably simpler; and of course the sort is more trivial, since that's always the case.

But sorting IPs is something of a special case. In general, one would probably have to resort to either pack or sprintf to generate the sortable string.

Replies are listed 'Best First'.
Re^2: Understanding transformation sorts (ST, GRT), the details
by merlyn (Sage) on May 18, 2005 at 14:08 UTC
      I'm assuming well-formed input. If there's non-conformant data in the input, it would be better to have already detected and handled it.