[30828] in Perl-Users-Digest
Perl-Users Digest, Issue: 2073 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Dec 22 18:09:39 2008
Date: Mon, 22 Dec 2008 15:09:06 -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 Mon, 22 Dec 2008 Volume: 11 Number: 2073
Today's topics:
memory management <r.ted.byers@gmail.com>
Re: memory management <1usa@llenroc.ude.invalid>
Re: memory management sln@netherlands.com
Re: memory management <tadmc@seesig.invalid>
Re: memory management sln@netherlands.com
Re: memory management <r.ted.byers@gmail.com>
Re: memory management <r.ted.byers@gmail.com>
Re: memory management sln@netherlands.com
Re: memory management <r.ted.byers@gmail.com>
Re: Non-OO interface to mysql <cwilbur@chromatico.net>
Re: Rounding up in perl sln@netherlands.com
Re: Rounding up in perl sln@netherlands.com
Re: Rounding up in perl sln@netherlands.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 22 Dec 2008 10:05:01 -0800 (PST)
From: Ted Byers <r.ted.byers@gmail.com>
Subject: memory management
Message-Id: <e58a033c-c05c-4dd4-85a4-46929bc65308@n10g2000vbl.googlegroups.com>
Activestate's perl 5.10.0 on WXP.
I have recently found a couple of my scripts failing with out of
memory error messages, notably with XML::Twig.
This makes no sense since the files being processed are only of the
order of a few dozen megabytes to a maximum of 100MB, and the system
has 4 GB RAM. The machine is not especially heavily loaded (e.g.,
most of the time, when these scripts fail, they have executed over
night with nothing else running except, of course, the OS - WXP).
Curiously, I have yet to find anything useful in the Activestate
documentation for (Active)Perl.5.10.0 regarding memory management. Is
there anything, or any package, that I can use to tell me what is
going awry and how to fix it? I didn't see any likely candidates
using PPM and CPAN. It would be nice if I could have my script tell
me how much memory it is using, and for which data structures. Or
must I remain effectively blind and just split the task into smaller
tasks until it runs to completion on each?
Thanks
Ted
------------------------------
Date: Mon, 22 Dec 2008 18:42:12 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: memory management
Message-Id: <Xns9B7C8B6471F5Basu1cornelledu@127.0.0.1>
Ted Byers <r.ted.byers@gmail.com> wrote in news:e58a033c-c05c-4dd4-85a4-
46929bc65308@n10g2000vbl.googlegroups.com:
> Activestate's perl 5.10.0 on WXP.
>
> I have recently found a couple of my scripts failing with out of
> memory error messages, notably with XML::Twig.
>
> This makes no sense since the files being processed are only of the
> order of a few dozen megabytes to a maximum of 100MB, and the system
> has 4 GB RAM. The machine is not especially heavily loaded (e.g.,
> most of the time, when these scripts fail, they have executed over
> night with nothing else running except, of course, the OS - WXP).
This seems to be a FAQ:
http://xmltwig.com/xmltwig/XML-Twig-FAQ.html#Q12
http://xmltwig.com/xmltwig/XML-Twig-FAQ.html#Q21
http://tomacorp.com/perl/xml/saxvstwig.html
Reports memory usage of 12M for a 614K input file.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Mon, 22 Dec 2008 18:53:54 GMT
From: sln@netherlands.com
Subject: Re: memory management
Message-Id: <u1ovk45grs38tpe8jtun7cpq2q6adl9lh5@4ax.com>
On Mon, 22 Dec 2008 10:05:01 -0800 (PST), Ted Byers <r.ted.byers@gmail.com> wrote:
>Activestate's perl 5.10.0 on WXP.
>
>I have recently found a couple of my scripts failing with out of
>memory error messages, notably with XML::Twig.
>
>This makes no sense since the files being processed are only of the
>order of a few dozen megabytes to a maximum of 100MB, and the system
>has 4 GB RAM. The machine is not especially heavily loaded (e.g.,
>most of the time, when these scripts fail, they have executed over
>night with nothing else running except, of course, the OS - WXP).
>
>Curiously, I have yet to find anything useful in the Activestate
>documentation for (Active)Perl.5.10.0 regarding memory management. Is
>there anything, or any package, that I can use to tell me what is
>going awry and how to fix it? I didn't see any likely candidates
>using PPM and CPAN. It would be nice if I could have my script tell
>me how much memory it is using, and for which data structures. Or
>must I remain effectively blind and just split the task into smaller
>tasks until it runs to completion on each?
>
>Thanks
>
>Ted
You can check data structure sizes with some Devil:: packages.
use Devel::Size qw( total_size );
# build an array or create objects.. then
print total_size(_reference_), "\n";
Twig does its own special memory management. Mostly it builds
node tree's in memory, but it might have hybrid qualities as well.
This adds tremendous memory overhead, probably on the order of 10-50 to
1, depending on what your doing.
Another consideration is what your doing in the code. Are you making
temporaries all over the place?
By and large, 100MB's of raw data will translate into a possible Gig or
more with all the overhead.
sln
------------------------------
Date: Mon, 22 Dec 2008 13:24:39 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: memory management
Message-Id: <slrngkvqbn.1lm.tadmc@tadmc30.sbcglobal.net>
sln@netherlands.com <sln@netherlands.com> wrote:
> You can check data structure sizes with some Devil:: packages.
But those only work on October 31st...
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Mon, 22 Dec 2008 19:36:32 GMT
From: sln@netherlands.com
Subject: Re: memory management
Message-Id: <tvqvk4ds2i2mmgt9g0d5cmkpc4nf70kpv9@4ax.com>
On Mon, 22 Dec 2008 13:24:39 -0600, Tad J McClellan <tadmc@seesig.invalid> wrote:
>sln@netherlands.com <sln@netherlands.com> wrote:
>
>
>> You can check data structure sizes with some Devil:: packages.
>
>
>But those only work on October 31st...
Oh, maybe just 1 then. I'm not a Devil fan so dunno.
sln
------------------------------
Date: Mon, 22 Dec 2008 12:31:31 -0800 (PST)
From: Ted Byers <r.ted.byers@gmail.com>
Subject: Re: memory management
Message-Id: <1bbf84ab-9ed7-4583-9444-d1441263e3d2@t39g2000prh.googlegroups.com>
On Dec 22, 1:42=A0pm, "A. Sinan Unur" <1...@llenroc.ude.invalid> wrote:
> Ted Byers <r.ted.by...@gmail.com> wrote in news:e58a033c-c05c-4dd4-85a4-
> 46929bc65...@n10g2000vbl.googlegroups.com:
>
> > Activestate's perl 5.10.0 on WXP.
>
> > I have recently found a couple of my scripts failing with out of
> > memory error messages, notably with XML::Twig.
>
> > This makes no sense since the files being processed are only of the
> > order of a few dozen megabytes to a maximum of 100MB, and the system
> > has 4 GB RAM. =A0The machine is not especially heavily loaded (e.g.,
> > most of the time, when these scripts fail, they have executed over
> > night with nothing else running except, of course, the OS - WXP).
>
> This seems to be a FAQ:
>
> http://xmltwig.com/xmltwig/XML-Twig-FAQ.html#Q12
>
> http://xmltwig.com/xmltwig/XML-Twig-FAQ.html#Q21
>
> http://tomacorp.com/perl/xml/saxvstwig.html
>
> Reports memory usage of 12M for a 614K input file.
>
> Sinan
>
> --
> A. Sinan Unur <1...@llenroc.ude.invalid>
> (remove .invalid and reverse each component for email address)
>
> comp.lang.perl.misc guidelines on the WWW:http://www.rehabitation.com/clp=
misc/
Ah, OK. I hadn't thought it specific to Twig since I had seen issues
with memory in other scripts using LWP. I thought maybe Perl, or
Active State's distribution of it, might have some issues, because
each of the scripts that encountered trouble was handling only a few
MB, and ran perfectly when working with contrived data of only a few
hundred K.
Thanks, I'll take a look there too.
------------------------------
Date: Mon, 22 Dec 2008 12:39:01 -0800 (PST)
From: Ted Byers <r.ted.byers@gmail.com>
Subject: Re: memory management
Message-Id: <ac2940c3-de6e-4bf2-8032-f4d1281e1205@n10g2000yqm.googlegroups.com>
On Dec 22, 1:53=A0pm, s...@netherlands.com wrote:
> On Mon, 22 Dec 2008 10:05:01 -0800 (PST), Ted Byers <r.ted.by...@gmail.co=
m> wrote:
> >Activestate's perl 5.10.0 on WXP.
>
> >I have recently found a couple of my scripts failing with out of
> >memory error messages, notably with XML::Twig.
>
> >This makes no sense since the files being processed are only of the
> >order of a few dozen megabytes to a maximum of 100MB, and the system
> >has 4 GB RAM. =A0The machine is not especially heavily loaded (e.g.,
> >most of the time, when these scripts fail, they have executed over
> >night with nothing else running except, of course, the OS - WXP).
>
> >Curiously, I have yet to find anything useful in the Activestate
> >documentation for (Active)Perl.5.10.0 regarding memory management. =A0Is
> >there anything, or any package, that I can use to tell me what is
> >going awry and how to fix it? =A0I didn't see any likely candidates
> >using PPM and CPAN. =A0It would be nice if I could have my script tell
> >me how much memory it is using, and for which data structures. =A0Or
> >must I remain effectively blind and just split the task into smaller
> >tasks until it runs to completion on each?
>
> >Thanks
>
> >Ted
>
> You can check data structure sizes with some Devil:: packages.
>
> use Devel::Size qw( total_size );
> # build an array or create objects.. then
> print total_size(_reference_), "\n";
>
> Twig does its own special memory management. Mostly it builds
> node tree's in memory, but it might have hybrid qualities as well.
> This adds tremendous memory overhead, probably on the order of 10-50 to
> 1, depending on what your doing.
>
> Another consideration is what your doing in the code. Are you making
> temporaries all over the place?
>
> By and large, 100MB's of raw data will translate into a possible Gig or
> more with all the overhead.
>
> sln
Thanks.
Actually, the script giving the most trouble is just using Twig to
parse an XML file and write the data to flat, tab delimited files to
be used to bulk load the data into our DB (but that is done using a
SQL script passed to a command line client in a separate process).
Usually, when this script is executed, there is about half of the 4 GB
of physical memory free, so even with the numbers you give, we ought
to have plenty of memory available. In fact, I have yet to see
anything less than 1.5 GB free memory even when I am working my system
hard (the bottle neck is usually HDD IO, regardless of the language
I'm using).
Thanks again,
Ted
------------------------------
Date: Mon, 22 Dec 2008 21:12:20 GMT
From: sln@netherlands.com
Subject: Re: memory management
Message-Id: <8jvvk41onf8oer6jiav3b9jtot2avnj75j@4ax.com>
On Mon, 22 Dec 2008 12:39:01 -0800 (PST), Ted Byers <r.ted.byers@gmail.com> wrote:
>On Dec 22, 1:53 pm, s...@netherlands.com wrote:
>> On Mon, 22 Dec 2008 10:05:01 -0800 (PST), Ted Byers <r.ted.by...@gmail.com> wrote:
>> >Activestate's perl 5.10.0 on WXP.
>>
>> >I have recently found a couple of my scripts failing with out of
>> >memory error messages, notably with XML::Twig.
>>
>> >This makes no sense since the files being processed are only of the
>> >order of a few dozen megabytes to a maximum of 100MB, and the system
>> >has 4 GB RAM. The machine is not especially heavily loaded (e.g.,
>> >most of the time, when these scripts fail, they have executed over
>> >night with nothing else running except, of course, the OS - WXP).
>>
>> >Curiously, I have yet to find anything useful in the Activestate
>> >documentation for (Active)Perl.5.10.0 regarding memory management. Is
>> >there anything, or any package, that I can use to tell me what is
>> >going awry and how to fix it? I didn't see any likely candidates
>> >using PPM and CPAN. It would be nice if I could have my script tell
>> >me how much memory it is using, and for which data structures. Or
>> >must I remain effectively blind and just split the task into smaller
>> >tasks until it runs to completion on each?
>>
>> >Thanks
>>
>> >Ted
>>
>> You can check data structure sizes with some Devil:: packages.
>>
>> use Devel::Size qw( total_size );
>> # build an array or create objects.. then
>> print total_size(_reference_), "\n";
>>
>> Twig does its own special memory management. Mostly it builds
>> node tree's in memory, but it might have hybrid qualities as well.
>> This adds tremendous memory overhead, probably on the order of 10-50 to
>> 1, depending on what your doing.
>>
>> Another consideration is what your doing in the code. Are you making
>> temporaries all over the place?
>>
>> By and large, 100MB's of raw data will translate into a possible Gig or
>> more with all the overhead.
>>
>> sln
>
>Thanks.
>
>Actually, the script giving the most trouble is just using Twig to
>parse an XML file and write the data to flat, tab delimited files to
>be used to bulk load the data into our DB (but that is done using a
>SQL script passed to a command line client in a separate process).
>
>Usually, when this script is executed, there is about half of the 4 GB
>of physical memory free, so even with the numbers you give, we ought
>to have plenty of memory available. In fact, I have yet to see
>anything less than 1.5 GB free memory even when I am working my system
>hard (the bottle neck is usually HDD IO, regardless of the language
>I'm using).
>
>Thanks again,
>
>Ted
Be careful when you say Twig and Parse in the same sentence.
Although I think Twig does its on parsing on some level, it can
use other Parsers if directed. The unique thing about Twig is its
ability to do its own parsing. How it does that I don't know.
What it means is it has the ability to introduce tools outside of
mainstream SAX parsers. How it does that is unknown to me, I'm not
really interested. This results in the ability to do stream as well as
bufferred processing, culminating in a node tree, possible illusionary
object in the hybrid sense. But the node-tree is the result. There are
performance issues, it can also search, like XPath, and replace, then
rewrite xml. This is no small feat.
I am in the process of doing similar tools, but mine captures, does
SAX, does search and replace with regular expressions and some other stuff.
I can tell you its fairly complicated. The reward though is just phenominal.
I manage memory differently. And I do other things than Twig.
Perhaps you could post a skeleton structure of what it is your doing
and I could run it through my routines.
You could however do this all yourself with a fast SAX parser.
The fastest Parser on the planet is Expat, not the Perl interface to it,
which is 6 times slower, but using C/C++.
Unfortunately, all it does is parse, its really a tremendously impaired work,
lacking any tools whatsoever.
sln
------------------------------
Date: Mon, 22 Dec 2008 14:00:46 -0800 (PST)
From: Ted Byers <r.ted.byers@gmail.com>
Subject: Re: memory management
Message-Id: <dbce8e4d-76f6-4471-b8a5-2be64a32191b@c36g2000prc.googlegroups.com>
On Dec 22, 4:12=A0pm, s...@netherlands.com wrote:
> On Mon, 22 Dec 2008 12:39:01 -0800 (PST), Ted Byers <r.ted.by...@gmail.co=
m> wrote:
> >On Dec 22, 1:53=A0pm, s...@netherlands.com wrote:
> >> On Mon, 22 Dec 2008 10:05:01 -0800 (PST), Ted Byers <r.ted.by...@gmail=
.com> wrote:
> >> >Activestate's perl 5.10.0 on WXP.
>
> >> >I have recently found a couple of my scripts failing with out of
> >> >memory error messages, notably with XML::Twig.
>
> >> >This makes no sense since the files being processed are only of the
> >> >order of a few dozen megabytes to a maximum of 100MB, and the system
> >> >has 4 GB RAM. =A0The machine is not especially heavily loaded (e.g.,
> >> >most of the time, when these scripts fail, they have executed over
> >> >night with nothing else running except, of course, the OS - WXP).
>
> >> >Curiously, I have yet to find anything useful in the Activestate
> >> >documentation for (Active)Perl.5.10.0 regarding memory management. =
=A0Is
> >> >there anything, or any package, that I can use to tell me what is
> >> >going awry and how to fix it? =A0I didn't see any likely candidates
> >> >using PPM and CPAN. =A0It would be nice if I could have my script tel=
l
> >> >me how much memory it is using, and for which data structures. =A0Or
> >> >must I remain effectively blind and just split the task into smaller
> >> >tasks until it runs to completion on each?
>
> >> >Thanks
>
> >> >Ted
>
> >> You can check data structure sizes with some Devil:: packages.
>
> >> use Devel::Size qw( total_size );
> >> # build an array or create objects.. then
> >> print total_size(_reference_), "\n";
>
> >> Twig does its own special memory management. Mostly it builds
> >> node tree's in memory, but it might have hybrid qualities as well.
> >> This adds tremendous memory overhead, probably on the order of 10-50 t=
o
> >> 1, depending on what your doing.
>
> >> Another consideration is what your doing in the code. Are you making
> >> temporaries all over the place?
>
> >> By and large, 100MB's of raw data will translate into a possible Gig o=
r
> >> more with all the overhead.
>
> >> sln
>
> >Thanks.
>
> >Actually, the script giving the most trouble is just using Twig to
> >parse an XML file and write the data to flat, tab delimited files to
> >be used to bulk load the data into our DB (but that is done using a
> >SQL script passed to a command line client in a separate process).
>
> >Usually, when this script is executed, there is about half of the 4 GB
> >of physical memory free, so even with the numbers you give, we ought
> >to have plenty of memory available. =A0In fact, I have yet to see
> >anything less than 1.5 GB free memory even when I am working my system
> >hard (the bottle neck is usually HDD IO, regardless of the language
> >I'm using).
>
> >Thanks again,
>
> >Ted
>
> Be careful when you say Twig and Parse in the same sentence.
> Although I think Twig does its on parsing on some level, it can
> use other Parsers if directed. The unique thing about Twig is its
> ability to do its own parsing. How it does that I don't know.
> What it means is it has the ability to introduce tools outside of
> mainstream SAX parsers. How it does that is unknown to me, I'm not
> really interested. This results in the ability to do stream as well as
> bufferred processing, culminating in a node tree, possible illusionary
> object in the hybrid sense. But the node-tree is the result. There are
> performance issues, it can also search, like XPath, and replace, then
> rewrite xml. This is no small feat.
>
> I am in the process of doing similar tools, but mine captures, does
> SAX, does search and replace with regular expressions and some other stuf=
f.
> I can tell you its fairly complicated. The reward though is just phenomin=
al.
> I manage memory differently. And I do other things than Twig.
>
> Perhaps you could post a skeleton structure of what it is your doing
> and I could run it through my routines.
>
> You could however do this all yourself with a fast SAX parser.
> The fastest Parser on the planet is Expat, not the Perl interface to it,
> which is 6 times slower, but using C/C++.
> Unfortunately, all it does is parse, its really a tremendously impaired w=
ork,
> lacking any tools whatsoever.
>
> sln
OK, I'll work up a skeleton after dinner (once I'm not on the clock).
Basically, I get a data feed, in well formed XML, and I need to get
that data into our DB. This feed consists of over 100 XML files,
ranging from less than 1 kb to several dozen MB. Since I have no
direct connection between the feed and the DB (which lacks the ability
to import XML data), I resorted to reading the XML and writing tab
delimited files, which the DB can bulk load in a flash (it is PDQ with
this bulk load).
Maybe it is blasphemy here, but C++ is one of my favourite programing
languages.
I respect guys like you and your efforts with XML. You're strong in
an area where I am challenged. Once of the things I always hated
doing was writing code to parse and validate input. My forte is in
making numeric algorithms fast (hence my preference for fortran and C+
+). I believe you when you say it is complicated, and would be very
interested in hearing about the rewards you describe as phenomenal.
Maybe I'll develop a taste for it? ;-)
Anyway, this relates to one of the things I find frustrating in modern
application development is that I can define a suite of interrelated
data structures (picture a properly normalized database with dozens
tables). The frustration is that I have to waste time repeating this,
in SQL to set up the tables, in classes in (pick one of C++, Java,
Perl, your favourite OO language) for use in business logic, and then
again in the user interface. And of course, XML can be added to the
mix, for communicating between layers (back end, business layer, GUI,
&c.). The data and relationships in it remain the same and it is
quite tedious to duplicate it in so many languages used in the
different layers.
Thanks
Ted
------------------------------
Date: Sun, 21 Dec 2008 22:46:19 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Non-OO interface to mysql
Message-Id: <868wq87tys.fsf@mithril.chromatico.net>
>>>>> "LE" == Lars Eighner <usenet@larseighner.com> writes:
LE> In our last episode, <x7k59toxld.fsf@stemsystems.com>, the
LE> lovely and talented Uri Guttman broadcast on
LE> comp.lang.perl.misc:
LE> 2) Little ASCII art pictures of arrows in code (especially where
LE> the arrows point the counterintuitive way)
>> just turn your head around and the arrows point in the right
>> way. you have a strange view of coding if that is what really
>> bothers you. don't go near c or pl1 which had that arrow style
>> for decades.
LE> I think you mean c++, not the same thing as c.
You are aware that the -> operator comes from C, no?
foo->bar is syntactic sugar for (*foo).bar.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Mon, 22 Dec 2008 18:17:17 GMT
From: sln@netherlands.com
Subject: Re: Rounding up in perl
Message-Id: <bslvk4pc3qv07qja0anbfl6u635c32s2ib@4ax.com>
On Sun, 21 Dec 2008 22:42:39 GMT, sln@netherlands.com wrote:
>On Thu, 18 Dec 2008 21:28:34 GMT, sln@netherlands.com wrote:
>
>>On Wed, 17 Dec 2008 10:37:22 -0500, David Groff <david.groff@noaa.gov> wrote:
>>
>>>
>>>
>>>Is there more than one function for rounding a
>>>number up in perl?
>>>I tried the ceil() function but get an undefined subroutine
>>>message.
>>
[snip]
>This is amended code and a full proof using standard C ceil/floor
>as a comparison. This output is the perl code equavelent.
>
>The previous versions is erroneous and can't use +- .5 as int()
>rounds to the nearest whole number.
>
>As it is now +- 1.0 is used as well as taking boundry conditions
>into consideration.
>
>The _ceil()/_floor() are eqavelent now. An effort was made towards
>speedy code if thats possible.
>
[snip]
>
>sub _ceil {
> my $z = int($_[0]);
> return $z if ($_[0] == $z || $_[0]<0);
> return int($_[0]+1.0);
not needed ^^^
>}
>sub _floor {
> my $z = int($_[0]);
> return $z if ($_[0] == $z || $_[0]>=0);
> return int($_[0]-1.0);
not needed ^^^
>}
>
>
There is no need for a double call to int().
The last int() is not necessary. So it's speedier,
if there is such a thing.
sln
## -----------------------
## ceil/floor equavelent
## -----------------------
use strict;
use warnings;
## test ceil-floor around 0 and between (+-) 2.0 - 3.0
my @Test = qw(
0.0 0.1 0.6
2.0 2.1 2.3 2.4 2.5
2.6 2.7 2.8 2.9 3.0
);
my $y;
for $y (@Test)
{
printf( "The ceil of %s is %f\n", $y, _ceil( $y ) );
printf( "The ceil of -%s is %f\n\n", $y, _ceil( -$y ) );
}
for $y (@Test)
{
printf( "The floor of %s is %f\n", $y, _floor( $y ) );
printf( "The floor of -%s is %f\n\n", $y, _floor( -$y ) );
}
sub _ceil {
my $z = int($_[0]);
return $z if ($_[0] == $z || $_[0] < 0.0);
return $z+1.0;
}
sub _floor {
my $z = int($_[0]);
return $z if ($_[0] == $z || $_[0] >= 0.0);
return $z-1.0;
}
__END__
------------------------------
Date: Mon, 22 Dec 2008 19:44:21 GMT
From: sln@netherlands.com
Subject: Re: Rounding up in perl
Message-Id: <3drvk45ifsh590em47nd338rt9b47prjfa@4ax.com>
On Mon, 22 Dec 2008 18:17:17 GMT, sln@netherlands.com wrote:
>On Sun, 21 Dec 2008 22:42:39 GMT, sln@netherlands.com wrote:
>
>>On Thu, 18 Dec 2008 21:28:34 GMT, sln@netherlands.com wrote:
>>
>>>On Wed, 17 Dec 2008 10:37:22 -0500, David Groff <david.groff@noaa.gov> wrote:
>>>
>>>>
>>>>
>>>>Is there more than one function for rounding a
>>>>number up in perl?
>>>>I tried the ceil() function but get an undefined subroutine
>>>>message.
>>>
>[snip]
>>This is amended code and a full proof using standard C ceil/floor
>>as a comparison. This output is the perl code equavelent.
>>
>>The previous versions is erroneous and can't use +- .5 as int()
>>rounds to the nearest whole number.
>>
>>As it is now +- 1.0 is used as well as taking boundry conditions
>>into consideration.
>>
>>The _ceil()/_floor() are eqavelent now. An effort was made towards
^^^^^^^^^
equivalent
Not sure about the spelling. I'm dislexic so it looks right to me.
sln
------------------------------
Date: Mon, 22 Dec 2008 20:48:52 GMT
From: sln@netherlands.com
Subject: Re: Rounding up in perl
Message-Id: <gluvk4lto36ceobh17puk32idkfn4jpva3@4ax.com>
On Mon, 22 Dec 2008 18:17:17 GMT, sln@netherlands.com wrote:
>On Sun, 21 Dec 2008 22:42:39 GMT, sln@netherlands.com wrote:
>
>>On Thu, 18 Dec 2008 21:28:34 GMT, sln@netherlands.com wrote:
>>
>>>On Wed, 17 Dec 2008 10:37:22 -0500, David Groff <david.groff@noaa.gov> wrote:
>>>
>>>>
>>>>
>>>>Is there more than one function for rounding a
>>>>number up in perl?
>>>>I tried the ceil() function but get an undefined subroutine
>>>>message.
>>>
>[snip]
>>This is amended code and a full proof using standard C ceil/floor
>>as a comparison. This output is the perl code equavelent.
>>
>>The previous versions is erroneous and can't use +- .5 as int()
>>rounds to the nearest whole number.
>>
>>As it is now +- 1.0 is used as well as taking boundry conditions
>>into consideration.
>>
>>The _ceil()/_floor() are eqavelent now. An effort was made towards
>>speedy code if thats possible.
>>
>[snip]
>>
>>sub _ceil {
>> my $z = int($_[0]);
>> return $z if ($_[0] == $z || $_[0]<0);
>> return int($_[0]+1.0);
> not needed ^^^
>>}
>>sub _floor {
>> my $z = int($_[0]);
>> return $z if ($_[0] == $z || $_[0]>=0);
>> return int($_[0]-1.0);
> not needed ^^^
>>}
>>
>>
>There is no need for a double call to int().
>The last int() is not necessary. So it's speedier,
>if there is such a thing.
>
[snip]
>
>sub _ceil {
> my $z = int($_[0]);
> return $z if ($_[0] == $z || $_[0] < 0.0);
> return $z+1.0;
>}
>sub _floor {
> my $z = int($_[0]);
> return $z if ($_[0] == $z || $_[0] >= 0.0);
> return $z-1.0;
>}
>
Even better. Random statistics suggests ceil/floor will
not be called on boundries more than otherwise.
Therefore, the speediest solution possible is to check for
otherwise first. This will eliminate unecesarry boundry checks
in conditions that statistically predict other wise.
Speedier still, if there is such a thing.
sub _ceil {
my $z = int($_[0]);
return $z if ($_[0] < 0.0 || $_[0] == $z);
return $z+1.0;
}
sub _floor {
my $z = int($_[0]);
return $z if ($_[0] >= 0.0 || $_[0] == $z);
return $z-1.0;
}
Typically, this is the least common denominator conditional
logic that would be used in the C library if its not of
a mathematical nature in its assembly derivation.
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:
#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 V11 Issue 2073
***************************************
