[32058] in Perl-Users-Digest
Perl-Users Digest, Issue: 3322 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Mar 16 03:09:25 2011
Date: Wed, 16 Mar 2011 00:09:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 16 Mar 2011 Volume: 11 Number: 3322
Today's topics:
Re: Autovivification <hjp-usenet2@hjp.at>
Re: Autovivification <uri@StemSystems.com>
Re: Autovivification <derykus@gmail.com>
Re: Autovivification <uri@StemSystems.com>
Re: convenient module to take statistics for hashed str <ela@yantai.org>
Re: going from CPAN to RPM <puiterl@notaimvalley.nl>
Re: going from CPAN to RPM <m@rtij.nl.invlalid>
Re: recursive Pythagorian triples <cartercc@gmail.com>
Re: recursive Pythagorian triples <hjp-usenet2@hjp.at>
Re: recursive Pythagorian triples <hjp-usenet2@hjp.at>
Re: recursive Pythagorian triples <sreservoir@gmail.com>
Re: recursive Pythagorian triples <sreservoir@gmail.com>
Re: recursive Pythagorian triples <ednotover@gmail.com>
Re: recursive Pythagorian triples <nospam.gravitalsun@hotmail.com.nospam>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 15 Mar 2011 23:15:50 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Autovivification
Message-Id: <slrninvp8m.702.hjp-usenet2@hrunkner.hjp.at>
On 2011-03-14 16:32, Uri Guttman <uri@StemSystems.com> wrote:
>>>>>> "PJH" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
>
> PJH> Otherwise there is no lvalue context in
>
> PJH> if ($x->[0][0]) { ... }
>
> the $x->[0] is the lvalue there.
We may use a different definition of "lvalue". I am using the definition
from the C standard:
| An lvalue is an expression with an object type or an incomplete type
| other than void;
[...]
| Except when it is the operand of the sizeof operator, the unary &
| operator, the ++ operator, the -- operator, or the left operand of the .
| operator or an assignment operator, an lvalue that does not have array
| type is converted to the value stored in the designated object (and is
| no longer an lvalue).
And apply to that Perl (which is of course a different language with
somewhat different concepts).
In $x->[0][0], without autovivification none of the exceptions above
apply to the subexpression $x->[0]. So $x->[0] is "converted to the
value stored in the designated object" (undef) "and is no longer an
lvalue".
Only with autovivification is there a implicit assignment to $x->[0]
which preserves the "lvalueness" of $x->[0]. But at this point your
argument becomes circular: This is an lvalue because of
autovivification. Autovivification is necessary because it is an lvalue.
> without autoviv, you can't ever check whether the next level has a
> [0].
You don't have to check. If $x->[0] is undef, there is no next level, so
it can't have a [0]. The whole expression could just return undef, no
need for autovivification.
> >> this is from perlref:
> >>
> >> This is one of the cases we mentioned earlier in which
> >> references could spring into existence when in an lvalue
> >> context.
>
> PJH> Note that "This" refers to:
>
> PJH> $array[$x]->{"foo"}->[0] = "January";
>
> PJH> which is an lvalue context (it is on the *l*eft side of an assignment).
>
>
> that is lvalue in two places. the {foo} and the [0] are both
> lvalues. the {foo} is implied and the [0] is explicit.
No, neither {foo} nor [0] are lvalues. $array[$x]->{"foo"} and
$array[$x]->{"foo"}->[0] may be lvalues (and so may $array[$x]).
This is different from the the previous example because there is an
assignment, so $array[$x]->{"foo"}->[0] is not converted from an lvalue
to an rvalue, so here we really have an lvalue even without
autovivification.
It is also different because to assign something to
$array[$x]->{"foo"}->[0] there must first be an anonymous array pointed
to by $array[$x]->{"foo"}, so here autovivification is actually
necessary to complete the assignment.
> >> autivivification happens when you must have a ref or the
> >> whole expression dies.
>
> PJH> Well, that's just the case for the first example. I don't have a ref and
> PJH> the whole expression dies. So you say that autovivification should
> PJH> happen in this case.
>
> not at the top level. that can be handled without autoviv. the middle
> levels are where it happens by implication even without assignment to
> the lowest level.
It's the same level in both cases. $x->[0] is the element which is
missing.
> PJH> (OTOH, there is no reason why $x->[0][0] (or @{ $x->[0] }) has to die:
> PJH> It could just return undef, just like an access to a non-existent array
> PJH> element returns undef)
>
> it DOES return undef. autoviv is a side effect of the access to the
> lowest level. perl can't tell the difference between
>
> $foo->{bar}[0] = 1 ;
>
> and
> if ( $foo->{bar}[0] )
>
> from the perspective of {bar}.
I know that it can't tell the difference. I argue that it should be able
to do that (it's not that difficult).
But this is a sideline. My orginal gripe was that the behaviour between
$x->[0][0] and @{ $x->[0] } was inconsistent (autovivification in one
case but not the other). If your argument is that this should be
different because Perl CAN tell the difference then I suspect that all
your arguments boil down to "it must be this way because it is so".
> PJH> No, that makes even less sense, because there is no intrinsic lvalue
> PJH> context. It probably does make sense if you look at it from a
> PJH> implementation POV ("it was simpler that way") or a historic POV
> PJH> (compatibility with pre-strict behaviour).
>
> this is what happens. it is documented (if poorly). middle level implied
> refs get autovivified.
Yes. I know what happens, and I know that it is documented. Please give
me a break. I didn't start using Perl (or posting to this group)
yesterday. I am arguing that your rationalizations of the behaviour
don't make sense. To repeat what I wrote above:
It probably does make sense if you look at it from a dimplementation POV
("it was simpler that way") or a historic POV d(compatibility with
pre-strict behaviour).
In other words I believe that the current inconsistent behaviour was not
the result of a concious decision but an accident of implementation.
hp
------------------------------
Date: Tue, 15 Mar 2011 23:15:21 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Autovivification
Message-Id: <87vczjoiwm.fsf@quad.sysarch.com>
>>>>> "PJH" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
PJH> On 2011-03-14 16:32, Uri Guttman <uri@StemSystems.com> wrote:
>>>>>>> "PJH" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
>>
PJH> Otherwise there is no lvalue context in
>>
PJH> if ($x->[0][0]) { ... }
>>
>> the $x->[0] is the lvalue there.
PJH> We may use a different definition of "lvalue". I am using the definition
PJH> from the C standard:
hmm, the lang in question is perl. perl and c are very
different. delving down into a deep tree of undef refs is legal in
perl. the equivilent in c does core dumps. slight difference there.
PJH> And apply to that Perl (which is of course a different language with
PJH> somewhat different concepts).
so why did you bring it up?
PJH> In $x->[0][0], without autovivification none of the exceptions above
PJH> apply to the subexpression $x->[0]. So $x->[0] is "converted to the
PJH> value stored in the designated object" (undef) "and is no longer an
PJH> lvalue".
i won't even dignify it. i deleted the c comment as it isn't perl. it is
irrelevent here. perl is different and dynamic langs in general do MANY
things that c doesn't do. would you want perl to also require to
readjust string, array and hash sizes by hand everytime that is needed?
PJH> Only with autovivification is there a implicit assignment to $x->[0]
PJH> which preserves the "lvalueness" of $x->[0]. But at this point your
PJH> argument becomes circular: This is an lvalue because of
PJH> autovivification. Autovivification is necessary because it is an lvalue.
nope. your defense is circularly recursive.
>> without autoviv, you can't ever check whether the next level has a
>> [0].
PJH> You don't have to check. If $x->[0] is undef, there is no next level, so
PJH> it can't have a [0]. The whole expression could just return undef, no
PJH> need for autovivification.
then how does this work:
my $foo ;
$foo->[0][0][0] = 1;
we are NOT assigning to $foo. yet it gets assigned an array ref. that is
autoviv at work. $foo is NOT a classical lvalue but an implied one. that
is all there is here. you are tilting at a windmill and it isn't going
to change. why you think this is wrong i cannot fathom. autoviv has been
in perl5 since it started. it is a key feature when dealing with data
structures. just drop this useless train of thought.
PJH> No, neither {foo} nor [0] are lvalues. $array[$x]->{"foo"} and
PJH> $array[$x]->{"foo"}->[0] may be lvalues (and so may $array[$x]).
NO. you don't get it. why you don't get it isn't clear so i can't fix
you. there are IMPLIED LVALUES. get it? implied. the intermediate levels
NEED refs to work. perl doesn't care if you are assigning to the lowest
level or reading it. ALL THE ABOVE LEVELS MUST HAVE REFS IN THEM. perl
just does that. that is what autoviv is about.
autoviv makes it EASY to build deep trees. have you ever seen newbie
code which doesn't use autoviv? it is full of crap like this:
if ( defined $foo->{bar} ) {
push @{$foo->{bar}}, $baz ;
}
else {
$foo->{bar} = [] ;
push @{$foo->{bar}}, $baz ;
}
$foo is NOT an explicit lvalue in any of that code. it is always an
implied one. so it gets assigned an array ref. this is simple shit.
over and out. i am not responding here anymore. you need to get over
this already. autoviv works fine. there may be one issue which is that
exists will also autoviv and some say it shouldn't. perl6 fixes that.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 15 Mar 2011 21:38:52 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Autovivification
Message-Id: <56efc92d-c5aa-46ed-b561-286ab6ca640e@i35g2000prd.googlegroups.com>
On Mar 15, 8:15=A0pm, "Uri Guttman" <u...@StemSystems.com> wrote:
> >>>>> "PJH" =3D=3D Peter J Holzer <hjp-usen...@hjp.at> writes:
> ...
But this issue still lurks:
PJH> But this is a sideline. My orginal gripe was
PJH> that the behaviour between $x->[0][0] and
PJH> @{ $x->[0] } was inconsistent (autovivification
PJH> in one case but not the other). If your argument
PJH> is that this should be different because Perl
PJH> CAN tell the difference then I suspect that all
PJH> your arguments boil down to "it must be this way
PJH> because it is so".
Even a slight simplification demo's the seeming
inconsistency:
perl -Mstrict -wle 'my $foo;print $foo->[0]'
vs.
perl -Mstrict -wle 'my $foo;print @{$foo->[0]}'
Can't use an undefined value as an ARRAY ref...
You might reasonably think that either both should
work or both should fail.
--
Charles DeRykus
------------------------------
Date: Wed, 16 Mar 2011 02:00:48 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Autovivification
Message-Id: <874o73ob8v.fsf@quad.sysarch.com>
>>>>> "CD" == C DeRykus <derykus@gmail.com> writes:
CD> On Mar 15, 8:15pm, "Uri Guttman" <u...@StemSystems.com> wrote:
>> >>>>> "PJH" == Peter J Holzer <hjp-usen...@hjp.at> writes:
>> ...
CD> But this issue still lurks:
PJH> But this is a sideline. My orginal gripe was
PJH> that the behaviour between $x->[0][0] and
PJH> @{ $x->[0] } was inconsistent (autovivification
PJH> in one case but not the other). If your argument
PJH> is that this should be different because Perl
PJH> CAN tell the difference then I suspect that all
PJH> your arguments boil down to "it must be this way
PJH> because it is so".
CD> Even a slight simplification demo's the seeming
CD> inconsistency:
CD> perl -Mstrict -wle 'my $foo;print $foo->[0]'
CD> vs.
CD> perl -Mstrict -wle 'my $foo;print @{$foo->[0]}'
CD> Can't use an undefined value as an ARRAY ref...
CD> You might reasonably think that either both should
CD> work or both should fail.
try dropping the strict and printing $foo
perl -wle 'my $foo;print @{$foo->[0]}; print "$foo\n"'
Use of uninitialized value in array dereference at -e line 1.
ARRAY(0x691df0)
so it did autoviv $foo. the warning/strict error was from the @{}
part. and that is correct. there is no inconsistancy here. autoviv is
when you have lvalue situations, explicit or implied. $foo->[0] part is
neither so it doesn't get autovivified. a single level dereference
doesn't get autovivified. you need depth or an lvalue.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Wed, 16 Mar 2011 12:23:10 -0700
From: "ela" <ela@yantai.org>
Subject: Re: convenient module to take statistics for hashed structures?
Message-Id: <ilpach$avs$1@ijustice.itsc.cuhk.edu.hk>
"George Mpouras" <nospam.gravitalsun@hotmail.com.nospam> wrote in message
news:ilnmka$2gnf$1@news.ntua.gr...
># The following version is much faster than the previous
Yes, your latest implementation works very fast, even for a million records!
> sub query {
> for (my $i=$#{$data{$_[0]}->[1]}; $i>=0; $i--) {
> return [$col[$i], $data{$_[0]}->[1]->[$i]->[1]->{$_[1]}] if exists
> $data{$_[0]}->[1]->[$i]->[1]->{$_[1]} }
> ['',[]]
> }
I wanna change your implementation from "discrete" checking to "continuous"
one, the logic is to first sort (rank keys: *** expected range: (0-100] ***)
numerically, then test if the "largest" key (e.g. 100, 75 etc) is larger
than the threshold specified. My problem is that I don't know how to refer
to the keys under
$data{$_[0]}->[1]->[$i]->[1]
Writing something like "foreach my $field (sort {$b<=>$a} keys
%data{$_[0]}->[1]->[$i]->[1])" (Thanks for McClellan's teaching on
appropriately using sort here) does not work. Moreover, there's no need to
"foreach" here as if the largest one also can't surpass the threshold,
neither the smaller ones can. So how to avoid "foreach" here?
------------------------------
Date: Tue, 15 Mar 2011 23:13:10 +0100
From: Paul Uiterlinden <puiterl@notaimvalley.nl>
Subject: Re: going from CPAN to RPM
Message-Id: <4d7fe476$0$41102$e4fe514c@news.xs4all.nl>
Art Werschulz wrote:
> Hi.
>
> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>
>> When I do a "rpm -ql $(rpm -qa perl-*) | grep /usr/lib/perl5 | less" I
>> see the modules about 50/50 using /usr/lib/perl/5.10.0/ and /usr/lib/
>> perl5/vendor_perl/5.10.0/. So that is not reliable.
>
> The command
> rpm -qa perl-*
> produces no results for me, but
You should protect the * from expansion by putting it in quotes or preceding
it with a back slash. As it is now, the result completely depends on the
contents of your current working directory. If by chance you have a file or
directory named 'perl-blah' in your current working directory, you will
only search for perl-bla.
So use:
rpm -qa 'perl-*'
--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.
------------------------------
Date: Tue, 15 Mar 2011 23:57:26 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: going from CPAN to RPM
Message-Id: <mf7558-63b.ln1@news.rtij.nl>
On Mon, 14 Mar 2011 08:18:47 -0400, Art Werschulz wrote:
> works okay. But at any rate
> rpm -ql `rpm -qa perl-*` | grep /usr/lib/perl5 | grep vendor_perl
> produces no output whatsoever.
Maybe they changed the packaging between F12 and F14, I get plenty of
output.
M4
------------------------------
Date: Tue, 15 Mar 2011 13:10:18 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: recursive Pythagorian triples
Message-Id: <c171792f-5579-4adf-ab92-261ea59d208d@22g2000prx.googlegroups.com>
On Mar 15, 2:49=A0pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> Not sure why you would want to do this,
Because of this, an Erlang program to find Pythagorian triples
recursively:
pythag(N) ->
[{A,B,C} ||
A <- seq(1,N),
B <- seq(1,N),
C <- seq(1,N),
A + B + C =3D< N,
(A * A) + (B * B) =3D:=3D C * C].
This says, given an integer N, for every permutation of A, B, and C
such that A+B+C is less than N, return A, B, C if the condition is
true.
I wondered if Perl could do the same in as few lines of code, taking
into account the function seq(N1,N2) which returns successive integers
from N1 to N2.
This isn't work related, as you might have guessed, but recreational.
CC.
------------------------------
Date: Tue, 15 Mar 2011 22:15:01 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: recursive Pythagorian triples
Message-Id: <slrninvlmm.702.hjp-usenet2@hrunkner.hjp.at>
On 2011-03-15 19:27, George Mpouras <nospam.gravitalsun@hotmail.com.nospam> wrote:
> Στις 15/3/2011 9:22 μμ, ο/η Peter J. Holzer έγραψε:
>> On 2011-03-15 18:34, George Mpouras<nospam.gravitalsun@hotmail.com.nospam> wrote:
>>> # This is pretty fast
>>>
>>> my $iterator=&BuildIterator;
>>>
>>> $iterator->(4);
>>>
>>> sub BuildIterator {
>>> return sub {
>>> for (my $i=1; $i<=$_[0]; $i++) {
>>> for (my $j=1; $j<$i; $j++) {
>>> print STDOUT join(',', ($i**2 - $j**2) , 2*$i*$j , ($i**2 + $j**2))."\n" }}}
>>> }
>>
>> But:
>>
>> * No recursion.
>>
>> * Doesn't print all pythogarean triples with a, b, c<= 100
>> (for example it doesn't print 6, 8, 10).
>>
>> * It isn't obvious that the tupels it produces are indeed pythogarean
>> triples (yes, the proof is simple, but you need to do it).
>>
>> * What's with the anonymous sub? That's completely unnecessary.
>
>
> Ah, the 6,8,10 is the second printed line !
Actually, 8,6,10 is the second printed line. I sorted the output to
check which triplets were missing, that's why the wrong order threw me
off.
It still doesn't print all the pythogarean triples with a, b, c <= 100.
So that brings us to a new problem:
For any value N, is there a value $x so that $iterator->($x) will
produce all pythogarean triples with a, b, c <= N?
There may be a simple proof for that but I admit that at the moment I
don't even have an idea how to start. So for me it is not a replacement
for Carter's program as I don't know which value to call $iterator with
to get all triples <= 100 (never mind that it will also print values >
100 before that).
hp
------------------------------
Date: Tue, 15 Mar 2011 22:16:54 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: recursive Pythagorian triples
Message-Id: <slrninvlq7.702.hjp-usenet2@hrunkner.hjp.at>
On 2011-03-15 19:24, George Mpouras <nospam.gravitalsun@hotmail.com.nospam> wrote:
> Στις 15/3/2011 9:22 μμ, ο/η Peter J. Holzer έγραψε:
>> * What's with the anonymous sub? That's completely unnecessary.
>>
>> hp
>
> Its beautiful !
It's ugly. It has extra code which serves no purpose.
hp
------------------------------
Date: Tue, 15 Mar 2011 20:10:26 -0400
From: sreservoir <sreservoir@gmail.com>
Subject: Re: recursive Pythagorian triples
Message-Id: <ilov62$9ib$1@news.eternal-september.org>
On 03/15/2011 02:34 PM, George Mpouras wrote:
> Στις 15/3/2011 7:58 μμ, ο/η Glenn Jackman έγραψε:
>> At 2011-03-15 01:30PM, "ccc31807" wrote:
>>> Pythagorian triples are integers that form the sides of a right
>>> triangle, e.g., 3, 4, 5. I've posted an iterative version below for
>>> all triples less than 100. I'm having trouble coming up with a
>>> recursive version. Any ideas?
>>>
>>> CC
>>>
>>> #! perl
>>> use strict;
>>> use warnings;
>>> print "Pythagorian triples\n\n";
>>>
>>> for(my $i = 1; $i< 101; $i++)
>>> {
>>> for(my $j = 1; $j< 101; $j++)
>>> {
>>> for(my $k = 1; $k< 101; $k++)
>>> {
>>> print "$i - $j - $k\n" if ($i * $i + $j * $j) == ($k * $k);
>>> }
>>> }
>>> }
>>> exit(0);
>>
>> Not recursive, but the RosettaCode site
>> (http://rosettacode.org/wiki/List_comprehensions#Perl)
>> has this implementation
>>
>> sub triples ($) {
>> my ($n) = @_;
>> map {
>> my $x = $_;
>> map {
>> my $y = $_;
>> map { [$x, $y, $_] }
>> grep { $x**2 + $y**2 == $_**2 } 1..$n
>> } 1..$n
>> } 1..$n;
>> }
>>
>>
>
>
> this is the same as OP
in the same way that 2+2 is the same as 2*2.
------------------------------
Date: Tue, 15 Mar 2011 20:12:32 -0400
From: sreservoir <sreservoir@gmail.com>
Subject: Re: recursive Pythagorian triples
Message-Id: <ilova0$9ib$2@news.eternal-september.org>
On 03/15/2011 04:10 PM, ccc31807 wrote:
> On Mar 15, 2:49 pm, "Peter J. Holzer"<hjp-usen...@hjp.at> wrote:
>> Not sure why you would want to do this,
>
> Because of this, an Erlang program to find Pythagorian triples
> recursively:
>
> pythag(N) ->
> [{A,B,C} ||
> A<- seq(1,N),
> B<- seq(1,N),
> C<- seq(1,N),
> A + B + C =< N,
> (A * A) + (B * B) =:= C * C].
that's not recursive. that's a list comprehension.
------------------------------
Date: Tue, 15 Mar 2011 19:53:09 -0700 (PDT)
From: Ed <ednotover@gmail.com>
Subject: Re: recursive Pythagorian triples
Message-Id: <952e0e0c-bea5-4f4f-8a98-0e5d9813c5b0@f31g2000pri.googlegroups.com>
On Mar 15, 5:15=C2=A0pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> On 2011-03-15 19:27, George Mpouras <nospam.gravital...@hotmail.com.nospa=
m> wrote:
>
>
>
> > =CE=A3=CF=84=CE=B9=CF=82 15/3/2011 9:22 =CE=BC=CE=BC, =CE=BF/=CE=B7 Pet=
er J. Holzer =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5:
> >> On 2011-03-15 18:34, George Mpouras<nospam.gravital...@hotmail.com.nos=
pam> =C2=A0wrote:
> >>> # This is pretty fast
>
> >>> my $iterator=3D&BuildIterator;
>
> >>> $iterator->(4);
>
> >>> sub BuildIterator {
> >>> return sub {
> >>> for (my $i=3D1; $i<=3D$_[0]; $i++) {
> >>> for (my $j=3D1; $j<$i; $j++) =C2=A0 =C2=A0 {
> >>> print STDOUT join(',', ($i**2 - $j**2) , 2*$i*$j , ($i**2 + $j**2))."=
\n" }}}
> >>> }
>
> >> But:
>
> >> =C2=A0 * No recursion.
>
> >> =C2=A0 * Doesn't print all pythogarean triples with a, b, c<=3D 100
> >> =C2=A0 =C2=A0 (for example it doesn't print 6, 8, 10).
>
> >> =C2=A0 * It isn't obvious that the tupels it produces are indeed pytho=
garean
> >> =C2=A0 =C2=A0 triples (yes, the proof is simple, but you need to do it=
).
>
> >> =C2=A0 * What's with the anonymous sub? That's completely unnecessary.
>
> > Ah, the 6,8,10 is the second printed line !
>
> Actually, 8,6,10 is the second printed line. I sorted the output to
> check which triplets were missing, that's why the wrong order threw me
> off.
>
> It still doesn't print all the pythogarean triples with a, b, c <=3D 100.
>
> So that brings us to a new problem:
>
> For any value N, is there a value $x so that $iterator->($x) will
> produce all pythogarean triples with a, b, c <=3D N?
>
> There may be a simple proof for that but I admit that at the moment I
> don't even have an idea how to start. So for me it is not a replacement
> for Carter's program as I don't know which value to call $iterator with
> to get all triples <=3D 100 (never mind that it will also print values >
> 100 before that).
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 hp
The code would need to iterate with a multiplier. See the brief
discussion here:
http://en.wikipedia.org/wiki/Pythagorean_triple#Generating_a_triple
Note that 6, 8, 10 would come from a doubling of m =3D 2, n =3D 1 (a =3D 3,
b =3D 4, c =3D 5). The code as written won't provide that triplet (in
that specific order). 8, 6, 10 comes directly from m =3D 3, n =3D 1.
Ed
------------------------------
Date: Wed, 16 Mar 2011 08:13:05 +0200
From: George Mpouras <nospam.gravitalsun@hotmail.com.nospam>
Subject: Re: recursive Pythagorian triples
Message-Id: <ilpkdh$2ac4$1@news.ntua.gr>
On 03/15/2011 11:15 PM, Peter J. Holzer wrote:
> On 2011-03-15 19:27, George Mpouras<nospam.gravitalsun@hotmail.com.nospam> wrote:
>> Στις 15/3/2011 9:22 μμ, ο/η Peter J. Holzer έγραψε:
>>> On 2011-03-15 18:34, George Mpouras<nospam.gravitalsun@hotmail.com.nospam> wrote:
>>>> # This is pretty fast
>>>>
>>>> my $iterator=&BuildIterator;
>>>>
>>>> $iterator->(4);
>>>>
>>>> sub BuildIterator {
>>>> return sub {
>>>> for (my $i=1; $i<=$_[0]; $i++) {
>>>> for (my $j=1; $j<$i; $j++) {
>>>> print STDOUT join(',', ($i**2 - $j**2) , 2*$i*$j , ($i**2 + $j**2))."\n" }}}
>>>> }
>>>
>>> But:
>>>
>>> * No recursion.
>>>
>>> * Doesn't print all pythogarean triples with a, b, c<= 100
>>> (for example it doesn't print 6, 8, 10).
>>>
>>> * It isn't obvious that the tupels it produces are indeed pythogarean
>>> triples (yes, the proof is simple, but you need to do it).
>>>
>>> * What's with the anonymous sub? That's completely unnecessary.
>>
>>
>> Ah, the 6,8,10 is the second printed line !
>
> Actually, 8,6,10 is the second printed line. I sorted the output to
> check which triplets were missing, that's why the wrong order threw me
> off.
>
> It still doesn't print all the pythogarean triples with a, b, c<= 100.
>
> So that brings us to a new problem:
>
> For any value N, is there a value $x so that $iterator->($x) will
> produce all pythogarean triples with a, b, c<= N?
>
> There may be a simple proof for that but I admit that at the moment I
> don't even have an idea how to start. So for me it is not a replacement
> for Carter's program as I don't know which value to call $iterator with
> to get all triples<= 100 (never mind that it will also print values>
> 100 before that).
>
> hp
Did you find any missing triplet ?
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3322
***************************************
