Re: how to recursion

[PYH]

I asked this just b/c I want to do matrix calculation in perl.
I found under some conditions a recursion is more effective.

Thanks everybody.

On 2017/3/29 23:31, Chas. Owens wrote:

On Tue, Mar 28, 2017 at 9:27 PM PYH > wrote:

Hi,

what's the better way to write a recursion in perl's class?

sub my_recursion {
 my $self = shift;
 
 if (...) {
 $self->my_recursion;
 }
}

this one?


Define better. In general that is the right form (assuming there is some
side effect to calling my_recursion that will cause the if statement to
be false).  If your function is tail recursive and it has the potential
to be deeply nested, then you can take advantage of a quirk of goto to
make it faster and use less memory:

#!/usr/bin/perl

use strict;
use warnings;

{ package A;
sub new { bless {}, shift }

sub recur {
my ($self, $n) = @_;

return "recur done" if $n <= 0;
return $self->recur($n - 1);
}

sub tail_recur {
my ($self, $n) = @_;

return "tail_recur done" if $n <= 0;
@_ = ($self, $n - 1);
goto _recur;
}
}

my $o = A->new;

print $o->recur(1_000_000), "\n";
print $o->tail_recur(1_000_000), "\n";

NOTE: this only works if the code is tail recursive.  That is, the
recursive function does nothing but return the next call's return
value.  It works by replacing the function with itself rather than
pushing another copy of the function on the stack.



--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Perl Critic and subroutine signatures

[SSC_perl]

> On Mar 29, 2017, at 3:47 PM, Kevin Phair  wrote:
> 
> Something like
> 
> [-Subroutines::ProhibitSubroutinePrototypes]

Thanks.  I ran across that myself on perlmaven.com right before I went 
to lunch.  I was hoping to find a page on CPAN or even the Perl Critic web site 
that would list all the exceptions, but unless I just don’t know where to look, 
it’s simply not available.  Now watch - someone will find that list and prove 
me wrong. ;)

——

O.K., if you install P::C on your own machine, you can run:

perlcritic -list

to get a list of them.

Also, some good news.  It looks like P::C is now under new management, 
so we’ll probably be seeing an update before too much longer.

https://github.com/Perl-Critic/Perl-Critic/issues/713

Frank
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Perl Critic and subroutine signatures

[Kevin Phair]

Something like

[-Subroutines::ProhibitSubroutinePrototypes]

in your .perlcriticrc should do the trick.

You can also do it inline with something like

