Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.perl.misc > #8774

Re: names, values, boxes and microchips

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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