Is there one different way to order data ?

[Manfred Henning]

Hello !

i wanted to display one birthday list of our employes.
The database field is one date field (like 31.12.1998)
I split the date in day, month and year.
i create after the spliting one query, to show me the people, that had
birthday in the last 7 days.

Now, i wanted to order the raws. I want to have as the 1st position, the
person with the youngest day and month. (not year!)
Just to order the string in the SQL query, is not enough - if i do it like
this, i get the youngest people at the first line (because the order
criterium in the database, reads also the year...)

Every idea is welcome !
Thanks,
Manfred

[dr...@copyright.com]

In article <36146...@news.zeitung-online.net>,

Just to sort the dates by month and day, you could use something similar to
an algorithm recently discussed in a thread on sorting by IP address:

@birthdays_sorted = sort {
pack("C2",reverse split(/\./,$a)) cmp pack("C2",reverse split(/\./,$b))
} @birthdays;

Or using the ever-popular Schwartzian Transform to do those packs and unpacks
only once per birthday:

@birthdays_sorted =
map { $_->[0] }
sort { $a->[1] cmp $b->[1] }
map { [$_, pack("C2",reverse split(/\./,$_))] }
@birthdays;

But if you want to do date arithmetic (i.e., birthdays in the last seven
days), you really need a Julian date computation. I suspect the Date::Manip
module available on CPAN would be useful for this, and you might find there
something that will help you solve both problems.

Or you can roll your Julian date routine for use in the comparison and in the
sort, using the localtime function built into Perl and the timelocal function
in the Time::Local module that is bundled in the core set of things that come
with Perl.

--
Don Roby

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

[John Porter]

I've recently been benchmarking the relative performance of
the Schwartzian Transform (ST) (aka. map-sort-map) vs.
the Orcish Maneuver (say "OR-cache").

I recently posted some results that indicate that ST is
more than an order of magnitude slower than OM.
However, those tests were not quite realistic, in that they
discarded the results of the operation. Apparently Perl can
optimize for this, under the right conditions. What follows
is a benchmark wherein the results are not discarded.

#!/usr/local/bin/perl -w
use Benchmark;

# read 3100 7-letter words. shuffle them.
my $file = 'words.7';
open F, $file or die "open $file: $!\n";
my @in = shuffle( <F> ); chomp @in; close F;
my @out;

sub control { # explicit comparison
@out = sort { $a cmp $b } @in
}

sub control0 { # default comparison
@out = sort @in
}

sub ST {
@out =

map { $_->[0] }
sort { $a->[1] cmp $b->[1] }

map { [ $_, $_ ] }
@in;
}

sub OM {
my %c = (); # the cache
@out = sort { ($c{$a} ||= $a) cmp ($c{$b} ||= $b) } @in;
}

timethese( 10, {
'ST' => \&ST,
'OM' => \&OM,
'ct' => \&control,
'c0' => \&control0,
} );

sub shuffle { # the usual Fisher-Yates shuffle.
my @i = @_;
for my $i ( reverse ( 0 .. $#i ) ) {
my $j = int( rand( $i ));
@i[$i,$j] = @i[$j,$i];
}
@i;
}

Benchmark: timing 10 iterations of OM, ST, c0, ct...
OM: 33 secs (32.51 usr 0.05 sys = 32.56 cpu)
ST: 30 secs (29.70 usr 0.09 sys = 29.79 cpu)
c0: 2 secs ( 2.52 usr 0.00 sys = 2.52 cpu)
ct: 12 secs (11.48 usr 0.00 sys = 11.48 cpu)

In these tests, I am trying to compare the underlying
algorithms of ST and OM. Therefore, the compare keys
are identical to the original strings, rather than
adding the overhead of computing some other comparison
keys.
Note how using an explicit {$a cmp $b} adds an order
of magnitude overhead. Perl clearly optimizes for
the default sort (the implicit {$a cmp $b}).

--
John "Many Jars" Porter

[John Porter]

John Porter wrote:
>
> Benchmark: timing 10 iterations of OM, ST, c0, ct...
> OM: 33 secs (32.51 usr 0.05 sys = 32.56 cpu)
> ST: 30 secs (29.70 usr 0.09 sys = 29.79 cpu)
> c0: 2 secs ( 2.52 usr 0.00 sys = 2.52 cpu)
> ct: 12 secs (11.48 usr 0.00 sys = 11.48 cpu)

And I forgot to mention:

SunOS 5.4 generic sun4m sparc
perl 5.004_04

--
John "Many Jars" Porter

baby mother hospital scissors creature judgment butcher engineer

[Larry Rosler]

[Posted to comp.lang.perl.misc and a copy mailed.]

In article <3614F674...@min.net> on Fri, 02 Oct 1998 11:51:16 -
0400, John Porter <jdpo...@min.net> says...

> I've recently been benchmarking the relative performance of
> the Schwartzian Transform (ST) (aka. map-sort-map) vs.
> the Orcish Maneuver (say "OR-cache").
>
> I recently posted some results that indicate that ST is
> more than an order of magnitude slower than OM.
> However, those tests were not quite realistic, in that they
> discarded the results of the operation. Apparently Perl can
> optimize for this, under the right conditions. What follows
> is a benchmark wherein the results are not discarded.

...

> Benchmark: timing 10 iterations of OM, ST, c0, ct...
> OM: 33 secs (32.51 usr 0.05 sys = 32.56 cpu)
> ST: 30 secs (29.70 usr 0.09 sys = 29.79 cpu)
> c0: 2 secs ( 2.52 usr 0.00 sys = 2.52 cpu)
> ct: 12 secs (11.48 usr 0.00 sys = 11.48 cpu)

It's good that you got this straightened out, because the first results
you posted were troubling. OM runs slower than ST because an extra test
is needed (for TRUE) every time a comparison value is used.

It's perhaps worth pointing out that when any of the comparison values
computes to FALSE, OR will run even more slowly than ST, because the
FALSE value will be recomputed and stored every time the comparison value
is needed.

So, while OR is nice for such things as setting defaults:

$value ||= $default_value;

it is dominated in sort comparisons by ST.

--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
l...@hpl.hp.com

[dr...@copyright.com]

In article <6v2j6v$1ue$1...@nnrp1.dejanews.com>,

dr...@copyright.com wrote:
>
> But if you want to do date arithmetic (i.e., birthdays in the last seven
> days), you really need a Julian date computation. I suspect the Date::Manip
> module available on CPAN would be useful for this, and you might find there
> something that will help you solve both problems.
>
> Or you can roll your Julian date routine for use in the comparison and in the
> sort, using the localtime function built into Perl and the timelocal function
> in the Time::Local module that is bundled in the core set of things that come
> with Perl.
>

Roby, you twit, you've rephrased someone's question as a FAQ and then answered
it incorrectly!

Slap, slap, slap!

Perfaq4 tells us:

How can I find the Julian Day?

Neither Date::Manip nor Date::DateCalc deal with Julian days. Instead, there
is an example of Julian date calculation in
http://www.perl.com/CPAN/authors/David_Muir_Sharnoff/modules/Time/JulianDay.p
m.gz, which should help.

Curiously, I could not find that file. This author's Time modules seem to
have been rearranged since that was written.

However, I think the example referenced is in the file
http://www.perl.com/CPAN/authors/David_Muir_Sharnoff/modules/Time-modules-98.
081201.tar.gz