[30826] in Perl-Users-Digest
Perl-Users Digest, Issue: 2071 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Dec 21 21:09:43 2008
Date: Sun, 21 Dec 2008 18:09:11 -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, 21 Dec 2008 Volume: 11 Number: 2071
Today's topics:
confused a little by use strict <leave.alone@btinternet.com>
Re: confused a little by use strict <noreply@gunnar.cc>
Re: Non-OO interface to mysql <skeldoy@gmail.com>
Re: Non-OO interface to mysql <usenet@larseighner.com>
Re: Non-OO interface to mysql <hjp-usenet2@hjp.at>
Re: Non-OO interface to mysql <kkeller-usenet@wombat.san-francisco.ca.us>
Re: Non-OO interface to mysql <hjp-usenet2@hjp.at>
Re: Non-OO interface to mysql <usenet@larseighner.com>
Re: Non-OO interface to mysql <uri@stemsystems.com>
Re: Non-OO interface to mysql <tim@burlyhost.com>
Re: Non-OO interface to mysql <usenet@larseighner.com>
Re: opening the file at a specific line number. <news@lawshouse.org>
printing out the current URL for current ASP page in Pe <jack_posemsky@yahoo.com>
Re: printing out the current URL for current ASP page i <noreply@gunnar.cc>
Re: Rounding up in perl <hjp-usenet2@hjp.at>
Re: Rounding up in perl <hjp-usenet2@hjp.at>
Re: Rounding up in perl <tadmc@seesig.invalid>
Re: Rounding up in perl sln@netherlands.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 21 Dec 2008 16:58:21 GMT
From: dan <leave.alone@btinternet.com>
Subject: confused a little by use strict
Message-Id: <NAu3l.40416$3Q.30055@newsfe27.ams2>
Howdy,
The code:
use strict;
my $foo = 0;
for $foo (0,1) {
print "$foo\n";
}
print "$foo\n";
outputs
0
1
0
So $foo comes out of the loop unchanged. OK, if thats how it works, then
why complain if I write
use strict;
my $foo = 0;
for $mistake (0,1) {
print "$foo\n";
}
print "$foo\n";
which outputs
Global symbol "$mistake" requires explicit package name ...?
Since it complains, this implies that in the first case, $foo would come
out of the loop with value 1, doesn't it?
------------------------------
Date: Sun, 21 Dec 2008 18:27:41 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: confused a little by use strict
Message-Id: <6r7ckkFfmpl0U1@mid.individual.net>
dan wrote:
> The code:
>
> use strict;
> my $foo = 0;
> for $foo (0,1) {
> print "$foo\n";
> }
> print "$foo\n";
>
> outputs
>
> 0
> 1
> 0
>
> So $foo comes out of the loop unchanged.
The docs refer to it as "implicit localisation". Please read about
foreach loops in "perldoc perlsyn".
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 21 Dec 2008 06:57:51 -0800 (PST)
From: skeldoy <skeldoy@gmail.com>
Subject: Re: Non-OO interface to mysql
Message-Id: <ae0da84f-860f-4c55-8efe-637ea06e1c87@s9g2000prm.googlegroups.com>
On Dec 20, 10:55=A0pm, Lars Eighner <use...@larseighner.com> wrote:
> Just another in a series of periodic requests asking if anyone has run
> across a non-OO interface to MySQL.
You could always create a security nightmare/spaghetti-nest by
invoking the mysql-tool from backticks.. ;)
`mysql -u root database -e "select * from table;"` or something to
that accord.
Still. Not really sure why one would do such a thing. Gonna side with
the "biting of the nuts"-man there.
------------------------------
Date: Sun, 21 Dec 2008 16:03:04 +0000 (UTC)
From: Lars Eighner <usenet@larseighner.com>
Subject: Re: Non-OO interface to mysql
Message-Id: <slrngksq5q.2bpj.usenet@debranded.larseighner.com>
In our last episode,
<ae0da84f-860f-4c55-8efe-637ea06e1c87@s9g2000prm.googlegroups.com>, the
lovely and talented skeldoy broadcast on comp.lang.perl.misc:
> On Dec 20, 10:55 pm, Lars Eighner <use...@larseighner.com> wrote:
>> Just another in a series of periodic requests asking if anyone has run
>> across a non-OO interface to MySQL.
> You could always create a security nightmare/spaghetti-nest by
> invoking the mysql-tool from backticks.. ;)
> `mysql -u root database -e "select * from table;"` or something to
> that accord.
Well, yes, that's how I will go if I have to build it myself. What I asking
is if the functions for parsing the return already exist somewhere.
> Still. Not really sure why one would do such a thing. Gonna side with
> the "biting of the nuts"-man there.
--
Lars Eighner <http://larseighner.com/> usenet@larseighner.com
Bush's third term begins Jan. 20th with an invocation by Rick Warren.
Obama: No hope; No change; More of the Same.
------------------------------
Date: Sun, 21 Dec 2008 20:53:33 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Non-OO interface to mysql
Message-Id: <slrngkt7lt.jmc.hjp-usenet2@hrunkner.hjp.at>
On 2008-12-21 16:03, Lars Eighner <usenet@larseighner.com> wrote:
> In our last episode,
><ae0da84f-860f-4c55-8efe-637ea06e1c87@s9g2000prm.googlegroups.com>, the
> lovely and talented skeldoy broadcast on comp.lang.perl.misc:
>> On Dec 20, 10:55 pm, Lars Eighner <use...@larseighner.com> wrote:
>>> Just another in a series of periodic requests asking if anyone has run
>>> across a non-OO interface to MySQL.
>
>> You could always create a security nightmare/spaghetti-nest by
>> invoking the mysql-tool from backticks.. ;)
>> `mysql -u root database -e "select * from table;"` or something to
>> that accord.
>
> Well, yes, that's how I will go if I have to build it myself. What I asking
> is if the functions for parsing the return already exist somewhere.
Oh my god. That's really the worst way to implement it.
Write simple wrapping functions around DBI, if you prefer to write
$rows = mysql_selectall_arrayref($dbh, "select * from table");
instead of
$rows = $dbh->selectall_arrayref("select * from table");
Or write wrapper functions around the C API if you prefer writing XS to
writing Perl (but then, why would you write in Perl in the first case?).
But parsing the output of mysql is just plainly insane.
hp
------------------------------
Date: Sun, 21 Dec 2008 14:12:41 -0800
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: Non-OO interface to mysql
Message-Id: <qjr226xg7u.ln2@goaway.wombat.san-francisco.ca.us>
On 2008-12-21, Lars Eighner <usenet@larseighner.com> wrote:
> In our last episode,
><Itf3l.18820$iY3.12303@newsfe14.iad>,
> the lovely and talented Tim Greer
> broadcast on comp.lang.perl.misc:
>
>> However, I don't see a reason to seek such a thing out, just to avoid OO
>> (so I assume there's more to the question),
>
> The idea is precisely to avoid OO (best) or at least to have function type
> calls (second best).
What exactly do you hope to gain by avoiding OO?
> Nope, that's it: avoiding OO so far as possible and OO type calls even if
> OO behind the scenes cannot be avoided.
As someone else posted, you could simply write your own function-style
wrappers around the DBI methods. Compared to basically rewriting DBI in
a functional style from scratch, these wrappers would be fairly
straightforward to write.
--keith
--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
------------------------------
Date: Sun, 21 Dec 2008 23:30:15 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Non-OO interface to mysql
Message-Id: <slrngktgro.l5v.hjp-usenet2@hrunkner.hjp.at>
On 2008-12-21 22:12, Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
> On 2008-12-21, Lars Eighner <usenet@larseighner.com> wrote:
>> Nope, that's it: avoiding OO so far as possible and OO type calls even if
>> OO behind the scenes cannot be avoided.
>
> As someone else posted, you could simply write your own function-style
> wrappers around the DBI methods. Compared to basically rewriting DBI in
> a functional style from scratch,
Rewriting DBI in a functional style might be interesting (SQL already
has some properties of functional languages). But Lars doesn't strike me
as a Lisp or Haskell fan.
hp
------------------------------
Date: Sun, 21 Dec 2008 23:31:52 +0000 (UTC)
From: Lars Eighner <usenet@larseighner.com>
Subject: Re: Non-OO interface to mysql
Message-Id: <slrngktkfb.2dbu.usenet@debranded.larseighner.com>
In our last episode, <qjr226xg7u.ln2@goaway.wombat.san-francisco.ca.us>, the
lovely and talented Keith Keller broadcast on comp.lang.perl.misc:
> On 2008-12-21, Lars Eighner <usenet@larseighner.com> wrote:
>> In our last episode,
>><Itf3l.18820$iY3.12303@newsfe14.iad>,
>> the lovely and talented Tim Greer
>> broadcast on comp.lang.perl.misc:
>>
>>> However, I don't see a reason to seek such a thing out, just to avoid OO
>>> (so I assume there's more to the question),
>>
>> The idea is precisely to avoid OO (best) or at least to have function type
>> calls (second best).
> What exactly do you hope to gain by avoiding OO?
1) The horrible slowness and waste of resources.
2) Little ASCII art pictures of arrows in code (especially where the arrows
point the counterintuitive way)
>> Nope, that's it: avoiding OO so far as possible and OO type calls even if
>> OO behind the scenes cannot be avoided.
> As someone else posted, you could simply write your own function-style
> wrappers around the DBI methods. Compared to basically rewriting DBI in
> a functional style from scratch, these wrappers would be fairly
> straightforward to write.
--
Lars Eighner <http://larseighner.com/> usenet@larseighner.com
Bush's third term begins Jan. 20th with an invocation by Rick Warren.
Obama: No hope; No change; More of the Same.
------------------------------
Date: Sun, 21 Dec 2008 19:35:58 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Non-OO interface to mysql
Message-Id: <x7k59toxld.fsf@stemsystems.com>
>>>>> "LE" == Lars Eighner <usenet@larseighner.com> writes:
LE> In our last episode, <qjr226xg7u.ln2@goaway.wombat.san-francisco.ca.us>, the
LE> lovely and talented Keith Keller broadcast on comp.lang.perl.misc:
>> On 2008-12-21, Lars Eighner <usenet@larseighner.com> wrote:
>>> In our last episode,
>>> <Itf3l.18820$iY3.12303@newsfe14.iad>,
>>> the lovely and talented Tim Greer
>>> broadcast on comp.lang.perl.misc:
>>>
>>>> However, I don't see a reason to seek such a thing out, just to avoid OO
>>>> (so I assume there's more to the question),
>>>
>>> The idea is precisely to avoid OO (best) or at least to have function type
>>> calls (second best).
>> What exactly do you hope to gain by avoiding OO?
LE> 1) The horrible slowness and waste of resources.
you don't know how fast it is until you compare it. premature
optimization and all. the DB itself is way slower than any OO perl code
you would use. this is a very silly (which means stupid) argument
defending your point.
also programmer time is way more expensive than cpu time. do you want to
waste all your hours developing this thing or just buy a faster cpu?
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.
>>> Nope, that's it: avoiding OO so far as possible and OO type calls
>>> even if OO behind the scenes cannot be avoided.
that makes less and less sense. what if mysql was written in c++ or uses
some c++? would you avoid it? you have an irrational fear like any other
phobia. it is all in your mind and not in the code.
that being said, OO isn't for every problem but a blanket refusal of all
OO especially for your silly reasons means you aren't a good
programmer. OO is a useful tool but like any tool can be
abused. ignoring OO is just abusing yourself.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Sun, 21 Dec 2008 17:36:24 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: Non-OO interface to mysql
Message-Id: <uaC3l.534$fc3.267@newsfe02.iad>
Lars Eighner wrote:
>
>> What exactly do you hope to gain by avoiding OO?
>
> 1) The horrible slowness and waste of resources.
I know there are certain people that act like OO is going to kill
efficiency, but it will not. There is good OO code and bad non OO
code. The more important aspect is database design. The modules now
are absolutely not going to impose a problem. You could spend a very
long time trying to create an alternative and it still might not be any
faster.
Either way, to have all of the maturity, checking, etc. that the current
modules do, it's going to take a lot longer to develop an alternative
just to not be OO, then it would to just use OO and move onto more
interesting things. If you wish to, by all means, there's nothing
wrong with creating a non OO interface, but I don't think it's
legitimate. It's not horribly slow and it doesn't waste resources. If
you're concerned with speed, why not use C? Why use Perl at all?
> 2) Little ASCII art pictures of arrows in code (especially where the
> arrows point the counterintuitive way)
If you were willing to work with OO code in Perl, it would probably take
only a few hours (though maybe days or weeks, depending on the time you
have and interest, as well as the goal) to get really good at it.
Again, if you want to do it, go for it. I don't see this as a
legitimate debate though. You could probably make something faster
that's non OO, but I doubt that OO is that big of an aspect in this
case and all that work for just avoiding OO seems like the wasted
resources.
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
------------------------------
Date: Mon, 22 Dec 2008 02:03:12 +0000 (UTC)
From: Lars Eighner <usenet@larseighner.com>
Subject: Re: Non-OO interface to mysql
Message-Id: <slrngkttb3.2dbu.usenet@debranded.larseighner.com>
In our last episode,
<x7k59toxld.fsf@stemsystems.com>,
the lovely and talented Uri Guttman
broadcast on comp.lang.perl.misc:
>>>>>> "LE" == Lars Eighner <usenet@larseighner.com> writes:
> LE> In our last episode, <qjr226xg7u.ln2@goaway.wombat.san-francisco.ca.us>, the
> LE> lovely and talented Keith Keller broadcast on comp.lang.perl.misc:
> >> On 2008-12-21, Lars Eighner <usenet@larseighner.com> wrote:
> >>> In our last episode,
> >>> <Itf3l.18820$iY3.12303@newsfe14.iad>,
> >>> the lovely and talented Tim Greer
> >>> broadcast on comp.lang.perl.misc:
> >>>
> >>>> However, I don't see a reason to seek such a thing out, just to avoid OO
> >>>> (so I assume there's more to the question),
> >>>
> >>> The idea is precisely to avoid OO (best) or at least to have function type
> >>> calls (second best).
> >> What exactly do you hope to gain by avoiding OO?
> LE> 1) The horrible slowness and waste of resources.
> you don't know how fast it is until you compare it. premature
> optimization and all. the DB itself is way slower than any OO perl code
> you would use. this is a very silly (which means stupid) argument
> defending your point.
> also programmer time is way more expensive than cpu time. do you want to
> waste all your hours developing this thing or just buy a faster cpu?
> 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
I think you mean c++, not the same thing as c.
> or pl1 which had that arrow style for decades.
> >>> Nope, that's it: avoiding OO so far as possible and OO type calls
> >>> even if OO behind the scenes cannot be avoided.
> that makes less and less sense. what if mysql was written in c++ or uses
> some c++? would you avoid it? you have an irrational fear like any other
> phobia. it is all in your mind and not in the code.
> that being said, OO isn't for every problem but a blanket refusal of all
> OO especially for your silly reasons means you aren't a good
> programmer. OO is a useful tool but like any tool can be
> abused. ignoring OO is just abusing yourself.
> uri
--
Lars Eighner <http://larseighner.com/> usenet@larseighner.com
Bush's third term begins Jan. 20th with an invocation by Rick Warren.
Obama: No hope; No change; More of the Same.
------------------------------
Date: Sun, 21 Dec 2008 19:50:22 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: opening the file at a specific line number.
Message-Id: <1229889198.3566.0@proxy01.news.clara.net>
Nene wrote:
> Hello,
>
> I have a script that runs every 5 minutes and greps for errors in a
> log file.
If you really mean simple grep'ing for strings then I wonder if it might
be easier to write it as a shell script. Each time you grep write the
number of lines to a file (something like wc -l > transient_file) and
then when you wake up the next time do a bit of arithmetic with the
current state of the file and the previous size in "transient_file" to
give a starting line number.
Then you could use "tail -$STARTING_LINE_NUMBER" to leave you with just
the new part and grep that.
Not to be discussed further in this group, I suppose!
--
Henry Law Manchester, England
------------------------------
Date: Sun, 21 Dec 2008 16:50:02 -0800 (PST)
From: Jack <jack_posemsky@yahoo.com>
Subject: printing out the current URL for current ASP page in Perl
Message-Id: <9b919af5-aaaf-4af9-accf-956bc5164dca@u18g2000pro.googlegroups.com>
Hi I am using ASP and Perl and printing the hash %ENV does nothing, as
does $ENV{URLVARIABLES} (With URLVARIABLES being anything..
Any ideas would be great.
Thank you,
Jack
------------------------------
Date: Mon, 22 Dec 2008 02:47:12 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: printing out the current URL for current ASP page in Perl
Message-Id: <6r89t8Fg5isdU1@mid.individual.net>
Jack wrote:
> Subject: printing out the current URL for current ASP page in Perl
>
> I am using ASP and Perl and printing the hash %ENV does nothing, as
> does $ENV{URLVARIABLES} (With URLVARIABLES being anything..
I have no idea how you pick the environment in ASP. If it had been a
Perl CGI script you would have been able to say:
print "http://$ENV{HTTP_HOST}$ENV{REQUEST_URI}\n";
And to print the whole %ENV var:
print "$_ = $ENV{$_}\n" for keys %ENV;
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 21 Dec 2008 14:34:52 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Rounding up in perl
Message-Id: <slrngkshfs.7fc.hjp-usenet2@hrunkner.hjp.at>
On 2008-12-20 16:39, Tim Greer <tim@burlyhost.com> wrote:
> Peter J. Holzer wrote:
>> As Ilya said, truncating is one of several modes of rounding.
>
> Right. I am well aware of that, and I even said so as well before Ilya
> replied.
>
>> It's not that int doesn't round, or that
>> isn't dependable, it just usually isn't the rounding function you
>> want.
>
> And that is what I said previously, it's not probably want you want,
> since it's intent is to truncate (even if that is a method used for
> rounding),
We may have a language problem here. I wouldn't say "truncating is a
method used for rounding", but "truncating is a method of rounding". The
former implies that there is only one way of rounding, and truncating is
not rounding, but can be used to implement rounding. The latter implies
that there are many ways of rounding, and trucating is one of them.
> and I think that it's not as dependable as other solutions,
Again, we may have a language problem. If I say a method is "not
dependable" I mean that it does give the expected result most of the
time, but sometimes it gives the wrong result, and the problem isn't
immediately apparent.
To borrow an example from a recent thread, replacing a symlink with
unlink($link) if -e $link;
symlink($target, $link);
is not dependable. It works almost all of the time, but there is a
possibility that another process creates $link between the time your
process has removed it and tries to recreate it - and unless you are
used to thinking about race conditions, you may not see that.
OTOH, if you do something like
$y = int($x) # round to nearest int
that's not a question of dependability. That will produce the wrong
answer for 50% of all possible values, and it is immediately apparent
from the definition of the int function, that it is the wrong function
to use in this case. (floor and ceil are of course, just as wrong).
Let's assume you want a function which rounds the way you learned in
primary school: Round to nearest integer, and break ties away from zero.
sub common_round_i { my ($x) = @_; return int($x); }
sub common_round_f { my ($x) = @_; return floor($x); }
sub common_round_c { my ($x) = @_; return ceil($x); }
sub common_round_s { my ($x) = @_; return sprintf("%.0f", $x); }
It is immediately clear that the first three implementations don't do
what you want. The first two round 0.9 down (instead of up) and
common_round_c rounds 0.1 up (instead of down).
common_round_s seems to do the right thing at the first glance:
It rounds 0.1 down, it rounds 0.9 up, it rounds 1.5 up. But it rounds
0.5 down (instead of up), and that is probably not immediately apparent
to someone who hasn't learned a bit about numerical methods. So you
could say that using sprintf is "not dependable" (for the problem you
want to solve - there are good reasons for sprintf working the way it
does and at that point you should probably consider the possibility that
"rounding the way you learned in primary school" may not be what you
really need), while the other ways are not only "not dependable", they
are clearly und utterly wrong.
However, you can use the int, floor, and ceil functions to implement
your rounding function:
sub common_round_i2 {
my ($x) = @_;
return int($x + ($x >= 0 ? 0.5 : -0.5));
}
sub common_round_f2 {
my ($x) = @_;
return $x >= 0 ? floor($x + 0.5) : -floor(-$x + 0.5);
}
sub common_round_c2 {
my ($x) = @_;
return $x >= 0 ? -ceil(-$x - 0.5) : ceil($x - 0.5);
}
All of these are correct (as per specification), and there is no
mathematical reason to prefer one over the others. But common_round_i2
is slightly shorter and doen't need any modules, so I'd prefer that from
a Perl programmer's view.
> which I also listed -- which the docs themselves also warn against.
The warning in the documentation is highly confusing. Not really wrong,
but very misleading if you don't already know about these things (and
then you don't need the warning).
hp
------------------------------
Date: Sun, 21 Dec 2008 15:02:21 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Rounding up in perl
Message-Id: <slrngksj3d.ggd.hjp-usenet2@hrunkner.hjp.at>
On 2008-12-20 01:58, Tim Greer <tim@burlyhost.com> wrote:
> Nevertheless, someone I actually used to respect for their contributions
> has resorted to acting like this and aligning their logic with a poster
> that doesn't know what the /x modifer if for.
As they say, even a blind man hits the mark sometimes. Just because sln
writes something it isn't automatically wrong.
hp
------------------------------
Date: Sun, 21 Dec 2008 11:49:18 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Rounding up in perl
Message-Id: <slrngkt0cu.j7c.tadmc@tadmc30.sbcglobal.net>
Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> As they say, even a blind man hits the mark sometimes. Just because sln
> writes something it isn't automatically wrong.
Who would be so foolish as to fall into such a prejudice?
... me, raises hand ...
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Sun, 21 Dec 2008 22:42:39 GMT
From: sln@netherlands.com
Subject: Re: Rounding up in perl
Message-Id: <esgtk4h4t10o145v68vlbc5ua3ht0tahh1@4ax.com>
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.
>
>Here is a Perl ceil/floor equivalent. The first code section
>seems to correctly implement floor by taking into account that
>int() does not use the sign in its process of rounding. The
>second code section with floor, although intuitive is not correct.
>For a full proof, all the values between 2.0 - 2.9 should be checked.
>
>sln
>
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.
Thanks Peter J. Holzer for pointing out the error.
The good thing about this code is it works the same way every time.
Now, back to the show...
sln
==================================================
# ===========================================
# A Perl based Ceil/floor equavelent
# This floor takes the sign into acount
# when rounding.
# - - - - - - - -
use strict;
use warnings;
## test ceil-floor around 0 and between (+-) 2.0 - 3.0
## in .1 increments
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,$z);
for $y (@Test)
{
$z = _ceil( $y );
printf( "The ceil of %s is %f\n", $y, $z );
$z = _ceil( -$y );
printf( "The ceil of -%s is %f\n\n", $y, $z );
}
for $y (@Test)
{
$z = _floor( $y );
printf( "The floor of %s is %f\n", $y, $z );
$z = _floor( -$y );
printf( "The floor of -%s is %f\n\n", $y, $z );
}
sub _ceil {
my $z = int($_[0]);
return $z if ($_[0] == $z || $_[0]<0);
return int($_[0]+1.0);
}
sub _floor {
my $z = int($_[0]);
return $z if ($_[0] == $z || $_[0]>=0);
return int($_[0]-1.0);
}
__END__
The ceil of 0.0 is 0.000000
The ceil of -0.0 is 0.000000
The ceil of 0.1 is 1.000000
The ceil of -0.1 is 0.000000
The ceil of 0.6 is 1.000000
The ceil of -0.6 is 0.000000
The ceil of 2.0 is 2.000000
The ceil of -2.0 is -2.000000
The ceil of 2.1 is 3.000000
The ceil of -2.1 is -2.000000
The ceil of 2.3 is 3.000000
The ceil of -2.3 is -2.000000
The ceil of 2.4 is 3.000000
The ceil of -2.4 is -2.000000
The ceil of 2.5 is 3.000000
The ceil of -2.5 is -2.000000
The ceil of 2.6 is 3.000000
The ceil of -2.6 is -2.000000
The ceil of 2.7 is 3.000000
The ceil of -2.7 is -2.000000
The ceil of 2.8 is 3.000000
The ceil of -2.8 is -2.000000
The ceil of 2.9 is 3.000000
The ceil of -2.9 is -2.000000
The ceil of 3.0 is 3.000000
The ceil of -3.0 is -3.000000
The floor of 0.0 is 0.000000
The floor of -0.0 is 0.000000
The floor of 0.1 is 0.000000
The floor of -0.1 is -1.000000
The floor of 0.6 is 0.000000
The floor of -0.6 is -1.000000
The floor of 2.0 is 2.000000
The floor of -2.0 is -2.000000
The floor of 2.1 is 2.000000
The floor of -2.1 is -3.000000
The floor of 2.3 is 2.000000
The floor of -2.3 is -3.000000
The floor of 2.4 is 2.000000
The floor of -2.4 is -3.000000
The floor of 2.5 is 2.000000
The floor of -2.5 is -3.000000
The floor of 2.6 is 2.000000
The floor of -2.6 is -3.000000
The floor of 2.7 is 2.000000
The floor of -2.7 is -3.000000
The floor of 2.8 is 2.000000
The floor of -2.8 is -3.000000
The floor of 2.9 is 2.000000
The floor of -2.9 is -3.000000
The floor of 3.0 is 3.000000
The floor of -3.0 is -3.000000
------------------------------
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 2071
***************************************
