Math

[Robert Hicks]

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]

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.

 

[Jürgen Exner]

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]

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]

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

 

[Michele Dondi]

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

 

[Sisyphus]

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:ari 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]

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:ari 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

 

[Robert Hicks]

Thank you and thanks for all the answers.

Robert

 

[Brian Blackmore]

Maths!

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

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.

 

[Sisyphus]

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...

According to my Math::BigFloat (version 1.51) documentation you can, for
example:

use Math::BigFloat lib => 'GMP';

and that will, as I understand it, use the GMP integer routines instead of
the (pure perl) M::BI integer routines - so long as Math::BigInt::GMP has
been installed.

I gather that the "BigFloat" calculations are simply "BigInt" calculations,
and that M::BF merely keeps track of where to put the decimal point,
accuracy, precision, etc .... but I haven't looked into it beyond briefly
skimming the M::BF documentation.

Cheers,
Rob

 

[Michele Dondi]

According to my Math::BigFloat (version 1.51) documentation you can, for
example:

use Math::BigFloat lib => 'GMP';

You're right, I overlooked the documentation, possibly because M::BI
mentions this possibility at the very top, while M::BF somewhat later
on.

I gather that the "BigFloat" calculations are simply "BigInt" calculations,
and that M::BF merely keeps track of where to put the decimal point,
accuracy, precision, etc .... but I haven't looked into it beyond briefly
skimming the M::BF documentation.

I think so too, because it says:

: Math with the numbers is done (by default) by a module called
: Math::BigInt::Calc. This is equivalent to saying:


Michele

 

[Michele Dondi]

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.

I must have said this already, but a friend of mine, who does QCD
lattice simulations and is AFAIK very knowledgeable, uses C++ as the
main language for his programs, and he's a skilled C++ programmer...
yet for very critical portions of code he creates libraries in
fortran, which then he links to his C++ programs, because he swears he
can gain some percent of speed, which is relevant in this respect:
just think that he's been given access to some supercomuters and huge
number crunching clusters, and the granted usage time is limited too.


Michele

 

[Michele Dondi]

I think that in order to get something like a number out of perl from
usenet, you would need techniques beyond the Perl Programming Language. So
much idiot shit.

Merl the perl, please! What do you mean? I can get something like a
number out of perl very easily. Nay, a lot of numbers:

perl -le "print $x=($x%2?3*$x+1:$x/2)||int rand~0 while $x!=1"

I don't know what you mean with "from usenet". You can search the
archives for Abigail's Erathostene's Sieve implementation if you like.
Most of my contributions to the OEIS did feature sequences calculated
with Perl... then at some time I stopped and I'm not even on the ML
any more, due to lack of time, but that's another story.


Michele

 

[Brian Blackmore]

On Fri, 20 Jul 2007 03:46:47 +0000 (UTC), Brian Blackmore

I must have said this already, but a friend of mine, who does QCD
lattice simulations and is AFAIK very knowledgeable, uses C++ as the
main language for his programs, and he's a skilled C++ programmer...
yet for very critical portions of code he creates libraries in
fortran, which then he links to his C++ programs, because he swears he
can gain some percent of speed, which is relevant in this respect:
just think that he's been given access to some supercomuters and huge
number crunching clusters, and the granted usage time is limited too.

Yeah, it seems to vary quite a bit depending on what one is actually
doing; doesn't it? It's too bad that OS programmers don't concern
themselves with efficient algorithms any more.

I remember once where we had an algorithm that should have been faster
in assembly, but the GCC optimizer came up with something better than
that for the slow i386 machine. Nevertheless, the simple assembly was
still the better choice for the manufactured chip (not exactly a
surprise).

Oh, and I think I came in a bit late to this thread, so if you said it
already, I missed it. Thanks for the recap.

It's sad that I've never used fortran. Maybe I'll try to fix
that.

 

[Martijn Lievaart]

I remember once where we had an algorithm that should have been faster
in assembly, but the GCC optimizer came up with something better than
that for the slow i386 machine. Nevertheless, the simple assembly was
still the better choice for the manufactured chip (not exactly a
surprise).

