[32028] in Perl-Users-Digest
Perl-Users Digest, Issue: 3292 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Feb 20 14:09:34 2011
Date: Sun, 20 Feb 2011 11:09:15 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 20 Feb 2011 Volume: 11 Number: 3292
Today's topics:
arithmetic persistence <marc.girod@gmail.com>
Re: arithmetic persistence <willem@turtle.stack.nl>
Re: arithmetic persistence sln@netherlands.com
Re: arithmetic persistence <marc.girod@gmail.com>
Re: arithmetic persistence <willem@turtle.stack.nl>
Re: arithmetic persistence <marc.girod@gmail.com>
Re: arithmetic persistence <marc.girod@gmail.com>
Re: arithmetic persistence <willem@turtle.stack.nl>
Re: arithmetic persistence sln@netherlands.com
Re: arithmetic persistence <willem@turtle.stack.nl>
Re: arithmetic persistence <marc.girod@gmail.com>
Re: List Separator $, behaving oddly <hjp-usenet2@hjp.at>
Re: List Separator $, behaving oddly <nospam-abuse@ilyaz.org>
Re: List Separator $, behaving oddly sharma__r@hotmail.com
Please help me how is easiest way to extract text betwe <mladen.g@gmail.com>
Re: really need all the %{ ${ ${$_}{x} }{y} } jazz? <hjp-usenet2@hjp.at>
Re: really need all the %{ ${ ${$_}{x} }{y} } jazz? <jwkrahn@example.com>
Re: Regex question; match <br> after opening tag <hjp-usenet2@hjp.at>
Re: Strategies for modifying marked-up text? sln@netherlands.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 20 Feb 2011 06:43:12 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: arithmetic persistence
Message-Id: <9e51a4f5-fc37-40c9-96ba-68be2f3a52ea@d19g2000yql.googlegroups.com>
A Sunday topic...
I bought not long ago a deck of cards with mathematical puzzles
(question on the face, answer on the back) by Martin Gardner.
One puzzle dealt with the issue of /persistence/ in the mathematical
sense.
Take an integer (decimal representation).
Take the product of the digits its representation is made of.
This gets you a new, smaller, number.
Recurse until the representation takes a single digit.
The persistence is the number of steps it took.
Unclear? Sorry I gave the deck to a friend.
But 0 is the first number of persistence 0.
10 is the first of p(1).
25 is the first of p(2).
39 is the first of p(3).
77 is the first of p(4).
Martin Gardner's question was: what is the first number of p(5)?
After some time of failing to get an answer by just thinking, I wrote
a perl script: p1
-8<----------------------
#!/usr/bin/perl -w
use strict;
use vars qw($ver);
sub prod {
my @d = @_;
my $p = 1;
$p = $p * $_ for @d;
return $p;
}
sub pers {
my ($s, $i) = @_;
if ($i) {
push @{$i}, $s;
} else {
$i = [];
print " $s: " if $ver;
}
my @d = $s =~ /(\d)/g;
if (@d > 1) {
my $p = prod @d;
return pers($p, $i);
}
print scalar @{$i}, ' (', join(' ', @{$i}), ")\n" if $ver;
return scalar @{$i};
}
my ($i, $n, $p) = (1, 1, 0);
while ($i < 10000000) {
$p = pers($i);
if ($p == $n) {
$ver = 1;
pers($i);
$ver = 0;
$n++;
}
$i++;
}
-8<-----------------
It gave me the result, but also a timing (on my laptop, looking
for 10 millions integers, and getting the first result of p(8)):
real 5m41.736s
user 5m40.175s
sys 0m0.108s
I thought that it was pretty lousy, and could be optimized, by
caching the already done calculations.
This brought in the question dealt with in a recent thread, of the
efficiency of hashes.
Trying to limit the size of the hash I use, I came up with the
following p2:
-8<-----------------------
#!/usr/bin/perl -w
use strict;
use vars qw($ver %c $h);
sub prod {
my @d = @_;
my $p = 1;
$p = $p * $_ for @d;
return $p;
}
sub pers {
my ($s, $i) = @_;
print " $s: " if $ver and !$i;
my @d = $s =~ /(\d)/g;
if (@d > 1) {
@d = sort @d;
if ($d[0]) {
shift @d while @d and $d[0] == 1;
if (@d) {
my $k = join '', @d;
if ($c{$k}) {
if (defined $i) { push @{$i}, @{$c{$k}} } else { $i = $c{$k} }
my $r = scalar @{$i};
print " $r", ' (', join(' ', @{$i}), ")\n" if $ver;
$h++;
return $r;
}
my $p = prod @d;
return pers($p, []) unless defined $i;
push @{$i}, $s;
my $r = pers($p, $i);
$c{$k} = $i;
return $r;
} else {
if (defined $i) {push @{$i}, $s} else { $i = [] }
return pers(1, $i);
}
} else {
if (defined $i) {push @{$i}, $s} else { $i = [] }
return pers(0, $i);
}
}
if (defined $i) {push @{$i}, $s} else { $i = [] }
my $r = scalar @{$i};
print " $r", ' (', join(' ', @{$i}), ")\n" if $ver;
return $r;
}
my ($i, $n, $p) = (1, 1, 0);
# $ver = 1;
while ($i < 10000000) {
$p = pers($i);
if ($p == $n) {
$ver = 1;
pers($i);
$ver = 0;
$n++;
}
$i++;
}
print "#keys: ", scalar keys %c, "\nHits: $h\n";
-8<----------------
The point is I was disappointed with the result:
real 4m32.386s
user 4m30.334s
sys 0m0.124s
Especially because 1 billion trials takes more time than 10 times 100
millions.
The numbers are larger, of course...
But, how can one do better?
The word 'persistence' makes it a bit awkward to search Google...
This script also gets soon into the 32 bit limit. Getting beyond is a
new challenge.
My resulting hash (for 10 millions) is not huge, and it was used:
#keys: 324
Hits: 1916050
Marc
------------------------------
Date: Sun, 20 Feb 2011 15:45:50 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: arithmetic persistence
Message-Id: <slrnim2dpd.305s.willem@turtle.stack.nl>
Marc Girod wrote:
) A Sunday topic...
) I bought not long ago a deck of cards with mathematical puzzles
) (question on the face, answer on the back) by Martin Gardner.
) One puzzle dealt with the issue of /persistence/ in the mathematical
) sense.
) Take an integer (decimal representation).
) Take the product of the digits its representation is made of.
) This gets you a new, smaller, number.
) Recurse until the representation takes a single digit.
) The persistence is the number of steps it took.
)
) Unclear? Sorry I gave the deck to a friend.
) But 0 is the first number of persistence 0.
) 10 is the first of p(1).
) 25 is the first of p(2).
) 39 is the first of p(3).
) 77 is the first of p(4).
) Martin Gardner's question was: what is the first number of p(5)?
)
) After some time of failing to get an answer by just thinking, I wrote
) a perl script: p1
) -8<----------------------
) #!/usr/bin/perl -w
<snip brute-force answer>
) -8<-----------------
)
) It gave me the result, but also a timing (on my laptop, looking
) for 10 millions integers, and getting the first result of p(8)):
)
) real 5m41.736s
) user 5m40.175s
) sys 0m0.108s
)
) I thought that it was pretty lousy, and could be optimized, by
) caching the already done calculations.
) This brought in the question dealt with in a recent thread, of the
) efficiency of hashes.
) Trying to limit the size of the hash I use, I came up with the
) following p2:
A hash ? What results were you caching ??
) But, how can one do better?
Cache the right thing. IE, the persistence of all numbers lower than x.
You already use recursion to calculate persistence(x).
Now, if you replace the recursive call with a lookup in the cache,
you'll get each result in a single step.
) The word 'persistence' makes it a bit awkward to search Google...
) This script also gets soon into the 32 bit limit. Getting beyond is a
) new challenge.
Where do you get into the 32 bit limit ??
Here's an example program I whipped up just now:
On my box, it finds P(8) in 15 seconds. (check: it's 2677889)
use strict;
use warnings;
use List::Util qw(reduce);
my @persis;
my $found = 0;
for (0 .. 9) { $persis[$_] = 0; }
for (my $i = 10; $found < 8; $i++) {
my $prod = reduce { $a * $b } split('', $i);
$persis[$i] = my $pers = $persis[$prod] + 1;
if ($pers > $found) {
$found = $pers;
print "$i is the first of p($pers)\n";
}
}
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Sun, 20 Feb 2011 09:31:23 -0800
From: sln@netherlands.com
Subject: Re: arithmetic persistence
Message-Id: <nsj2m6pl88re506820b9q6ckfc4q5qo6dv@4ax.com>
On Sun, 20 Feb 2011 15:45:50 +0000 (UTC), Willem <willem@turtle.stack.nl> wrote:
>Where do you get into the 32 bit limit ??
>
>Here's an example program I whipped up just now:
>On my box, it finds P(8) in 15 seconds. (check: it's 2677889)
>
>use strict;
>use warnings;
>use List::Util qw(reduce);
>
>my @persis;
>my $found = 0;
>
>for (0 .. 9) { $persis[$_] = 0; }
>
>for (my $i = 10; $found < 8; $i++) {
> my $prod = reduce { $a * $b } split('', $i);
> $persis[$i] = my $pers = $persis[$prod] + 1;
> if ($pers > $found) {
> $found = $pers;
> print "$i is the first of p($pers)\n";
> }
>}
>
10 is the first of p(1)
25 is the first of p(2)
39 is the first of p(3)
77 is the first of p(4)
679 is the first of p(5)
6788 is the first of p(6)
68889 is the first of p(7)
2677889 is the first of p(8)
26888999 is the first of p(9)
Anyone care to run this out to p(20)
-sln
------------------------------
Date: Sun, 20 Feb 2011 09:47:41 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: arithmetic persistence
Message-Id: <bb223a05-2694-4625-a064-e2fb8951a7ef@p12g2000vbo.googlegroups.com>
On Feb 20, 3:45=A0pm, Willem <wil...@turtle.stack.nl> wrote:
> A hash ? =A0What results were you caching ??
The decomposition of unique products.
OK: I was doing extra work there to get some extra output.
Not strictly needed for my problem statement.
My output gave:
10: 1 (0)
25: 2 (10 0)
39: 3 (27 14 4)
77: 4 (49 36 18 8)
679: 5 (378 168 48 32 6)
6788: 6 (2688 768 336 45 20 0)
68889: 7 (27648 2688 768 336 45 20 0)
2677889: 8 (338688 27648 2688 768 336 45 20 0)
> Cache the right thing. =A0IE, the persistence of all numbers lower than x=
.
I was trying to get one step smarter, there...
trying to skip saving duplicates results for numbers
with the same digits in different order.
> You already use recursion to calculate persistence(x).
> Now, if you replace the recursive call with a lookup in the cache,
> you'll get each result in a single step.
I was doing that inside the function.
> Where do you get into the 32 bit limit ??
First number with persistence 10?
> Here's an example program I whipped up just now:
> On my box, it finds P(8) in 15 seconds. =A0(check: it's 2677889)
Your box is faster than mine: I get 44 s.
Your loop is different, you stop after 2.7 million when I go to 10.
And you get a different low level calculation.
But OK, putting those into my algorithm, I get down to 1m13, so still
about 1.5 times slower than you.
OK, I strip my collecting the decomposition...
Now, we are comparing the same things, and I get 31s.
It is not as clean as yours, granted:
#!/usr/bin/perl -w
use strict;
use vars qw($ver %c);
use List::Util qw(reduce);
use vars qw($a $b);
sub pers {
my $s =3D shift;
my @d =3D split('', $s);
if (@d > 1) {
@d =3D sort @d;
if ($d[0]) {
shift @d while @d and $d[0] =3D=3D 1;
if (@d) {
my $k =3D join '', @d;
return $c{$k} if $c{$k};
my $p =3D reduce { $a * $b } @d;
$c{$k} =3D pers($p, 1) + 1;
return $c{$k};
}
}
return 1;
}
return 0;
}
my ($i, $n, $p) =3D (1, 1, 0);
while ($n < 9) {
$p =3D pers($i);
if ($p =3D=3D $n) {
print " $i: $n\n";
$n++;
}
$i++;
}
Marc
------------------------------
Date: Sun, 20 Feb 2011 18:04:53 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: arithmetic persistence
Message-Id: <slrnim2lu5.3j5.willem@turtle.stack.nl>
sln@netherlands.com wrote:
) 10 is the first of p(1)
) 25 is the first of p(2)
) 39 is the first of p(3)
) 77 is the first of p(4)
) 679 is the first of p(5)
) 6788 is the first of p(6)
) 68889 is the first of p(7)
) 2677889 is the first of p(8)
) 26888999 is the first of p(9)
)
) Anyone care to run this out to p(20)
Hell, I didn't have enough memory to get p(10) like this.
Even in C, allocating one byte for one result.
Perhaps a smarter approach would help. Or a stupider one... ^^;;
My perl brute force approach took 25 seconds to find p(8).
Which isn't that much more than the 15 it took the DP version.
BTW: A simple C program took less than 2 seconds to find p(9).
Adding a simple pruning cut that in half.
NB: The pruning version is even faster than the caching version.
Now running it for p(10)...
I guess the OP was using some very slow programming techniques.
If anyone cares, I can explain how the pruning version works.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Sun, 20 Feb 2011 10:16:06 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: arithmetic persistence
Message-Id: <b2715325-6e44-4b26-a020-d0783d69ad06@w36g2000vbi.googlegroups.com>
On Feb 20, 5:47=A0pm, Marc Girod <marc.gi...@gmail.com> wrote:
> First number with persistence 10?
OK. I missed that. Perl gets nicely above that.
> And you get a different low level calculation.
This didn't make much difference.
My prod was maybe even slightly faster than using reduce.
And using a global regexp marginally slower than split.
Marc
------------------------------
Date: Sun, 20 Feb 2011 10:20:46 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: arithmetic persistence
Message-Id: <584eb127-d943-4b40-89d1-3f7cbf82652f@r4g2000vbq.googlegroups.com>
On Feb 20, 6:04=A0pm, Willem <wil...@turtle.stack.nl> wrote:
> I guess the OP was using some very slow programming techniques.
Don't guess, look at the code!
I wasted time mostly to get some extra data in the printout.
The rest was using a different stop condition (testing n numbers,
instead of looking for the first number with a given persistence).
And I have a slower box.
For the rest, my algorithm was already a pruning version of yours.
> If anyone cares, I can explain how the pruning version works.
Yes, please. And compare with mine!
Marc
------------------------------
Date: Sun, 20 Feb 2011 18:39:12 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: arithmetic persistence
Message-Id: <slrnim2nug.3j5.willem@turtle.stack.nl>
Marc Girod wrote:
) On Feb 20, 3:45?pm, Willem <wil...@turtle.stack.nl> wrote:
)
)> A hash ? ?What results were you caching ??
)
) The decomposition of unique products.
) OK: I was doing extra work there to get some extra output.
) Not strictly needed for my problem statement.
) My output gave:
)
) 10: 1 (0)
) 25: 2 (10 0)
) 39: 3 (27 14 4)
) 77: 4 (49 36 18 8)
) 679: 5 (378 168 48 32 6)
) 6788: 6 (2688 768 336 45 20 0)
) 68889: 7 (27648 2688 768 336 45 20 0)
) 2677889: 8 (338688 27648 2688 768 336 45 20 0)
)
)> Cache the right thing. ?IE, the persistence of all numbers lower than x.
)
) I was trying to get one step smarter, there...
) trying to skip saving duplicates results for numbers
) with the same digits in different order.
Oh I see. Does that help ? I would imagine that looking up
the results in an array would give a big speedup.
)> Here's an example program I whipped up just now:
)> On my box, it finds P(8) in 15 seconds. ?(check: it's 2677889)
)
) Your box is faster than mine: I get 44 s.
) Your loop is different, you stop after 2.7 million when I go to 10.
) And you get a different low level calculation.
)
) But OK, putting those into my algorithm, I get down to 1m13, so still
) about 1.5 times slower than you.
Ah, so the low level calculation was slowing you down a lot ?
) OK, I strip my collecting the decomposition...
) Now, we are comparing the same things, and I get 31s.
) It is not as clean as yours, granted:
Now that it's stripped down I see what you were doing.
The whole decomposition thing was throwing me a loop.
Quite clever! And, as it seems, indeed faster.
You cut out any number that has a 0 anywhere, also.
Like this, you're skipping a lot of calculations indeed,
but at the cost of sorting the digits.
By the way, here's a simple version that's marginally faster
even, and doesn't require lots of memory. It uses a simple
pruning trick to cut off calculation when it knows that a
result isn't good enough.
use strict;
use warnings;
use List::Util qw(reduce);
my $found = 0;
my $fnum = 0;
for (my $i = 10; $found < 8; $i++) {
my $prod = reduce { $a * $b } split('', $i);
next if ($prod < $fnum);
my $cnt = 1;
while ($prod >= 10) {
$prod = reduce { $a * $b } split('', $prod);
$cnt++;
}
if ($cnt > $found) {
$found = $cnt;
$fnum = $i;
print "$i is the first of p($cnt)\n";
}
}
I also wrote this in C, using 64-bit ints, and it turns out that
3778888999 is the first of p(10), which my box found in 2m50.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Sun, 20 Feb 2011 10:47:58 -0800
From: sln@netherlands.com
Subject: Re: arithmetic persistence
Message-Id: <kdo2m61dof88vfl4fgkntda8oj949lfag1@4ax.com>
On Sun, 20 Feb 2011 18:39:12 +0000 (UTC), Willem <willem@turtle.stack.nl> wrote:
>Marc Girod wrote:
>) On Feb 20, 3:45?pm, Willem <wil...@turtle.stack.nl> wrote:
>)
>)> A hash ? ?What results were you caching ??
>)
>) The decomposition of unique products.
>) OK: I was doing extra work there to get some extra output.
>) Not strictly needed for my problem statement.
>) My output gave:
>)
>) 10: 1 (0)
>) 25: 2 (10 0)
>) 39: 3 (27 14 4)
>) 77: 4 (49 36 18 8)
>) 679: 5 (378 168 48 32 6)
>) 6788: 6 (2688 768 336 45 20 0)
>) 68889: 7 (27648 2688 768 336 45 20 0)
>) 2677889: 8 (338688 27648 2688 768 336 45 20 0)
>)
>)> Cache the right thing. ?IE, the persistence of all numbers lower than x.
>)
>) I was trying to get one step smarter, there...
>) trying to skip saving duplicates results for numbers
>) with the same digits in different order.
>
>Oh I see. Does that help ? I would imagine that looking up
>the results in an array would give a big speedup.
>
>)> Here's an example program I whipped up just now:
>)> On my box, it finds P(8) in 15 seconds. ?(check: it's 2677889)
>)
>) Your box is faster than mine: I get 44 s.
>) Your loop is different, you stop after 2.7 million when I go to 10.
>) And you get a different low level calculation.
>)
>) But OK, putting those into my algorithm, I get down to 1m13, so still
>) about 1.5 times slower than you.
>
>Ah, so the low level calculation was slowing you down a lot ?
>
>) OK, I strip my collecting the decomposition...
>) Now, we are comparing the same things, and I get 31s.
>) It is not as clean as yours, granted:
>
>Now that it's stripped down I see what you were doing.
>The whole decomposition thing was throwing me a loop.
>Quite clever! And, as it seems, indeed faster.
>You cut out any number that has a 0 anywhere, also.
>
>Like this, you're skipping a lot of calculations indeed,
>but at the cost of sorting the digits.
>
>
>By the way, here's a simple version that's marginally faster
>even, and doesn't require lots of memory. It uses a simple
>pruning trick to cut off calculation when it knows that a
>result isn't good enough.
>
>
>use strict;
>use warnings;
>use List::Util qw(reduce);
>
>my $found = 0;
>my $fnum = 0;
>
>for (my $i = 10; $found < 8; $i++) {
> my $prod = reduce { $a * $b } split('', $i);
> next if ($prod < $fnum);
> my $cnt = 1;
> while ($prod >= 10) {
> $prod = reduce { $a * $b } split('', $prod);
> $cnt++;
> }
> if ($cnt > $found) {
> $found = $cnt;
> $fnum = $i;
> print "$i is the first of p($cnt)\n";
> }
>}
>
>
>I also wrote this in C, using 64-bit ints, and it turns out that
>3778888999 is the first of p(10), which my box found in 2m50.
>
>
Thank you. I must analyze this pruning.
-sln
------------------------------
Date: Sun, 20 Feb 2011 18:50:29 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: arithmetic persistence
Message-Id: <slrnim2ojl.3j5.willem@turtle.stack.nl>
Marc Girod wrote:
) On Feb 20, 6:04?pm, Willem <wil...@turtle.stack.nl> wrote:
)
)> I guess the OP was using some very slow programming techniques.
)
) Don't guess, look at the code!
) I wasted time mostly to get some extra data in the printout.
That's silly. You can recalculate the extra data when needed.
) The rest was using a different stop condition (testing n numbers,
) instead of looking for the first number with a given persistence).
) And I have a slower box.
The 5m you quoted, was that for the n numbers ?
) For the rest, my algorithm was already a pruning version of yours.
)
)> If anyone cares, I can explain how the pruning version works.
)
) Yes, please. And compare with mine!
Well, it's quite simple. You use a simple brute force algorithm,
but if the first product calculation turns out to be smaller than
the last smallest persistence you found, you go to the next number.
In other words, when looking for a number with P(10), then the
first product has to be in P(9), so if it's smaller than the
smallest P(9), you can conclude that it's not in P(10).
It turns out that multiplying the simple way, using arithmetics,
is faster even in Perl.
use strict;
use warnings;
my $found = 0;
my $fnum = 0;
for (my $i = 10; $found < 10; $i++) {
my $prod = multiply($i);
next if ($prod < $fnum);
my $cnt = 1;
while ($prod >= 10) {
$prod = multiply($prod);
$cnt++;
}
if ($cnt > $found) {
$found = $cnt;
$fnum = $i;
print "$i is the first
of p($cnt)\n";
}
}
sub multiply
{
my $num = shift;
my $prod = 1;
while ($prod && $num) {
$prod *= ($num % 10);
$num = int($num / 10);
}
return $prod;
}
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Sun, 20 Feb 2011 11:00:34 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: arithmetic persistence
Message-Id: <5f9e7762-b3c0-40dd-93a2-dfcf605159fe@y3g2000vbh.googlegroups.com>
On Feb 20, 6:39=A0pm, Willem <wil...@turtle.stack.nl> wrote:
> Like this, you're skipping a lot of calculations indeed,
> but at the cost of sorting the digits.
...which is a rising cost, and ends up being prohibitive...
> By the way, here's a simple version that's marginally faster
> even, and doesn't require lots of memory. =A0It uses a simple
> pruning trick to cut off calculation when it knows that a
> result isn't good enough.
Yes, a much simpler idea, indeed.
I have to get out of my first mindset of getting the value anyway.
> I also wrote this in C, using 64-bit ints, and it turns out that
> 3778888999 is the first of p(10), which my box found in 2m50.
And I am nowhere near this, of course.
Thanks,
Marc
------------------------------
Date: Sat, 19 Feb 2011 20:21:28 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: List Separator $, behaving oddly
Message-Id: <slrnim061o.716.hjp-usenet2@hrunkner.hjp.at>
On 2011-02-18 19:27, sharma__r@hotmail.com <sharma__r@hotmail.com> wrote:
> On Feb 18, 11:37 pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
>> On 2011-02-18 09:42, sharma...@hotmail.com <sharma...@hotmail.com> wrote:
>> > when we set the $, punctuation variable two different ways we get
>> > different behaviors.
>>
>> > perl -e '
>> > # this does not work
>> > local *{"::,"} = \do{q[:]};
>> [...]
>> > ';
>>
>> > perl -e '
>> > # this works
>> > local ${*{"::,"}} = q[:];
>> [...]
>> > ';
>>
>> > Why does this happen?
>>
>> May I ask why you set $, in such a wierd way? Why don't you just use
>>
>> local $, = q[:];
>>
>> ?
>
>
> I am trying to alter the punctuation variables inside a sub, like as
> show below.
>
> The idea is to make the sub immune from any settings of punctuation
> variables that may be in effect
> AND
> also if we want to supersede the local punctuation inside a sub, we
> may supply it from outside via a
> hash whose keys are the punctuation variable symbols.
[...]
> sub klm {
> my %h = %{$_[0]};
> local $, = q{=}; # <--- setting inside the sub(use this if not forced
> from outside)
> no strict 'refs';
> ${*{"::$_"}} = $h{$_} for keys %h; # <--- this works, meaning proper
> $, takes effect as also print shows proper separtors
> # *{"::$_"} = \$h{$_} for keys %h; # <--doesn't work, meaning
> proper $, takes effect but print does not show proper separtion
[please avoid wrapped lines in example code: It makes the code hard to
read and it cannot be executed as is]
${$_} = $h{$_} for keys %h;
seems to work, too.
hp
------------------------------
Date: Sun, 20 Feb 2011 01:56:55 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: List Separator $, behaving oddly
Message-Id: <slrnim0t77.8bd.nospam-abuse@powdermilk.math.berkeley.edu>
On 2011-02-18, sharma__r@hotmail.com <sharma__r@hotmail.com> wrote:
> when we set the $, punctuation variable two different ways
Nope.
> we get different behaviors.
> # this does not work
> local *{"::,"} = \do{q[:]};
You are not setting a variable here. You are replacing a container.
After this, a lookup for $, would return not the magic container
usually associated with $, but the container created by q() inside
your do{}. Contrast this with setting a variable, which is changing
what is INSIDE the container.
All the magic properties of $, are lost after your operation (unless
somebody stored $oldComma = \$, somewhere, and now accesses the old
container via $$oldComma.
> # this works
> local ${*{"::,"}} = q[:];
Here the LHS is an alias for $::,
Hope this helps,
Ilya
------------------------------
Date: Sat, 19 Feb 2011 21:29:59 -0800 (PST)
From: sharma__r@hotmail.com
Subject: Re: List Separator $, behaving oddly
Message-Id: <bd96c6ea-e5ec-4653-a1c6-570912cef8c0@r19g2000prm.googlegroups.com>
On Feb 20, 6:56=A0am, Ilya Zakharevich <nospam-ab...@ilyaz.org> wrote:
> On 2011-02-18, sharma...@hotmail.com <sharma...@hotmail.com> wrote:
>
> > when we set the $, punctuation variable two different ways
>
> Nope.
>
> > we get different behaviors.
> > # this does not work
> > local *{"::,"} =3D \do{q[:]};
>
> You are not setting a variable here. =A0You are replacing a container.
> After this, a lookup for $, would return not the magic container
> usually associated with $, but the container created by q() inside
> your do{}. =A0Contrast this with setting a variable, which is changing
> what is INSIDE the container.
>
> All the magic properties of $, are lost after your operation (unless
> somebody stored $oldComma =3D \$, somewhere, and now accesses the old
> container via $$oldComma.
>
> > # this works
> > local ${*{"::,"}} =3D q[:];
>
> Here the LHS is an alias for $::,
>
> Hope this helps,
> Ilya
This has left me confused.
So what you are implying is that Perl looks at the "address" of $,
to enable its magic. But it isn't documented.
And why doesn't this behavior impacting the Exporter ?
--Rakesh
------------------------------
Date: Sun, 20 Feb 2011 19:33:18 +0100
From: "Mladen" <mladen.g@gmail.com>
Subject: Please help me how is easiest way to extract text between some variable text
Message-Id: <ijrmpb$oc1$1@localhost.localdomain>
Please help me how is easiest way to extract text between some variable text
Original text
<TH class=name width=100>New name</TH> need to
extract: New name
<TH class=name width=50>Test name </TH> need to
extract: Test name
<TH class=name width=65>Name 2</TH> need
to extract: Name 2
Thanks in advance
------------------------------
Date: Sat, 19 Feb 2011 20:08:39 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: really need all the %{ ${ ${$_}{x} }{y} } jazz?
Message-Id: <slrnim059n.716.hjp-usenet2@hrunkner.hjp.at>
On 2011-02-19 02:37, jidanni@jidanni.org <jidanni@jidanni.org> wrote:
> Gentlemen, my program runs great, but do I really have to use all that wacky
> %{ ${ ${$_}{geometry} }{location} } )
> stuff that I worked out using Data::Dumper, or is there a more familiar
> way to write it?
Read perldoc perlreftut, especially the use rules 1 and 2.
hp
------------------------------
Date: Sun, 20 Feb 2011 02:38:05 -0800
From: "John W. Krahn" <jwkrahn@example.com>
Subject: Re: really need all the %{ ${ ${$_}{x} }{y} } jazz?
Message-Id: <ia68p.107145$kr5.35447@newsfe08.iad>
jidanni@jidanni.org wrote:
> Gentlemen, my program runs great, but do I really have to use all that wacky
> %{ ${ ${$_}{geometry} }{location} } )
> stuff that I worked out using Data::Dumper, or is there a more familiar
> way to write it?
>
> use strict; use warnings FATAL => 'all'; local $/;
> use JSON -support_by_pp;
> my $v = from_json(<>, { utf8 => 0 } );
> use feature "switch";
> given ( $$v{status} ) {
> when ('OK') { }
> default { die $_; }
> }
> for ( @{ $$v{results} } ) {
> printf "%.7f %.7f %s %s\n",
> reverse( values %{ ${ ${$_}{geometry} }{location} } ),
^^^^^^^^^^^^^^^^^^^^
Here you say that ${$_}{geometry} contains a reference to a scalar.
> ${$_}{formatted_address}, ${$_}{geometry}{location_type};
^^^^^^^^^^^^^^^
And here you say that ${$_}{geometry} contains a reference to a hash
It has to be one or the other, but not both. So which is it?
BTW, ${$_}{geometry} is usually written as $_->{geometry}
John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
------------------------------
Date: Sat, 19 Feb 2011 20:04:17 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Regex question; match <br> after opening tag
Message-Id: <slrnim051h.716.hjp-usenet2@hrunkner.hjp.at>
On 2011-02-18 21:03, Tad McClellan <tadmc@seesig.invalid> wrote:
> ccc31807 <cartercc@gmail.com> wrote:
>> On Feb 18, 1:42 pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
>>> <br title="a <br> element">
>>
>> not valid HTML.
>
>
> Yes it is.
I wasn't actually sure whether an unescaped "<" within an attribute
value is allowed (it's forbidden in XML), but James Clark's SGML parser
accepts it and http://www.isgmlug.org/sgmlhelp/g-sg16.htm suggests it.
In any case I'm sure that an unescaped ">" is allowed, and that's the
one which brings breaks the proposed solution.
>><br title="a <br> element" />
>
>
> That is XHTML.
Even in XML, an unescaped ">" within an attribute is allowed, so
<br title="a <br> element" />
is valid XHTML and breaks the proposed solution.
> XHTML is not the same as HTML.
ACK. Although I tend to use HTML compatible XHTML[1] instead of HTML.
hp
[1] http://www.w3.org/TR/xhtml1/#guidelines
------------------------------
Date: Sun, 20 Feb 2011 07:19:56 -0800
From: sln@netherlands.com
Subject: Re: Strategies for modifying marked-up text?
Message-Id: <qob2m6lpb4rqn3dmo6t300dp0j8on4s5pc@4ax.com>
On Thu, 17 Feb 2011 10:45:11 +0100, Thomas Baetzler <news4281@baetzler.de> wrote:
>Hi,
>
>I'm looking for input on how to run search/replace operations on
>paragraphs of HTML text without having to worry about the surrounding
>markup.
>
>So far I'm using HTML::Treebuilder to parse a HTML document and identfy
>the individual paragraphs in the text. By recursively using the
>content_list method, I can locate the individual text chunks that make
>up the paragraph text.
>
>What I'd like to do is merge these chunks into a single string, run some
>search/replace regexes on it, then update the individual text chunks
>with the changes.
>
>Is there a better way to do this than stopping after each change to see
>what's changed and keep track of chunk borders that way?
>
>I could probably work on individual chunks in turn, but taking care of
>all the edge cases where I'd have to do lookahead/lookback in adjoining
>chunks could be, well, tedious ;-)
>
>TIA for any suggestion you might have!
>
>Cheers,
>Thomas
You can't. What granulatiry, letters? Yes letters. Thats about it.
That means even a word is not safe, let alone a phrase.
A human put all that together in a rule-less way. That means only a
human can modify it.
Its sometimes easy for the mind to rationalize that these things can be
done. After all, a human did it. Oh, it could probably be guessed with
natural language processing, but its just a guess.
Nice try though.
-sln
------------------------------
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 3292
***************************************
