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

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

Re: names, values, boxes and microchips

Show all headers | View raw

Rainer Weikusat <rweikusat@mssgmbh.com> writes:

> Ben Morrow <ben@morrow.me.uk> writes:
>> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>
> [...]
>
>>> sub filter_against
>
> [...]
>
>> 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

[...]

> is semantically equivalent to the fairly straight-forward list merge
> based algorithm I'm using.

I've nevertheless been curious enough that I spend some time thinking
about this while walking back to my flat after a trip to the
supermarket: Provided I understand this correctly, this is basically
the bubblesort algorithm: It compares each element of the filter list
to all elements on the input list in turn, moving the input elements
which are in front of the current filter item to a temporary output
list and the others onto the input list for the next iteration. It
then does a 2nd pass through the temporary output list in order to
move the elements on there to the real output list and a second pass
through the 'drop' list in order to print the tracing
information. These two fixup steps are necessary because the 'part'
routine is really totally unsuitable for this particular task because
it always creates a bunch of new anonymous arrays to store its output.

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.

"It must 're-use' code someone else already wrote" is not a sensible,
overriding concern for creating software

Joke I invented a while ago: Imagine software companies would be
constructing lorries, how would these look like?

Version 1: Like a regular lorry except that the wheels aren't round
but elliptical because the ellipsoids were left-over from a previous
project.

Version 1.5: Like a lorry with elliptical wheels but it has an
additional jet engine on the back to achieve Superior(!) speed when
compared with the lorries built by competitors using round wheels.

Version 2: Comes with an advanced AI auxiliary steering system
supposed to enable smooth movement despite the combined effects of the
jet engine and the elliptical wheels.

And so forth. The only thing which is never going to happen is that
someone goes back to step one and redesigns the autobody to
accommodate round wheels.

Back to comp.lang.perl.misc | Previous | Next — Previous 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