Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Perl Misc (http://www.velocityreviews.com/forums/f67-perl-misc.html)
-   -   Math (http://www.velocityreviews.com/forums/t903888-math.html)

Robert Hicks 07-19-2007 01:46 AM

Math
 
I realize that any math in Perl is probably slower than the same math
in "C" but I was wondering if Perl was as accurate as "C" in math
computations. I don't see why it wouldn't be but I thought I would ask
as a heavy spherical math project is on the horizon.

Robert


John W. Kennedy 07-19-2007 02:25 AM

Re: Math
 
Robert Hicks wrote:
> I realize that any math in Perl is probably slower than the same math
> in "C" but I was wondering if Perl was as accurate as "C" in math
> computations.


It's all the same arithmetic under the covers. But it /will/ be slower,
if pure compute time is the bottleneck.
--
John W. Kennedy
"The poor have sometimes objected to being governed badly; the rich have
always objected to being governed at all."
-- G. K. Chesterton. "The Man Who Was Thursday"

Jürgen Exner 07-19-2007 03:28 AM

Re: Math
 
Robert Hicks wrote:
> I realize that any math in Perl is probably slower than the same math
> in "C" but I was wondering if Perl was as accurate as "C" in math
> computations.


Computational precision depends on many factors like e.g. underlying
hardware, OS architecture, standard libraries, compiler/interpreter
optimization, etc.
But it has nothing to do with the actual programming language(*).

jue

(*): well, at least as long as we exclude symbolic computations in
specialized mathematical programming languages.





Mirco Wahab 07-19-2007 06:36 AM

Re: Math
 
Robert Hicks wrote:
> I realize that any math in Perl is probably slower than the same math
> in "C" but I was wondering if Perl was as accurate as "C" in math
> computations. I don't see why it wouldn't be but I thought I would ask
> as a heavy spherical math project is on the horizon.


From my own experiences: Perl is not *that* slow in
numerical thinks. The speed-problem will show up
if you do some matrix or vector stuff in naíve
Perl expressions because the array handling
is somehow expensive then.

The "accuracy" is, as has been mentioned, in the
normal IEEE "double" range. With only one additional
line of code (eg. "use Math::BigFloat;"), one can get
into almost "arbitary accuracy" mode
(see: http://perldoc.perl.org/Math/BigFloat.html and others).

There is already a Perl extension for vector and matrix
computations, it's called 'PDL' (Perl Data language,
see http://pdl.perl.org/) an an implementation of
GNU-GMP's mpf routines
(http://search.cpan.org/~sisyphus/Math-GMPf-0.14/GMPf.pm)

To get a clearer picture for startup, read:
http://math.arizona.edu/~kerl/doc/perl-talk.pdf

Regards

M.




Michele Dondi 07-19-2007 02:25 PM

Re: Math
 
On Thu, 19 Jul 2007 08:36:50 +0200, Mirco Wahab
<wahab@chemie.uni-halle.de> wrote:

>There is already a Perl extension for vector and matrix
>computations, it's called 'PDL' (Perl Data language,
>see http://pdl.perl.org/) an an implementation of


Since documentation seems not to abound, it is worth mentioning, for
the interested reader, that "lino" is posting a number of articles and
snippets about it in PerlMonks: the following Super Search should
retrieve them; note that it doesn't bring you directly to the results
but simply preloads some search form fields.

http://perlmonks.org/?node_id=3989;BIT=pdl;a=lin0


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Michele Dondi 07-19-2007 02:27 PM

Re: Math
 
On Thu, 19 Jul 2007 01:46:54 -0000, Robert Hicks <sigzero@gmail.com>
wrote:

>Subject: Math


Maths!

>I realize that any math in Perl is probably slower than the same math
>in "C" but I was wondering if Perl was as accurate as "C" in math
>computations. I don't see why it wouldn't be but I thought I would ask
>as a heavy spherical math project is on the horizon.


With the usual caveat about "many parameters to take into account",
there shouldn't be a difference, but possibly for a Perl's dwimmery
not really doing what you want. And when accuracy becomes a relevant
issue, then you can use specialized packages, as hinted to by others.


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Sisyphus 07-19-2007 03:33 PM

Re: Math
 

"Mirco Wahab" <wahab@chemie.uni-halle.de> wrote in message
news:f7n0q3$26ae$1@nserver.hrz.tu-freiberg.de...
> Robert Hicks wrote:
>> I realize that any math in Perl is probably slower than the same math
>> in "C" but I was wondering if Perl was as accurate as "C" in math
>> computations. I don't see why it wouldn't be but I thought I would ask
>> as a heavy spherical math project is on the horizon.

>
> From my own experiences: Perl is not *that* slow in
> numerical thinks.


I'll (tentatively) agree with that.

>
> The "accuracy" is, as has been mentioned, in the
> normal IEEE "double" range. With only one additional
> line of code (eg. "use Math::BigFloat;"), one can get
> into almost "arbitary accuracy" mode
> (see: http://perldoc.perl.org/Math/BigFloat.html and others).
>


But now things *do* start to get noticeably slower ... to the extent that a
"heavy spherical math project" may be better advised to use (instead of
Math::BigFloat) Math::Pari or <plug> Math::MPFR </plug>, both of which make
extensive use of "C" computations.

Of course, it all depends upon the heaviness and sphericality of the math
project :-)

Cheers,
Rob


Michele Dondi 07-19-2007 05:04 PM

Re: Math
 
On Fri, 20 Jul 2007 01:33:52 +1000, "Sisyphus"
<sisyphus1@nomail.afraid.org> wrote:

>But now things *do* start to get noticeably slower ... to the extent that a
>"heavy spherical math project" may be better advised to use (instead of
>Math::BigFloat) Math::Pari or <plug> Math::MPFR </plug>, both of which make
>extensive use of "C" computations.


I was about to tell you that M::BF can use a suitable XS module, if
you tell it so: but I checked and it's not the case, although it
definitely is with M::BI. Too bad...


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Robert Hicks 07-19-2007 06:55 PM

Re: Math
 
Thank you and thanks for all the answers.

Robert


Brian Blackmore 07-20-2007 03:46 AM

Re: Math
 
Michele Dondi <bik.mido@tiscalinet.it> wrote:
> On Thu, 19 Jul 2007 01:46:54 -0000, Robert Hicks <sigzero@gmail.com>
> wrote:


> >Subject: Math


> Maths!


Math! If you need an `s' at the end, it's mathematics!

> >I realize that any math in Perl is probably slower than the same math
> >in "C" but I was wondering if Perl was as accurate as "C" in math
> >computations. I don't see why it wouldn't be but I thought I would ask
> >as a heavy spherical math project is on the horizon.


> With the usual caveat about "many parameters to take into account",
> there shouldn't be a difference, but possibly for a Perl's dwimmery
> not really doing what you want. And when accuracy becomes a relevant
> issue, then you can use specialized packages, as hinted to by others.


Yeah, everyone has pretty much indicated the problems here, but I'll
echo the "it depends on what you're doing". I'm not the expert, but I
have my own arbitrary precision stuff in perl and it's slow, but
that's okay because it is supposed to be slow (figure that one out).
On the other hand, my C matrix routines are faster than PARI.

In my experience, perl is generally slower for heavy number crunching,
but it does well enough if only 25% of your code really has anything
to do with a bunch of numerical processing. If all that processing is
driving some other frontend, then it seems to fair pretty well.

--
Brian Blackmore
blb8 at po dot cwru dot edu


All times are GMT. The time now is 05:54 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.