Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Math

Reply
 
 
Sisyphus
Guest
Posts: n/a
 
      07-20-2007

"Michele Dondi" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Fri, 20 Jul 2007 01:33:52 +1000, "Sisyphus"
> <(E-Mail Removed)> 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: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...
>


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

 
Reply With Quote
 
 
 
 
Michele Dondi
Guest
Posts: n/a
 
      07-20-2007
On Fri, 20 Jul 2007 13:48:38 +1000, "Sisyphus"
<(E-Mail Removed)> wrote:

>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
--
{$_=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,
 
Reply With Quote
 
 
 
 
Michele Dondi
Guest
Posts: n/a
 
      07-20-2007
On Fri, 20 Jul 2007 03:46:47 +0000 (UTC), Brian Blackmore
<(E-Mail Removed)> wrote:

>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
--
{$_=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,
 
Reply With Quote
 
Michele Dondi
Guest
Posts: n/a
 
      07-20-2007
On Fri, 20 Jul 2007 02:22:45 -0700, "merl the perl"
<(E-Mail Removed)> wrote:

>> Thank you and thanks for all the answers.

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


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
--
{$_=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,
 
Reply With Quote
 
Brian Blackmore
Guest
Posts: n/a
 
      07-20-2007
Michele Dondi <(E-Mail Removed)> wrote:
> On Fri, 20 Jul 2007 03:46:47 +0000 (UTC), Brian Blackmore
> <(E-Mail Removed)> wrote:


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


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.

--
Brian Blackmore
blb8 at po dot cwru dot edu
 
Reply With Quote
 
Martijn Lievaart
Guest
Posts: n/a
 
      07-20-2007
On Fri, 20 Jul 2007 16:50:20 +0000, Brian Blackmore wrote:

> 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
 
Reply With Quote
 
Robert Hicks
Guest
Posts: n/a
 
      07-20-2007
On Jul 19, 11:46 pm, Brian Blackmore <(E-Mail Removed)> wrote:
> Michele Dondi <(E-Mail Removed)> wrote:
> > On Thu, 19 Jul 2007 01:46:54 -0000, Robert Hicks <(E-Mail Removed)>
> > 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.
>


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

 
Reply With Quote
 
Tad McClellan
Guest
Posts: n/a
 
      07-21-2007
Wade Ward <(E-Mail Removed)> wrote:

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


--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
 
Reply With Quote
 
Brian Blackmore
Guest
Posts: n/a
 
      07-22-2007
Robert Hicks <(E-Mail Removed)> wrote:
> On Jul 19, 11:46 pm, Brian Blackmore <(E-Mail Removed)> wrote:
> > Michele Dondi <(E-Mail Removed)> wrote:
> > > On Thu, 19 Jul 2007 01:46:54 -0000, Robert Hicks <(E-Mail Removed)>
> > > >
> > > >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,...

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


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.

--
Brian Blackmore
blb8 at po dot cwru dot edu
 
Reply With Quote
 
anno4000@radom.zrz.tu-berlin.de
Guest
Posts: n/a
 
      07-22-2007
Robert Hicks <(E-Mail Removed)> wrote in comp.lang.perl.misc:

[...]

> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Math.random() and Math.round(Math.random()) and Math.floor(Math.random()*2) VK Javascript 15 05-02-2010 03:43 PM
Math.min and Math.max for byte / short Philipp Java 9 07-23-2008 12:37 AM
math.h trig functions questions (and some forgotten high school math) Mark Healey C Programming 7 05-22-2006 10:42 AM
Re: Is still math.h the C++ math library ? AciD_X C++ 4 04-01-2004 07:29 PM
Why can I not use: Math a=new Math(); chirs Java 18 03-02-2004 06:00 PM



Advertisments