Been there, done that. Tried to optimize the most called routine in
assembly in a program written in C. (Yes, I did profile it first.) Turns
out the compiler (Borland C in this case) did a better job of optimizing
than I could.

M4

 

[Robert Hicks]

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


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.

Basically it has to do with the positions of ships. We get emails from
the ships that have lat/lon coordinates and we plot them. We also do
stuff like figure out what ships are within SAR distance and what
ports are close at hand for SAR operations. So spherical trig stuff
comes into play. I don't think "fast" is a requirement as long as we
can get the email, look up the last position, do calculations and then
write back to the db. That is the basics of it.

We currently have c libs with the math and a Perl/XS module that calls
those routines. We are having a horrible time moving that code from PA-
RISC to Itanium (the code is as old as IRIS and PRIME). So we may just
move it all into the Perl realm to make it easier going forward.

Robert

 

[Tad McClellan]

It was an intemperate response rooted in frustration.

Those can have long-lasting consequences, so you should attempt
to avoid them whenever possible.

Have you seen the Posting Guidelines that are posted here frequently?


Be extra cautious when you get upset
Count to ten before composing a followup when you are upset
This is recommended in all Usenet newsgroups. Here in clpmisc, most
flaming sub-threads are not about any feature of Perl at all! They
are most often for what was seen as a breach of netiquette. If you
have lurked for a bit, then you will know what is expected and won't
make such posts in the first place.

But if you get upset, wait a while before writing your followup. I
recommend waiting at least 30 minutes.

Count to ten after composing and before posting when you are upset
After you have written your followup, wait *another* 30 minutes
before committing yourself by posting it. You cannot take it back
once it has been said.

 

[Brian Blackmore]

Basically it has to do with the positions of ships. We get emails from
the ships that have lat/lon coordinates and we plot them. We also do
stuff like figure out what ships are within SAR distance and what
ports are close at hand for SAR operations. So spherical trig stuff
comes into play. I don't think "fast" is a requirement as long as we
can get the email, look up the last position, do calculations and then
write back to the db. That is the basics of it.

I have code that effectively does half of this; alas, it's not ready
for release. Navigation has been a hobby for a while, and there's a
great deal of modelling involved for a couple of the projects I'm
working on. For what you've described, I would expect no particular
loss of speed nor of precision using perl. Because of the data
stream, it's probably better than C in this case.

If you were doing acoustic tomography or processing soundings for
topography, then you'd notice a big difference (whatever "big"
means) in speed. I've found it unfortunate for these applications
that I'm so used to perl that sometimes it takes more time to write
it in C/C++, but there's a line between coding time and processing
time that is eventually crossed and C is the way to go.

At that point, however, you're so deep in it that you might as well just
tie a concrete block to your feet and throw yourself in the river,
because you're never going to come back up.

We currently have c libs with the math and a Perl/XS module that calls
those routines. We are having a horrible time moving that code from PA-
RISC to Itanium (the code is as old as IRIS and PRIME). So we may just
move it all into the Perl realm to make it easier going forward.

I can't imagine anything in there being so complicated that it
couldn't be implemented in either C or Perl in a big hurry. Keep it
around for backup sake or following the MS philosophy that there is
no physical layer, or the Java philosophy that C isn't available on
enough machines so we'll just write JVM in C so Java is... and write
an emulator for PA-RISC on Itanium.

 

[anno4000]

[...]

Basically it has to do with the positions of ships. We get emails from
[...]

We currently have c libs with the math and a Perl/XS module that calls
those routines. We are having a horrible time moving that code from PA-
RISC to Itanium (the code is as old as IRIS and PRIME). So we may just
move it all into the Perl realm to make it easier going forward.

That sounds like a plan. You can do a lot of trigonometry per received
mail message, even in Perl, speed won't be a problem. There's
"Geo:istance - Calculate Distances and Closest Locations" on CPAN.
GIS:istance seems to be the aspiring successor.

Anno