[28192] in Perl-Users-Digest
Perl-Users Digest, Issue: 9556 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 3 14:05:50 2006
Date: Thu, 3 Aug 2006 11:05:06 -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 Thu, 3 Aug 2006 Volume: 10 Number: 9556
Today's topics:
Re: 0th positin set when futzing with $[ <benmorrow@tiscali.co.uk>
Re: Curl/Perl http post performanc issue <benmorrow@tiscali.co.uk>
Re: Curl/Perl http post performanc issue <wkhedr@my-deja.com>
h2xs -Oxan ... fails when processing GNU/Linux /usr/inc <ramcgowan@comcast.net>
Re: How probably not to hand over a variable from one p <youcontrol@hispeed.ch>
Re: How probably not to hand over a variable from one p <youcontrol@hispeed.ch>
Re: How probably not to hand over a variable from one p <jurgenex@hotmail.com>
Re: How probably not to hand over a variable from one p <youcontrol@hispeed.ch>
Re: How probably not to hand over a variable from one p tinnews@isbd.co.uk
Re: How probably not to hand over a variable from one p <scobloke2@infotop.co.uk>
Re: How probably not to hand over a variable from one p <David.Squire@no.spam.from.here.au>
Re: How probably not to hand over a variable from one p <David.Squire@no.spam.from.here.au>
Re: how to "anonymize" Perl script before publishing it allenjo5@mail.northgrum.com
Re: Perl hash of hash efficiency. xhoster@gmail.com
Re: Recursion <koko_loko_0@yahoo.co.uk>
Re: Recursion <mritty@gmail.com>
Re: Recursion <koko_loko_0@yahoo.co.uk>
Re: Recursion <tzz@lifelogs.com>
Re: Unicode & Upgrading Perl <benmorrow@tiscali.co.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 3 Aug 2006 17:36:15 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: 0th positin set when futzing with $[
Message-Id: <v8l9q3-rvl.ln1@osiris.mauzo.dyndns.org>
Quoth "Paul Lalli" <mritty@gmail.com>:
> First, I know, - I *know* - one should not play with the $[ variable,
> and I would never ever do so in "real" code. Another thread mentioned
> the variable, and I was bored, so I started playing. That being said,
> I see the following results:
>
> $ perl -le'
> $[ = 7;
> @foo = qw/alpha beta gamma/;
> print "$_ => $foo[$_]" for 0 .. $#foo;
> '
> 0 => alpha
> 1 =>
> 2 =>
> 3 =>
> 4 => alpha
> 5 => beta
> 6 => gamma
> 7 => alpha
> 8 => beta
> 9 => gamma
>
> I can understand positions 7-9 being set. 7 is the first position of
> the array now. And I can understand position 4-6 being set. This is
> for the "wraparound" feature that we normally see when $[ hasn't been
> altered and we access negative indices . But can anyone explain to me
> why the position 0 is set? (and yes, I know -w would give me three
> "use of uninitialized" warnings for 1-3 above. Not relevant to my
> question, so I omitted it).
>
> I do not see any similar results when printing the values of, say -10
> through 3 if $[ has not been altered. So I assume this is specific to
> the 0th position, after $[ has been modified...
Yup. One thing you didn't try was
-4 =>
-3 => alpha
-2 => beta
-1 => gamma
(with $[=7). The relevant code is in pp_hot.c:pp_aelem
if (elem > 0)
elem -= PL_curcop->cop_arybase;
where elem is the index requested and PL_curcop->cop_arybase is the
value $[ had when the current statement was compiled (you realise, I
presume, that $[=foo; statements are not ordinary variable assignments,
and are processed more like 'use arybase foo;'? In particular, their
effect is compile-time and lexically scoped).
That line (well, the 'if (elem > 0)' line) has been there since the
initial 5.003 checkin when p5p moved over to Perforce, so I can't get a
commit log to see why it's there...
WRT the original thread, I think that this carping on about how @a - $#a
is not necessarily 1 because of $[ is seriously unhelpful. Noone in
their right mind would use $[ in real code, and it must just confuse
beginners more to have some weird $[ thrown at them when they're not
understanding scalar @a vs. $#a yet.
Ben
--
I must not fear. Fear is the mind-killer. I will face my fear and
I will let it pass through me. When the fear is gone there will be
nothing. Only I will remain.
benmorrow@tiscali.co.uk Frank Herbert, 'Dune'
------------------------------
Date: Thu, 3 Aug 2006 17:12:15 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: Curl/Perl http post performanc issue
Message-Id: <vrj9q3-6gl.ln1@osiris.mauzo.dyndns.org>
Quoth "wkhedr" <wkhedr@my-deja.com>:
> We have a Perl program that has to do thousands of secure http post
> requests to a web server as efficient as we could.
> The web server sends back a big XML structure in every request.
>
> We used Curl because it allowed us to deal with secured requests.
Have you tried using LWP?
> Curl by default uses http 1.1.
>
> When we ask Curl to use http 1.0, we get average response time of 40
> millisecond during our stress tests.
>
> The response time is good but the problem is it's not releasing the
> CPU's while waiting for the response. It's supposed to be like a disk
> I/O where it should not be using the CPU. So the CPU utilization goes
> up to 99% with multithreads of testing.
>
> When we run the tests using http 1.1, the response time was 2 seconds
> :)
>
> Using http 1.1 and asking Curl to disable "Expect: 100-continue" by
> using header "Expect:",
> we were able to reach response time of 120 milliseconds and the CPU
> usage was cut by almost 90%.
>
> The question is: how can we get the best of the two settings: have the
> same low CPU usage as http 1.1 and reduce the response time from 120 ms
> to 40 ms as http 1.0?
The rest of this is not really relevant to Perl, and would be better
asked on some Curl-related list or group.
Ben
--
I must not fear. Fear is the mind-killer. I will face my fear and
I will let it pass through me. When the fear is gone there will be
nothing. Only I will remain.
benmorrow@tiscali.co.uk Frank Herbert, 'Dune'
------------------------------
Date: 3 Aug 2006 10:01:31 -0700
From: "wkhedr" <wkhedr@my-deja.com>
Subject: Re: Curl/Perl http post performanc issue
Message-Id: <1154624491.149714.272460@m73g2000cwd.googlegroups.com>
LWP did the same numbers 120ms!
Ben Morrow wrote:
> Quoth "wkhedr" <wkhedr@my-deja.com>:
> > We have a Perl program that has to do thousands of secure http post
> > requests to a web server as efficient as we could.
> > The web server sends back a big XML structure in every request.
> >
> > We used Curl because it allowed us to deal with secured requests.
>
> Have you tried using LWP?
>
> > Curl by default uses http 1.1.
> >
> > When we ask Curl to use http 1.0, we get average response time of 40
> > millisecond during our stress tests.
> >
> > The response time is good but the problem is it's not releasing the
> > CPU's while waiting for the response. It's supposed to be like a disk
> > I/O where it should not be using the CPU. So the CPU utilization goes
> > up to 99% with multithreads of testing.
> >
> > When we run the tests using http 1.1, the response time was 2 seconds
> > :)
> >
> > Using http 1.1 and asking Curl to disable "Expect: 100-continue" by
> > using header "Expect:",
> > we were able to reach response time of 120 milliseconds and the CPU
> > usage was cut by almost 90%.
> >
> > The question is: how can we get the best of the two settings: have the
> > same low CPU usage as http 1.1 and reduce the response time from 120 ms
> > to 40 ms as http 1.0?
>
> The rest of this is not really relevant to Perl, and would be better
> asked on some Curl-related list or group.
>
> Ben
>
> --
> I must not fear. Fear is the mind-killer. I will face my fear and
> I will let it pass through me. When the fear is gone there will be
> nothing. Only I will remain.
> benmorrow@tiscali.co.uk Frank Herbert, 'Dune'
------------------------------
Date: 3 Aug 2006 09:47:52 -0700
From: "freeholder" <ramcgowan@comcast.net>
Subject: h2xs -Oxan ... fails when processing GNU/Linux /usr/include/stdio.h
Message-Id: <1154623672.926932.138370@i3g2000cwc.googlegroups.com>
I'm attempting to build a module created by an associate that works
fine on a Solaris 9 system. This is not going to actually be packaged
up in any way for distribution, it's for internal use on a few systems,
so we've chosen to simply build the module from scratch for the two
environments. This may not be the best decision, but that's where we
are now.
The problem is that the files and process used successfully on the
Solaris system fail in the second run of h2xs on the Linux box (both
Red Hat EL and Debian etch), with the following error:
--
$ h2xs -Oxan CLIEXT cliext.h
Defaulting to backwards compatibility with perl 5.8.4
If you intend this module to be compatible with earlier perl versions,
please
specify a minimum perl version with the -b option.
Overwriting existing CLIEXT!!!
Writing CLIEXT/ppport.h
Scanning typemaps...
Scanning /usr/local/perl/lib/5.8.4/ExtUtils/typemap
Scanning cliext.h for functions...
Expecting parenth after identifier in `struct _IO_FILE_plus
_IO_2_1_stdin_;
extern struct _IO_FILE_plus _IO_2_1_stdout_;
extern struct _IO_FILE_plus _IO_2_1_stderr_;
# 354 "/usr/include/libio.h" 3 4
typedef __ssize_t __io_read_fn (void *__cookie, char *__buf, size_t
__nbytes);
...deleted blank lines...
typedef __ssize_t __io_write_fn (void *__cookie, __const char *__buf,
size_t __n);
...deleted blank lines...
typedef int __io_seek_fn (void *__cookie, __off64_t *__pos, int __w);
typedef int __io_close_fn (void *__cookie);
# 406 "/usr/include/libio.h" 3 4
extern int __underflow (_IO_FILE *) __attribute__ ((__nothrow__))'
after `struct _IO_FILE_plus _IO_2_1_stdin_' at /usr/local/perl/lib/site
--
Nothing useful is created, of course, and we need to use the stdio.h in
order to get the definition of the FILE pointer type, which is being
passed from the Perl code to the C routine.
I would appreciate any assisstance anyone can provide to solve this.
Thanks,
Bob (freeholder ;)
------------------------------
Date: Thu, 3 Aug 2006 17:11:06 +0200
From: =?ISO-8859-1?Q?Markus_H=E4nchen?= <youcontrol@hispeed.ch>
Subject: Re: How probably not to hand over a variable from one perl script to another
Message-Id: <44d21208@news1.ethz.ch>
>> without any arguments should give me that element, Perl should be smart
>> enough to do this (and I guess it would be, were it not for the fact
>> that @arrayname is reserved to give me the number of elements of an
>> array, which I did not know since I always used $#arrayname to get the
>> length of an array).
>
> Oh, but, $#arrayname does not give the length of the array. It gives
> the last index of the array.
In Matlab length(matrixname) gives you the number of rows. Therefrom
stems my usage of the word length to indicate the number of entries and
since the last index +1 is equal to the number of entries...
> <rant>
> I consider this poster a good example of what happens when people are
> not immediately hit by a clue-by-four. I mean, look at this thread: A
> bunch of us patiently explaining the most elementary concepts that one
> ought to learn by reading a book, and what do we get in return? "Perl
> should be smart enough"? And a complete resistance to learning.
>
> Perl, just like any other programming language, has rules. Those rules
> make the language. The programmer learns those rules, and abides by
> them. If said programmer does not like the rules of a language, the
> programmer should look for another languages which is more to his
> liking.
>
> I am out of this thread.
> </rant>
I started this thread by trying to amuse you by showing in what a
complicated manner a complete beginner might solve a problem (and
hoping that maybe somebody would be tempted into telling me how much
easier I could have solved it).
------------------------------
Date: Thu, 3 Aug 2006 17:29:48 +0200
From: =?ISO-8859-1?Q?Markus_H=E4nchen?= <youcontrol@hispeed.ch>
Subject: Re: How probably not to hand over a variable from one perl script to another
Message-Id: <44d2166a@news1.ethz.ch>
On 2006-08-03 17:00:49 +0200, "Jürgen Exner" <jurgenex@hotmail.com> said:
> A. Sinan Unur wrote:
>> David Squire <David.Squire@no.spam.from.here.au> wrote in
>> news:eat1le$27f $1@gemini.csx.cam.ac.uk:
>>
>>> A. Sinan Unur wrote:
>>>> Markus Hänchen <youcontrol@hispeed.ch> wrote in
>>>> news:44d1ee5f@news1.ethz.ch:
>>>>>
>>>>> But, helas, nope.
>>>>
>>>> ITYM, 'alas'.
>>>
>>> Not necessarily. 'helas' is perfectly good French, and is also used
>>> in (mostly literary) English. The OED does mark it as obsolete
>>> though.
>>
>> I learn something new everyday.
>
> Although, Wikipedia does not know it, my standard dictionaries don't
> know it, and only the 2000+ page 8 pound Webster Encyclopedic
> Dictionary has a very short entry. Not commonly used, I would conclude.
>
> jue
I guess then that is me reading too much French and mixing up languages...
------------------------------
Date: Thu, 03 Aug 2006 15:32:47 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: How probably not to hand over a variable from one perl script to another
Message-Id: <zGoAg.8692$zV6.3043@trnddc03>
Markus Hänchen wrote:
>> Oh, but, $#arrayname does not give the length of the array. It gives
>> the last index of the array.
>
> In Matlab length(matrixname) gives you the number of rows. Therefrom
> stems my usage of the word length to indicate the number of entries
> and since the last index +1 is equal to the number of entries...
Most of the time, but not necessarily. See "perldoc perlvar" for $[
jue
------------------------------
Date: Thu, 3 Aug 2006 17:42:06 +0200
From: =?ISO-8859-1?Q?Markus_H=E4nchen?= <youcontrol@hispeed.ch>
Subject: Re: How probably not to hand over a variable from one perl script to another
Message-Id: <44d2194c@news1.ethz.ch>
> 2) Subroutine libraries
>
> If the runit.pl code needs to be invoked from more than one perl script,
That is the case for me (I am already using subroutines and know how
useful they are).
> then I'd first make it work as an inline subroutine (as 1. above) then
> learn how to separate it into a subroutine library
>
> perldoc -f require
>
> ----- 8< ------- myapp.pl
> #!/usr/bin/perl
> use strict;
> use warnings;
>
> require('mylib.pl');
>
> my @test = (12,4,5,10);
> print "The sum of @test is ", sum(\@test), "\n";
>
> ----- 8< ------- mylib.pl
> use strict;
> use warnings;
>
> sub sum {
> my $arrayref = shift;
> my $total = 0;
> foreach my $element (@$arrayref) {
> $total += $element;
> }
> return $total;
> }
> 1; # <--- don't forget this.
>
>
> 3) Modules
>
> AFAIK use of require for subroutine libraries has been, to a large
> extent, superceded by modules. These take a bit more work to create but
> have many advantages.
>
> perldoc -q "create a module"
I am going to read about subroutine libraries and modules. Thanks for
the reply.
------------------------------
Date: 03 Aug 2006 15:43:01 GMT
From: tinnews@isbd.co.uk
Subject: Re: How probably not to hand over a variable from one perl script to another
Message-Id: <44d21985$0$636$bed64819@news.gradwell.net>
David Squire <David.Squire@no.spam.from.here.au> wrote:
> Markus H?nchen wrote:
>
> [snip]
>
> > since the last index +1 is equal to the number of entries...
>
> As has now been pointed out several times in this thread, this is not
> necessarily the case in Perl.
>
As a sometime (but not frequent) user of perl I sympathise to an
extent with the OP.
The problem (from where I'm looking) with perl is how many, many ways
there are of doing things that hide what is going on, e.g. the
implicit use of $_.
Being used to more picky languages (like C and Java) I never feel safe
with all these things happening 'by themselves'.
--
Chris Green
------------------------------
Date: Thu, 03 Aug 2006 16:12:08 +0100
From: Ian Wilson <scobloke2@infotop.co.uk>
Subject: Re: How probably not to hand over a variable from one perl script to another
Message-Id: <m_ydnaM1qKfSj0_ZRVnygg@bt.com>
Markus Hänchen wrote:
> Hi,
>
> I guess there are better ways to hand over a variable from one perl
> script to another. Knowing very little about Perl I came up with this
> solution:
>
<snip example of using system to invoke one perl script from another>
I can't help thinking that you *may* be missing some very rudimentary
concepts: Subroutines, Libararies and Modules.
1) Subroutines.
You must know about subroutines, is there some reason why your runit.pl
is not made into a subroutine inside your calling perl script (I mean
merge the two perl scripts into a single file)
#!/usr/bin/perl
use strict;
use warnings;
my @test = (12,4,5,10);
print "The sum of @test is ", sum(\@test), "\n";
sub sum {
my $arrayref = shift;
my $total = 0;
foreach my $element (@$arrayref) {
$total += $element;
}
return $total;
}
2) Subroutine libraries
If the runit.pl code needs to be invoked from more than one perl script,
then I'd first make it work as an inline subroutine (as 1. above) then
learn how to separate it into a subroutine library
perldoc -f require
----- 8< ------- myapp.pl
#!/usr/bin/perl
use strict;
use warnings;
require('mylib.pl');
my @test = (12,4,5,10);
print "The sum of @test is ", sum(\@test), "\n";
----- 8< ------- mylib.pl
use strict;
use warnings;
sub sum {
my $arrayref = shift;
my $total = 0;
foreach my $element (@$arrayref) {
$total += $element;
}
return $total;
}
1; # <--- don't forget this.
3) Modules
AFAIK use of require for subroutine libraries has been, to a large
extent, superceded by modules. These take a bit more work to create but
have many advantages.
perldoc -q "create a module"
Hope that helps.
------------------------------
Date: Thu, 03 Aug 2006 16:17:49 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: How probably not to hand over a variable from one perl script to another
Message-Id: <eat42t$6po$1@gemini.csx.cam.ac.uk>
Markus Hänchen wrote:
[snip]
> since the last index +1 is equal to the number of entries...
As has now been pointed out several times in this thread, this is not
necessarily the case in Perl.
DS
------------------------------
Date: Thu, 03 Aug 2006 16:51:23 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: How probably not to hand over a variable from one perl script to another
Message-Id: <eat61r$b9m$1@gemini.csx.cam.ac.uk>
tinnews@isbd.co.uk wrote:
> David Squire <David.Squire@no.spam.from.here.au> wrote:
>> Markus H?nchen wrote:
>>
>> [snip]
>>
>>> since the last index +1 is equal to the number of entries...
>> As has now been pointed out several times in this thread, this is not
>> necessarily the case in Perl.
>>
> As a sometime (but not frequent) user of perl I sympathise to an
> extent with the OP.
>
> The problem (from where I'm looking) with perl is how many, many ways
> there are of doing things that hide what is going on, e.g. the
> implicit use of $_.
>
> Being used to more picky languages (like C and Java) I never feel safe
> with all these things happening 'by themselves'.
>
Well, I guess it's to do with familiarity. I suspect the first users of
vehicles with internal combustion engines might have thought: My god!
There is a really complicated lump of metal right next to me, with
explosions going off in it all the time. Explosions! And I'm sitting
next to it!". With familiarity, it is taken for granted, or even not
thought of at all.
If you were a frequent user of Perl I would guess that you would soon
feel safe with the implicit use of $_ etc.... though messing around with
the start index of arrays *is* evil.
DS
------------------------------
Date: 3 Aug 2006 10:42:15 -0700
From: allenjo5@mail.northgrum.com
Subject: Re: how to "anonymize" Perl script before publishing it?
Message-Id: <1154626935.542596.188150@m73g2000cwd.googlegroups.com>
Nomen Nescio wrote:
> usenet@DavidFilmer.com wrote:
>
> > Nomen Nescio wrote:
> > > I want to publish a few of my Perl programs on usenet but I don't want
> > > it to be obvious who wrote them.
> >
> > You can always use Acme::Bleach to 'clean up' your program:
> > http://search.cpan.org/~dconway/Acme-Bleach-1.12/lib/Acme/Bleach.pm
>
> Ha! I want the program which I'm donating to the public domain to be
> readable and modifiable by other people.
You might also want to look at B::Deparse:
perl -MO=Deparse yourprogram.pl
It reads the bytecode perl produces and creates a perl program out of
it.
------------------------------
Date: 03 Aug 2006 15:02:34 GMT
From: xhoster@gmail.com
Subject: Re: Perl hash of hash efficiency.
Message-Id: <20060803111046.750$YF@newsreader.com>
"tak" <yekasi@gmail.com> wrote:
> > How many things where in the hash at the time you did the
> > print scalar %mainHash? (print scalar keys %mainHash). If it had 150K
> > things in it at the time, than there are 150K/16K or about 10 entries
> > per bucket. Higher than I would expect but not aweful.
> >
>
> At the time I print out scalar keys %mainHash - i had 240k entries in
> it. (This is the one-big-hash implementation). And print scalar keys
> %mainHash reports 160k/230k - not 16 and 23k... i missed out a 0... so
> that means its about 1 entry per slot -- not too much collision?
Right, collisions are not your problem.
> I printed out the scalar keys %mainHash, and each of the subhashes
> AFTER all 240k entries were inserted. This is a cut and paste..
>
> 238348 lines in total..
> Item: @ - Size: 9 - ScalarSize: 7/16
> Item: A - Size: 12750 - ScalarSize: 8859/16384
...
> Item: Z - Size: 4167 - ScalarSize: 3277/8192
> scalar of master_hash is: 27/524288
So it looks like you preallocted the master hash to have 300_000 buckets
(which got rounded up to the next power of two, 525288). There is
certainly no benefit in doing that, as the master hash only holds 27
things. Of course this is irrelevant as we now know there is no reason to
use the two-level has in the first place!
> By looking at the scalarSize and my PF usage - It does seem like it is
> the memory issue, by loading too much data that the system can handle?
Yes. Either loading to much data, or storing too much, or storing it in
an inefficient way.
> Situations like that - Does it matter if i do keys(%mainHash) = 300000
> or not?
It can only make things worse. You are creating 299973 buckets that take
up some amount of memory but which will never be used. If you revert to
the single hash implementation, then pre-allocating that giant hash will
not hurt. It might help, but probably not by a meaningful amount.
Preallocating hashes (or arrays) almost *never* helps in a meaningful way.
I've only seen it help twice in non-toy cases, and both of those were on
older versions of Perl--one with bad hashing function that degenerated when
given keys which were all a multiple of 3, and the other was a
bug/malfeature in the garbage collector.
>
> > Are you using warnings? If so, did you get an uninitialized value
> > warning?
> >
>
> Perhaps not - how do you turn on warnings?
The prefered way is to "use warnings;". On older Perls, you specify
-w on the command line or the shebang line.
#!/usr/bin/perl -w
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Thu, 3 Aug 2006 16:19:19 +0100
From: "kokolo" <koko_loko_0@yahoo.co.uk>
Subject: Re: Recursion
Message-Id: <eat45q$h1n$1@news.al.sw.ericsson.se>
"Paul Lalli" <mritty@gmail.com> wrote in message
news:1154543633.212264.287960@p79g2000cwp.googlegroups.com...
>> sub qs {
> my $array_ref = shift;
> #do stuff to @$array_ref, or $array_ref->[0], etc.
> #do not copy the elements out of @$array_ref;
> #do not return @$array_ref. Just modify it in this subroutine.
> }
>
> $l_ref = \@smaller_numbers;
> qs($l_ref);
> # at this point, @smaller_numbers has whatever modifications
> # you did to @$array_ref in the subroutine.
>
> Paul Lalli
>
I tried like this and I didn't get it working. It seems to me, that changes
that took place in the recursive calls (marked with comments) happened only
within that particular calls.
kokolo
The code:
______________________________________________
print "Enter the number of elements to be sorted: \n";
chomp($size = <STDIN>);
foreach (1..$size) {push @array, int(rand(1000))}
$array_ref = \@array;
$start = time();
qs($array_ref);
$finish = time();
print "The sorted array is:\n @$array_ref \n";
print "The array of $size elements QuickSorted in ",$finish - $start,"
seconds \n";
sub qs {
my $sub_array_ref = shift;
my $pivot = $#$sub_array_ref;
my @smaller_numbers;
my @larger_numbers;
for ($i=0;$i<$pivot;$i++){
if ($sub_array_ref->[$i] <= $sub_array_ref->[$pivot]){
unshift @smaller_numbers, $sub_array_ref->[$i]
}
else {
push @larger_numbers, $sub_array_ref->[$i]
}
}
my $l_ref=\@smaller_numbers;
my $r_ref=\@larger_numbers;
if ($#$l_ref > 0){qs($l_ref)}; ## here, while it's in the subroutine it
looks ok, I put some check out printouts,
##but when it returns,
@smaller_numbers or @$l_ref are unchanged
if ($#$r_ref > 0){qs($r_ref)};
push @$l_ref,($sub_array_ref->[$pivot],@$r_ref);
}
------------------------------
Date: 3 Aug 2006 08:35:45 -0700
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: Recursion
Message-Id: <1154619345.760196.298030@75g2000cwc.googlegroups.com>
kokolo wrote:
> "Paul Lalli" <mritty@gmail.com> wrote in message
> news:1154543633.212264.287960@p79g2000cwp.googlegroups.com...
> >> sub qs {
> > my $array_ref = shift;
> > #do stuff to @$array_ref, or $array_ref->[0], etc.
> > #do not copy the elements out of @$array_ref;
> > #do not return @$array_ref. Just modify it in this subroutine.
> > }
> >
> > $l_ref = \@smaller_numbers;
> > qs($l_ref);
> > # at this point, @smaller_numbers has whatever modifications
> > # you did to @$array_ref in the subroutine.
> >
> I tried like this
No you didn't. You did exactly what I told you not to do. You created
new arrays, and copied values from @$array_ref into them.
> and I didn't get it working. It seems to me, that changes
> that took place in the recursive calls (marked with comments) happened only
> within that particular calls.
Because you didn't change the arrays you passed in. You created new
arrays that were valid only for the scope of that subroutine call.
> print "Enter the number of elements to be sorted: \n";
> chomp($size = <STDIN>);
> foreach (1..$size) {push @array, int(rand(1000))}
>
> $array_ref = \@array;
>
> $start = time();
> qs($array_ref);
> $finish = time();
>
> print "The sorted array is:\n @$array_ref \n";
> print "The array of $size elements QuickSorted in ",$finish - $start,"
> seconds \n";
>
> sub qs {
> my $sub_array_ref = shift;
> my $pivot = $#$sub_array_ref;
> my @smaller_numbers;
> my @larger_numbers;
Here you're declaring two brand new arrays.
> for ($i=0;$i<$pivot;$i++){
>
> if ($sub_array_ref->[$i] <= $sub_array_ref->[$pivot]){
>
> unshift @smaller_numbers, $sub_array_ref->[$i]
Here...
> }
> else {
> push @larger_numbers, $sub_array_ref->[$i]
... and here, you're copying values from @$sub_array_ref into the two
brand new arrays.
> }
> }
>
> my $l_ref=\@smaller_numbers;
> my $r_ref=\@larger_numbers;
Here, you're taking references to the two new arrays.
>
> if ($#$l_ref > 0){qs($l_ref)}; ## here, while it's in the subroutine it
> looks ok, I put some check out printouts,
> ##but when it returns,
> @smaller_numbers or @$l_ref are unchanged
Right. Because in the next iteration of the function, you did not use
@{$l_ref}. You used a brand new @smaller_numbers.
You need to change the *actual* array that is being referred to. Not
make copies.
Paul Lalli
------------------------------
Date: Thu, 3 Aug 2006 17:43:27 +0100
From: "kokolo" <koko_loko_0@yahoo.co.uk>
Subject: Re: Recursion
Message-Id: <eat93g$j2e$1@news.al.sw.ericsson.se>
"Paul Lalli" <mritty@gmail.com> wrote in message
news:1154619345.760196.298030@75g2000cwc.googlegroups.com...
> kokolo wrote:
> > "Paul Lalli" <mritty@gmail.com> wrote in message
> > news:1154543633.212264.287960@p79g2000cwp.googlegroups.com...
> > >> sub qs {
> > > my $array_ref = shift;
> > > #do stuff to @$array_ref, or $array_ref->[0], etc.
> > > #do not copy the elements out of @$array_ref;
> > > #do not return @$array_ref. Just modify it in this subroutine.
> > > }
> > >
> > > $l_ref = \@smaller_numbers;
> > > qs($l_ref);
> > > # at this point, @smaller_numbers has whatever modifications
> > > # you did to @$array_ref in the subroutine.
> > >
>
> > I tried like this
>
> No you didn't. You did exactly what I told you not to do. You created
> new arrays, and copied values from @$array_ref into them.
But I don't know how to do it then. These two arrays (smaller, larger) are
formed within subroutine, only inthere it's decided if they exist or not.
If I understood you correctly, instead of creating new arrays I should
re-use array reference . Then push and unshift to create new sub_arrays
around the pivot are not possible? Beacuse I virtually discard the whole
array passed to the subroutine, I keep the pivot only and I create two new
arrays.
Let me ask this: I realize I misuse references but is it at all possible to
keep the concept as it is ( with the two arrays created in subroutine) and
still use references?
kokolo
------------------------------
Date: Thu, 03 Aug 2006 14:01:55 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Recursion
Message-Id: <g69y7u5g0ks.fsf@CN1374059D0130.kendall.corp.akamai.com>
On 3 Aug 2006, koko_loko_0@yahoo.co.uk wrote:
> But I don't know how to do it then. These two arrays (smaller, larger) are
> formed within subroutine, only inthere it's decided if they exist or not.
> If I understood you correctly, instead of creating new arrays I should
> re-use array reference . Then push and unshift to create new sub_arrays
> around the pivot are not possible? Beacuse I virtually discard the whole
> array passed to the subroutine, I keep the pivot only and I create two new
> arrays.
> Let me ask this: I realize I misuse references but is it at all possible to
> keep the concept as it is ( with the two arrays created in subroutine) and
> still use references?
No. If you create new arrays, you are not dealing with the original
data structure, so sorting those arrays won't sort the original.
Try doing this with numeric offsets:
qs(\@data, $start, $pivot, $end);
then in qs:
# untested example code
sub qs
{
my $data = shift @_;
my $start = shift @_; # start offset of range to be qsorted
my pivot = shift @_; # pivot offset of range to be qsorted
my $end = shift @_; # end offset of range to be qsorted
... examples of usage follow ...
# get element 15 of $data
$data->[15];
...
# swap elements 12 and 22 of $data
($data->[12], $data->[22]) = ($data->[22], $data->[12]);
...
# sort a subrange from inside qs()
qs($data, $newstart, $newpivot, $newend);
...
}
I think the offsets are what you've been missing... If you just pass
a reference, you'll never know what part of it to sort, and if you
make a new array you're not sorting the original.
Ted
------------------------------
Date: Thu, 3 Aug 2006 17:10:13 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: Unicode & Upgrading Perl
Message-Id: <5oj9q3-6gl.ln1@osiris.mauzo.dyndns.org>
Quoth "Bill H" <bill@ts1000.us>:
> Thanks to all who answered the questions I had on Unicode, I have
> learned that I need to upgrade the version of Perl of I have on one of
> my Cobalt Raq4 servers. I currently have 5.005.03 and need to upgrade
> to 5.8. Can anyone give me some hints/pointers on how to go about this
> and where to get the upgrade for this system?
The easiest solution is to use a package provided by your OS vendor, if
such a thing exists. I would be surprised if they don't provide a 5.8
package.
If not, then you need to download perl-5.8.8.tar.gz from CPAN, unzip it
somewhere and follow the install instructions. You will need a C
compiler... I don't know if Raq4s come with one by default.
Ben
--
Although few may originate a policy, we are all able to judge it.
Pericles of Athens, c.430 B.C.
benmorrow@tiscali.co.uk
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 V10 Issue 9556
***************************************
