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

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

Re: names, values, boxes and microchips

Show all headers | View raw

Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
>> Ben Morrow <ben@morrow.me.uk> writes:

[...]

>>>     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:

I've used the catchup function of my newsreader to throw everything in
this group away since my less-than-reasoned two postings of
yesterday. While I've grown somewhat more accustomed to ordinary human
meanness, the umount of totally irrational[*] vitriolic rage some
people are capable of when being confronted with concepts alien to
them (such as using 'lexically scoped subroutines' with meaningful
names instead of duplicated code) is still a little bit too much for
me. But there are two points I'd like to clear up a little.

1. 'Bubblesort': This is not, in fact, the bubblesort algortihm but an
insertion sort variant, somewhat obscured by the need to work around
behaviour built into the 'part' subroutine which isn't really useful
for this case: It works by searching the place where the item on the
filter list had to be inserted into the other if it was to be
inserted. A somewhat less contorted implementation could look like
this (uncompiled/ tested) example:

my ($f, $i, $next, @out);

for $f (@$filter) {
	$next = [];
    
	for $i (@$in) {
	    	given ($i->net_compare($f)) {
	        	when (R_AFTER) {
	                	push(@out, $i);
			}

	                when ([R_BEFORE, R_SUB) {
	                	push(@$next, $i);
			}
	}

        $in = $next;
}

This is still rather bizarre, given that both input list are sorted
and free of items which are a subset of other items on the list,
because there's no reason to continue comparing $f with elements on
@$in after its place in the list has been found, ie, after a
comparison either returned '$f is in front of this' (R_BEFORE) or '$f
is a subset of this' (R_SUB) since the result of all remaining
invocations will be R_BEFORE. That's a direct result of the
unfortunate choice to use a general purpose 'partition a list' routine
for the inner loop: That's not quite what is really needed for an
insertion sort but 'clarity of the implementation be damned,
('clarity' in the sense that all operations which are part of the
algorithm are actually useful steps wrt accomplishing the desired
end) we can Cleverly(!) save two lines of code here' ...

This is really, seriously bad for writing something which can be
maintained by someone other than the original author because nobody
except him knows which parts of the implemented algortihm are
functional and which are accidental --- this will need to be
rediscovered by everyone who is tasked with making sense of this code
(which includes the original author after a sufficient amount of time
has passed).

2. __func__: That's a feature of C Perl unfortunately lacks, namely, a
'special expression' containing the name of the current
subroutine. This is useful for diagnostic messages because it enables
someone reading through the debug output to identify the code which
produces a particular 'diagnostics statement' more easily than by
grepping for the string. The equivalent Perl expression is

(caller(1))[3]

when invoked as an actual subroutine or

(caller(0))[3]

when the expression is 'inlined' instead. __func__ is defined as
subroutine,

sub __func__()
{
    return (caller(1))[3];
}

to make the perl compiler happy when being run for syntax/ strictness
checking and warnings alone and prior to installation (into a debian/
directory, actually), all code files are preprocessed via m4 -P using
an 'init file' containing

m4_define(`__func__',   `(caller(0))[3]')

m4_changequote(`', `')

because this code prints tenthousands of messages quickly for 'large'
installations (several thousand users) and they're necessary for
identifying and fixing errors in it.

[*] Eg, referring to use of an O(n) algorithm for merging two sorted
lists as 'pointless microoptimization which would be better
accomplished by using C instead of Perl' --- that's not 'an
optimization' aka 'attempt to cover the well after the
baby drowned' at all but the obvious 'textbook' choice.

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