## no critic (Subroutines::ProhibitSubroutinePrototypes)
sub subname ( ... ) {
## use critic

On Wed, Mar 29, 2017 at 1:16 PM, SSC_perl  wrote:

> Does anyone know how to keep Perl Critic from complaining about subroutine
> signatures?  I’m getting a massive amount of these types of warnings:
>
> Subroutine prototypes used at line...
>
> It also thinks that postfix dereferencing is a magic variable.  Is this
> because PC hasn’t been updated for a couple years, or is there an add-on
> that takes care of these situations?
>
> Thanks,
> Frank
>

Re: Perl Critic and subroutine signatures

[Uri Guttman]

On 03/29/2017 01:32 PM, SSC_perl wrote:
On Mar 29, 2017, at 10:19 AM, Uri Guttman > wrote:


i would ask why are you using prototypes?


I’m not using prototypes.  I’m using subroutine signatures.  Perl 
Critic only thinks they are prototypes.
ok, i just got that. perl critic has ways to shut down any of its 
warnings. look for prototype warnings and you can disable them. as you 
said, it needs to be updated to handle signatures.


uri

Fw: how to recursion

[Shlomi Fish]

Forwarding to the list.

Begin forwarded message:

Date: Wed, 29 Mar 2017 11:32:08 -0400
From: Shawn H Corey 
To: Shlomi Fish 
Subject: Re: how to recursion


On Wed, 29 Mar 2017 17:22:36 +0300
Shlomi Fish  wrote:

> my_recursion accepts $self as its first argument, so you should pass
> it there. Doing «my_recursion($self);» is one option for doing that
> but : 1. It looks ugly. 2. It's less future proof. 3. It's a bad
> practice for OOP perl.
> 
> The original code was fine.  

Oops, you're right. the OOLs I've been using lately take care self (or
this) automatically. I had forgotten that Perl is an OO toolkit, not an
OOL. ☺


-- 
Don't stop where the ink does.

Shawn H Corey

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Perl Critic and subroutine signatures

[SSC_perl]

> On Mar 29, 2017, at 10:19 AM, Uri Guttman  wrote:
> 
> i would ask why are you using prototypes?

I’m not using prototypes.  I’m using subroutine signatures.  Perl 
Critic only thinks they are prototypes.

Re: Perl Critic and subroutine signatures

[Uri Guttman]

On 03/29/2017 01:16 PM, SSC_perl wrote:
Does anyone know how to keep Perl Critic from complaining about 
subroutine signatures?  I’m getting a massive amount of these types of 
warnings:


Subroutine prototypes used at line...



i would ask why are you using prototypes? they are rarely useful 
(especially as arg checkers). the primary good use is changing how a sub 
is parsed when called (unary, taking a block arg, etc).


uri

Perl Critic and subroutine signatures

[SSC_perl]

Does anyone know how to keep Perl Critic from complaining about 
subroutine signatures?  I’m getting a massive amount of these types of warnings:

Subroutine prototypes used at line...

It also thinks that postfix dereferencing is a magic variable.  Is this 
because PC hasn’t been updated for a couple years, or is there an add-on that 
takes care of these situations?

Thanks,
Frank

Re: Equivalents statements using if and unless

[SSC_perl]

> On Mar 28, 2017, at 1:58 PM, Uri Guttman  wrote:
> 
> the only difference i see is using defined in the 2nd line.

Thanks, Uri.  Yeah, I got overly aggressive there.

> also i would test $field ne 'categories' first as if that is true why even 
> test $out->{$field}? it is a slight optimization but may also clarify the 
> logic.

And thanks for this, too.  That makes sense.  I’m looking at all lines 
of logic now to see if they can be optimized.

Frank
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: how to recursion

[Chas. Owens]

On Tue, Mar 28, 2017 at 9:27 PM PYH  wrote:

> Hi,
>
> what's the better way to write a recursion in perl's class?
>
> sub my_recursion {
>  my $self = shift;
>  
>  if (...) {
>  $self->my_recursion;
>  }
> }
>
> this one?
>

Define better. In general that is the right form (assuming there is some
side effect to calling my_recursion that will cause the if statement to be
false).  If your function is tail recursive and it has the potential to be
deeply nested, then you can take advantage of a quirk of goto to make it
faster and use less memory:

#!/usr/bin/perl

use strict;
use warnings;

{ package A;
sub new { bless {}, shift }

sub recur {
my ($self, $n) = @_;

return "recur done" if $n <= 0;
return $self->recur($n - 1);
}

sub tail_recur {
my ($self, $n) = @_;

return "tail_recur done" if $n <= 0;
@_ = ($self, $n - 1);
goto _recur;
}
}

my $o = A->new;

print $o->recur(1_000_000), "\n";
print $o->tail_recur(1_000_000), "\n";

NOTE: this only works if the code is tail recursive.  That is, the
recursive function does nothing but return the next call's return value.
It works by replacing the function with itself rather than pushing another
copy of the function on the stack.

Re: how to recursion

[Shlomi Fish]

Hi Shawn!

On Wed, 29 Mar 2017 08:09:12 -0400
Shawn H Corey  wrote:

> On Wed, 29 Mar 2017 09:25:06 +0800
> PYH  wrote:
> 
> > sub my_recursion {
> >  my $self = shift;
> >  
> >  if (...) {
> >  $self->my_recursion;  
> 
> # you don't need $self. subroutine lookup starts
> # in the same package. Just the sub by itself
> # is good enough.
> my_recursion();
> 

my_recursion accepts $self as its first argument, so you should pass it there.
Doing «my_recursion($self);» is one option for doing that but : 1. It looks
ugly. 2. It's less future proof. 3. It's a bad practice for OOP perl.

The original code was fine.

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: how to recursion

[Shawn H Corey]

On Wed, 29 Mar 2017 09:25:06 +0800
PYH  wrote:

> sub my_recursion {
>  my $self = shift;
>  
>  if (...) {
>  $self->my_recursion;

# you don't need $self. subroutine lookup starts
# in the same package. Just the sub by itself
# is good enough.
my_recursion();

>  }
> }

More thoughts on recursion:
https://lookatperl.blogspot.ca/2012/11/a-look-at-recursion.html


-- 
Don't stop where the ink does.

Shawn H Corey

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Equivalents statements using if and unless

[Илья Рассадин]

Hi!

First of all, using unless with complex logic inside the condition, 
especially using negatives (unless not...) is much harder to read and 
understand than using if.


See http://stackoverflow.com/a/3048787 and of course see original adwise 
from Conway's perl best practices 
http://shop.oreilly.com/product/9780596001735.do


So unless is bad choice in your case, i adwise to use if.

Second, contitions if (defined $var) and unless (not $var) are not the 
same, for example


use feature qw/say/;

my $var = 0;

if (defined $var) { say q[i'm in if]; }

unless (not $var) { say q[i'm in unless]; }


will print

i'm in if



28.03.17 23:58, Uri Guttman пишет:

On 03/28/2017 04:46 PM, SSC_perl wrote:
I could use another set of eyes on this.  Could someone please 
double check these two sets of conditions and let me know if the 
first is equivalent to the second?  I believe they are, but I don’t 
want to take any chances.



# Both of these should be equivalent.
$out->{$field} =~ s/``/\r/g unless (not $out->{$field} or $field eq 
'categories');
$out->{$field} =~ s/``/\r/g if (defined $out->{$field} && $field ne 
'categories');


google for demorgan's theorem. you should know it if you deal with 
complex boolean logic.


the only difference i see is using defined in the 2nd line.

also i would test $field ne 'categories' first as if that is true why 
even test $out->{$field}? it is a slight optimization but may also 
clarify the logic.


$out->{$field} =~ s/``/\r/g if $field ne 'categories' && 
$out->{$field} ;


no need for the () on statement modifiers so i removed them. i also 
didn't use defined as any value other than 0, '' or undef will be true 
and worth running the s///.


uri




--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/