Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.perl.misc > #8774
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Newsgroups | comp.lang.perl.misc |
| Subject | Re: names, values, boxes and microchips |
| Date | 2013-07-20 15:02 +0100 |
| Message-ID | <87ehatpbx0.fsf@sapphire.mobileactivedefense.com> (permalink) |
| References | <87a9lmi67s.fsf@sapphire.mobileactivedefense.com> <jr4oba-g85.ln1@anubis.morrow.me.uk> <87bo5y5wtn.fsf@sapphire.mobileactivedefense.com> <874nbq5rqf.fsf@sapphire.mobileactivedefense.com> <hltoba-vq7.ln1@anubis.morrow.me.uk> |
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> > Ben Morrow <ben@morrow.me.uk> writes:
>> >>
>> >> There are times when it's necessary to write in that sort of state-
>> >> machine style, but it's always clearer to avoid it when you can.
>> >>
>> >> use List::MoreUtils qw/part/;
>> >>
>> >> my %rc = (
>> >> R_AFTER => 0,
>> >> R_SAME => 1,
>> >> R_SUPER => 1,
>> >> R_BEFORE => 2,
>> >> R_SUB => 2,
>> >> );
>> >>
>> >> sub filter_against {
>> >> my ($in, $filter) = @_;
>> >>
>> >> my @out;
>> >> for my $f (@$filter) {
>> >> (my $out, my $drop, $in) = part {
>> >> my ($rc) = $_->net_compare($f);
>> >> $rc{$rc} // die "bad return from net_compare";
>> >> } @$in;
>> >>
>> >> push @out, @$out;
>> >> p_alloc("%s: dropping %s (%s)", __func__, $_, $f)
>> >> for @$drop;
>> >> }
>> >>
>> >> return \@out;
>> >> }
>> >>
>> >> This does more compares than yours, but given small-lists-infrequently-
>> >> compared I doubt that matters.
>>
>> > But I'm not really in the mood to figure out if this
>> > hypercomplicated attempt at reverse dicksizing
>
> There's really no need to be rude.
Indeed. In particular, there was no need to ignore the reason why I
posted this example and produce this absolutely atrocious
demonstration that some people are really too clever for their own
good instead. That was not only rude but - as a sort of reverse
categorical imperative - it could be regarded as morally repellent as
well.
[...]
>> Possibly, there's an even worse way to perform what is essentially a
>> merge operation of two sorted lists but if the idea was to produce the
>> most inefficient implementation of this, the code above is certainly a
>> promising contender for the 'baddest of the worst' title.
>
> Who cares how efficient it is? You said yourself this is run
> infrequently over short lists; it's far more important that the
> algorithm be simple and the code be comprehensible than that it run as
> fast as possible.
There's no point in deliberately using algorithms which are badly
suited for certain task, especially when said 'badly suited'
algorithms rely on outright bizarre 'homegrown' abuses for
pre-existing functions instead of simple and well-known 'standard
operations' like merging to sorted lists. That's thoroughly
'undergraduate' stuff and one can expect people to be sufficently
familiar with that that they refrain from totally outlandish flights
of fancy of this kind.
In any case, if you feel like disputing the results of some sixty
years (probably) of research into elementary sorting algorithms based
on NIH and "But I don't care for that!" please write a
book. Suggestion for a suitable cover:
http://cheezburger.com/4354656256
Back to comp.lang.perl.misc | Previous | Next — Previous in thread | Next in thread | Find similar
names, values, boxes and microchips Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-16 21:45 +0100
Re: names, values, boxes and microchips Ben Morrow <ben@morrow.me.uk> - 2013-07-19 17:07 +0100
Re: names, values, boxes and microchips Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-19 17:38 +0100
Re: names, values, boxes and microchips Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-19 19:28 +0100
Re: names, values, boxes and microchips Ben Morrow <ben@morrow.me.uk> - 2013-07-20 00:11 +0100
Re: names, values, boxes and microchips Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-20 15:02 +0100
Re: names, values, boxes and microchips Ben Morrow <ben@morrow.me.uk> - 2013-07-20 16:45 +0100
Re: names, values, boxes and microchips Rainer Weikusat <rw@sapphire.mobileactivedefense.com> - 2013-07-21 11:15 +0100
Re: names, values, boxes and microchips gamo@telecable.es - 2013-07-21 12:47 +0000
Re: names, values, boxes and microchips Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2013-07-23 07:14 -0400
Re: names, values, boxes and microchips gamo@telecable.es - 2013-07-23 20:43 +0000
Re: names, values, boxes and microchips Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-24 11:23 +0100
Re: names, values, boxes and microchips Ben Morrow <ben@morrow.me.uk> - 2013-07-23 23:10 +0100
Re: names, values, boxes and microchips Ben Morrow <ben@morrow.me.uk> - 2013-07-21 18:01 +0100
Re: names, values, boxes and microchips Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-21 20:53 +0100
Re: names, values, boxes and microchips Ben Morrow <ben@morrow.me.uk> - 2013-07-21 22:51 +0100
Re: names, values, boxes and microchips Charles DeRykus <derykus@gmail.com> - 2013-07-21 16:29 -0700
Re: names, values, boxes and microchips Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-22 01:20 +0100
Re: names, values, boxes and microchips Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-22 01:06 +0100
[OT] naming conventions Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-22 10:35 +0100
csiph-web