[25583] in Perl-Users-Digest
Perl-Users Digest, Issue: 7827 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Feb 24 21:05:28 2005
Date: Thu, 24 Feb 2005 18:05:16 -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 Thu, 24 Feb 2005 Volume: 10 Number: 7827
Today's topics:
Re: Annoying Problem with a Basic Perl app and XP Pro <sholden@flexal.cs.usyd.edu.au>
Re: Comparing huge XML Files <junnuthula@yahoo.com>
Re: CPAN problem <xrsr@rogerware.com>
Div/Mod with negatives (Re: Division/math bug in perl?) <snail@localhost.com>
Div/Mod with negatives (Re: Division/math bug in perl?) <snail@localhost.com>
Re: Div/Mod with negatives (Re: Division/math bug in pe <jwkenne@attglobal.net>
Re: Division/math bug in perl? <flavell@ph.gla.ac.uk>
Re: Division/math bug in perl? <comdog@panix.com>
Re: Division/math bug in perl? <jwkenne@attglobal.net>
Re: Division/math bug in perl? <1usa@llenroc.ude.invalid>
Re: Division/math bug in perl? <snail@localhost.com>
Re: glob <jkeen_via_google@yahoo.com>
Re: Having Trouble Recursing a Function <jgibson@mail.arc.nasa.gov>
Re: Having Trouble Recursing a Function <tadmc@augustmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 25 Feb 2005 00:07:10 GMT
From: Sam Holden <sholden@flexal.cs.usyd.edu.au>
Subject: Re: Annoying Problem with a Basic Perl app and XP Pro
Message-Id: <slrnd1sr1e.eh4.sholden@flexal.cs.usyd.edu.au>
On 24 Feb 2005 16:53:48 GMT,
Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
> Sam Holden <sholden@cs.usyd.edu.au> wrote in comp.lang.perl.misc:
>> On 24 Feb 2005 14:13:47 GMT,
>> Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
>> > Dimitri Papoutsis <bastard@uni-koblenz.de> wrote in comp.lang.perl.misc:
>> >
>> >> Definition: Pseudo-trial:
>> >> not even tried to do sth. but babbling as if...
>> >
>> > A trial is an experiment (if it isn't an interrogation). The word you
>> > want is "attempt".
>>
>> A lot of common usage and a few dictionaries disagree with that and
>> include "to make an effort to do" as one of the meanings of
>> try.
>
> The distinction is exactly what I'm getting at, but that's "try". "Trial"
> appears to have a somewhat specialized meaning.
Ahh. I completely missed the "Pseudo-trial" part and saw only the "tried"
part.
--
Sam Holden
------------------------------
Date: 24 Feb 2005 17:24:36 -0800
From: "junnuthala" <junnuthula@yahoo.com>
Subject: Re: Comparing huge XML Files
Message-Id: <1109294676.165910.32400@g14g2000cwa.googlegroups.com>
Thanks for all the replies.
But for a 6MB XML file, having more than 300,000 elements, XML::Parser
module is taking almost 35 minutes to get the parsed result as a tree.
Any suggestions why the XML::Parser is taking so much time to parse a
moderately big file?
-Venkat
------------------------------
Date: Fri, 25 Feb 2005 01:52:51 GMT
From: roger <xrsr@rogerware.com>
Subject: Re: CPAN problem
Message-Id: <Xns9607B5F0A88Crsrrogerwarecom@207.225.159.8>
Thanks.
Yes, I do have $HOME/.cpan created, with a subdirectory sources,
both created automatically the first time I ran perl -MCPAN -e shell.
And, when I run the cpan shell from that directory subsequently,
the files are placed in that directory, but it still fails.
I don't understand why it thinks it is failing to download them when
clearly it is succeeding.
Hmm.
anno4000@lublin.zrz.tu-berlin.de (Anno Siegel) wrote in news:cvlhf3$dr$2
@mamenchi.zrz.TU-Berlin.DE:
> roger <xrsr@rogerware.com> wrote in comp.lang.perl.misc:
>> Robert Sedlacek <phaylon@dunkelheit.at> wrote in
>> news:pan.2005.02.24.18.13.35.591988@dunkelheit.at:
>>
>> > roger wrote:
>> >
>> >> Can anyone help?
>> >
>> > Don't you have any mirrors specified for your cpan?
>> >
>>
>> Thanks for replying.
>>
>> I have added ftp://ftp.mednor.net/pub/mirrors/CPAN/
>> as a mirror, but it makes no difference.
>>
>> And like I say, the files were downloaded and now reside
>> in my current directory.
>
> That isn't where they ought to be. You probably have no .cpan
directory
> configured.
>
> Anno
------------------------------
Date: Thu, 24 Feb 2005 15:48:32 -0800
From: "Snail" <snail@localhost.com>
Subject: Div/Mod with negatives (Re: Division/math bug in perl?)
Message-Id: <cvlp3a$u1q$1@news.astound.net>
A. Sinan Unur wrote:
> "Snail" <snail@localhost.com> wrote in
> news:cvllsb$sai$1@news.astound.net:
>
>> My aplogies. I realize my subject line was very poorly choosen.
>
> I want to join Alan in thanking you for this response. I did
> misinterpret your intentions based on previous experience, and I
> apologize for that response.
No problem, may segfault really, with the subject line (which could
easily cause that implication.) I am thankful there are some
understanding people like yourself and Alan in this group.
:> Snail
------------------------------
Date: Thu, 24 Feb 2005 15:55:45 -0800
From: "Snail" <snail@localhost.com>
Subject: Div/Mod with negatives (Re: Division/math bug in perl?)
Message-Id: <cvlpgr$u77$1@news.astound.net>
John W. Kennedy wrote:
> Actually, C doesn't define the results of / and % unless both
> arguments are positive. It's up to the compiler writer (which
> typically means it's up to the hardware architect's design for the
> "divide" opcode). So Perl is better defined than C in this respect.
> (However, when under the control of "use integer;", Perl works like
> C.)
Thank you for your response. So does this behavior stem from hardware?
Like how a CPU handles it? or? (when you said "hardware architect's
design" above.)
> There are a gazillion programming languages and dialects out there,
> and nearly as many different ways of addressing the
> noninteger-to-integer problem. Be glad that Perl at least defines
> what "int" means; some languages in the past have regarded it as an
> "implementation detail".
I did not realize that c (and c++?) do not define it themselves. If it
is related to hardware as I am now suspecting, it might explain why. But
even so, I don't think it would have been difficult to program the
conversion algorithms to work a certain way. It seem, from what I've
gathered so far in this thread, that that is what Perl does.
As a guess, could it have been for effientcy reasons? (Like in the case
of c.)
:> Snail
------------------------------
Date: Thu, 24 Feb 2005 20:09:38 -0500
From: "John W. Kennedy" <jwkenne@attglobal.net>
Subject: Re: Div/Mod with negatives (Re: Division/math bug in perl?)
Message-Id: <I2vTd.20682$X81.7435@fe08.lga>
Snail wrote:
> John W. Kennedy wrote:
>
>
>>Actually, C doesn't define the results of / and % unless both
>>arguments are positive. It's up to the compiler writer (which
>>typically means it's up to the hardware architect's design for the
>>"divide" opcode). So Perl is better defined than C in this respect.
>>(However, when under the control of "use integer;", Perl works like
>>C.)
>
>
> Thank you for your response. So does this behavior stem from hardware?
> Like how a CPU handles it? or? (when you said "hardware architect's
> design" above.)
The design of C supposes that / and % for integers are mostly used with
positive numbers, and that object code should therefore be generated
that will run as fast as possible with positive numbers. The "divide"
instruction on most architectures will do this easily. But to force the
results for negative numbers to fit any particular pattern will take
extra instructions on some machines. Therefore, C gives the compiler
designer the freedom to create the fastest code for positive numbers, no
matter what the results are for negative numbers, and a well-thought-out
C compiler will normally do that. (Some compilers may include options to
force one philosophy or another.)
>>There are a gazillion programming languages and dialects out there,
>>and nearly as many different ways of addressing the
>>noninteger-to-integer problem. Be glad that Perl at least defines
>>what "int" means; some languages in the past have regarded it as an
>>"implementation detail".
> I did not realize that c (and c++?) do not define it themselves. If it
> is related to hardware as I am now suspecting, it might explain why. But
> even so, I don't think it would have been difficult to program the
> conversion algorithms to work a certain way. It seem, from what I've
> gathered so far in this thread, that that is what Perl does.
Perl does not compile to true object code, so forcing the decision has
only a very minor effect on speed. Forcing a rule on C might make divide
operations expand from about two instructions to about six. Forcing it
in Perl might make it expand from, say, about fifty to about fifty-four.
---
John W. Kennedy
"...if you had to fall in love with someone who was evil, I can see why
it was her."
-- "Alias"
------------------------------
Date: Thu, 24 Feb 2005 23:11:10 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Division/math bug in perl?
Message-Id: <Pine.LNX.4.61.0502242305050.29448@ppepc56.ph.gla.ac.uk>
On Thu, 24 Feb 2005, Snail wrote:
> > Well, I feel motivated to support A.S.U here. I find the tendency
> > to report every trivial problem as "bug in ..." - without apparent
> > reference to any documentation - to be extremely rude and
> > counterproductive.
>
> My aplogies. I realize my subject line was very poorly choosen. I
> did not intend on coming out as rude.
Thank you for this response.
> I only wanted to start a dicussion on why langs like Perl, c, c++
> (and java?) do this sort of division.
I personally would favour an unbiased algorithm, rather than one which
has twice the range of numbers yielding zero as yield any other
integer value. But the important thing is to check the documentation.
all the best
------------------------------
Date: Thu, 24 Feb 2005 17:21:17 -0600
From: brian d foy <comdog@panix.com>
Subject: Re: Division/math bug in perl?
Message-Id: <240220051721170004%comdog@panix.com>
In article <cvleei$on4$1@news.astound.net>, Snail <snail@localhost.com>
wrote:
> Why is this:
>
> $ perl -e 'print (int (-2.6), "\n")'
> -2
>
> Shouldn't it be -3? I thought converting from float to int is supposed
> to give the integer part, which is -3, and not round towards zero,
The docs for int() specifically say that it truncates towards zero.
That works no matter which side of zero you are on.
In my mind, it doesn't think about number lines. It just takes the
digits in the integer portion and discards anything after the
decimal place. It's not that it's supposed to do anything, as long
as it does what the author said he wanted it to do. It's not
a bug if it's doing what it's documented to do.
If you need something else else, you can write it yourself.
--
brian d foy, comdog@panix.com
Subscribe to The Perl Review: http://www.theperlreview.com
------------------------------
Date: Thu, 24 Feb 2005 18:38:31 -0500
From: "John W. Kennedy" <jwkenne@attglobal.net>
Subject: Re: Division/math bug in perl?
Message-Id: <REtTd.8902$vh1.1060@fe11.lga>
Snail wrote:
> Why is this:
>
> $ perl -e 'print (int (-2.6), "\n")'
> -2
>
> Shouldn't it be -3? I thought converting from float to int is supposed
> to give the integer part, which is -3, and not round towards zero, as it
> seems to be doing, resulting in -2? For that matter, why does c/c++ do
> this too?
>
> Any hand calculator I've tried gives -3 for int (-2.6), like a texas
> instruments graphing calc.
>
> To it's credit, perl correctly does mod func correctly:
>
> $ perl -e 'print (-13 % 5, "\n")'
> 2
>
> Where as in c/c++ you get -3, which is mathematically incorrect. (Any
> hand calculator I've tried gives 2 for the above operation.)
Actually, C doesn't define the results of / and % unless both arguments
are positive. It's up to the compiler writer (which typically means it's
up to the hardware architect's design for the "divide" opcode). So Perl
is better defined than C in this respect. (However, when under the
control of "use integer;", Perl works like C.)
There are a gazillion programming languages and dialects out there, and
nearly as many different ways of addressing the noninteger-to-integer
problem. Be glad that Perl at least defines what "int" means; some
languages in the past have regarded it as an "implementation detail".
---
John W. Kennedy
"Give up vows and dogmas, and fixed things, and you may grow like That.
...you may come to think a blow bad, because it hurts, and not because
it humiliates. You may come to think murder wrong, because it is
violent, and not because it is unjust."
-- G. K. Chesterton. "The Ball and the Cross"
------------------------------
Date: Thu, 24 Feb 2005 23:38:33 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Division/math bug in perl?
Message-Id: <Xns9607BDA483E5Aasu1cornelledu@127.0.0.1>
"Snail" <snail@localhost.com> wrote in news:cvllsb$sai$1@news.astound.net:
> My aplogies. I realize my subject line was very poorly choosen.
I want to join Alan in thanking you for this response. I did misinterpret
your intentions based on previous experience, and I apologize for that
response.
Sinan
------------------------------
Date: Thu, 24 Feb 2005 15:45:23 -0800
From: "Snail" <snail@localhost.com>
Subject: Re: Division/math bug in perl?
Message-Id: <cvlotd$tsb$1@news.astound.net>
Alan J. Flavell wrote:
> On Thu, 24 Feb 2005, Snail wrote:
>
>>> Well, I feel motivated to support A.S.U here. I find the tendency
>>> to report every trivial problem as "bug in ..." - without apparent
>>> reference to any documentation - to be extremely rude and
>>> counterproductive.
>>
>> My aplogies. I realize my subject line was very poorly choosen. I
>> did not intend on coming out as rude.
>
> Thank you for this response.
Your very welcome.
>> I only wanted to start a dicussion on why langs like Perl, c, c++
>> (and java?) do this sort of division.
>
> I personally would favour an unbiased algorithm, rather than one which
> has twice the range of numbers yielding zero as yield any other
> integer value. But the important thing is to check the documentation.
Great point. I guess it's a matter of looking at it but this is a great
way of comparing the outcomes on the negative side of zero.
> all the best
You too.
:> Snail
------------------------------
Date: Thu, 24 Feb 2005 23:46:29 GMT
From: Jim Keenan <jkeen_via_google@yahoo.com>
Subject: Re: glob
Message-Id: <pHtTd.62970$8a6.27525@trndny09>
xhoster@gmail.com wrote:
> Jim Keenan <jkeen_via_google@yahoo.com> wrote:
>
>>Are you sure that these are Perl errors?
>
>
> No, they would be perl errors, not Perl errors. That is, errors from
> the implementation of perl (which is implemented in the C language, and
> thus gives C errors, not Perl errors).
>
That was my hunch when I saw the "*** malloc[2396]", but since I don't
know enough C to competently answer questions about it, I spoke cautiously.
In any case, in response to another question by the OP, Sherm Pendley
noted that the OP needs to install X Code. Which makes sense to me,
'cause I know that when I first went to use Perl after I had gotten my
iBook, I was in a panic until I learned (from Randal, dha and others)
about installing those development tools.
jimk
------------------------------
Date: Thu, 24 Feb 2005 15:39:13 -0800
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: Having Trouble Recursing a Function
Message-Id: <240220051539131307%jgibson@mail.arc.nasa.gov>
In article <pan.2005.02.24.22.40.43.424469@spammer.die>, Mark Healey
<die@spammer.die> wrote:
> Can anyone tell me why the following only goes one level deep in the
> directory tree?
>
> I'm stumped
>
>
> #!/usr/bin/perl
>
> use strict;
> use Cwd;
>
> my $cdir;
> my @files;
>
> $cdir = getcwd();
>
> doDir($cdir);
>
> foreach(@files)
> {
> printf("$_\n");
> }
>
> exit;
>
> sub doDir
> {
> my $dir = $_[0];
> printf("####$dir####\n");
> my $fname;
> opendir(DIRHANDLE, $dir);
> my @list = readdir(DIRHANDLE);
> closedir(DIRHANDLE);
> foreach(@list)
> {
> chomp;
> if(-d $_)
This test is checking the existence of a subdirectory in the current
directory. When you are checking the sub-subdirectories in a
subdirectory, this check will fail, because it is looking for that
directory in the current directory, and it doesn't exist there. You
need to check "$dir/$_" instead.
> {
> unless(/\.\.?\z/)
> {
> $fname=$dir.'/'.$_;
> doDir($fname);
> }
> }
> else
> {
> if(/\.mp3\z/)
> {
> $fname=$dir.'/'.$_;
> push(@files, $fname);
> }
> }
> }# end foreach(@list)
> }# end doDir()
Better still would be to use File::Find, a standard module.
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
------------------------------
Date: Thu, 24 Feb 2005 19:06:08 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Having Trouble Recursing a Function
Message-Id: <slrnd1sug0.bio.tadmc@magna.augustmail.com>
Jim Gibson <jgibson@mail.arc.nasa.gov> wrote:
> In article <pan.2005.02.24.22.40.43.424469@spammer.die>, Mark Healey
><die@spammer.die> wrote:
>
>> Can anyone tell me why the following only goes one level deep in the
>> my @list = readdir(DIRHANDLE);
>> if(-d $_)
> You
> need to check "$dir/$_" instead.
Just like it says in the documentation for the function that
the OP is using!
Asking hundreds of people to read the docs to you is not very nice...
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
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 7827
***************************************
