Math

Discussion in 'Perl Misc' started by Robert Hicks, Jul 19, 2007.

  1. Robert Hicks

    Robert Hicks Guest

    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
    Robert Hicks, Jul 19, 2007
    #1
    1. Advertising

  2. 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"
    John W. Kennedy, Jul 19, 2007
    #2
    1. Advertising

  3. 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.
    Jürgen Exner, Jul 19, 2007
    #3
  4. Robert Hicks

    Mirco Wahab Guest

    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.
    Mirco Wahab, Jul 19, 2007
    #4
  5. On Thu, 19 Jul 2007 08:36:50 +0200, Mirco Wahab
    <-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, Jul 19, 2007
    #5
  6. On Thu, 19 Jul 2007 01:46:54 -0000, Robert Hicks <>
    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,
    Michele Dondi, Jul 19, 2007
    #6
  7. Robert Hicks

    Sisyphus Guest

    "Mirco Wahab" <-halle.de> wrote in message
    news:f7n0q3$26ae$-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
    Sisyphus, Jul 19, 2007
    #7
  8. On Fri, 20 Jul 2007 01:33:52 +1000, "Sisyphus"
    <> 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,
    Michele Dondi, Jul 19, 2007
    #8
  9. Robert Hicks

    Robert Hicks Guest

    Thank you and thanks for all the answers.

    Robert
    Robert Hicks, Jul 19, 2007
    #9
  10. Michele Dondi <> wrote:
    > On Thu, 19 Jul 2007 01:46:54 -0000, Robert Hicks <>
    > 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
    Brian Blackmore, Jul 20, 2007
    #10
  11. Robert Hicks

    Sisyphus Guest

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


    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
    Sisyphus, Jul 20, 2007
    #11
  12. On Fri, 20 Jul 2007 13:48:38 +1000, "Sisyphus"
    <> 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,
    Michele Dondi, Jul 20, 2007
    #12
  13. On Fri, 20 Jul 2007 03:46:47 +0000 (UTC), Brian Blackmore
    <> 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,
    Michele Dondi, Jul 20, 2007
    #13
  14. On Fri, 20 Jul 2007 02:22:45 -0700, "merl the perl"
    <> 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 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
    --
    {$_=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, Jul 20, 2007
    #14
  15. Michele Dondi <> wrote:
    > On Fri, 20 Jul 2007 03:46:47 +0000 (UTC), Brian Blackmore
    > <> 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
    Brian Blackmore, Jul 20, 2007
    #15
  16. 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
    Martijn Lievaart, Jul 20, 2007
    #16
  17. Robert Hicks

    Robert Hicks Guest

    On Jul 19, 11:46 pm, Brian Blackmore <> wrote:
    > Michele Dondi <> wrote:
    > > On Thu, 19 Jul 2007 01:46:54 -0000, Robert Hicks <>
    > > 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
    Robert Hicks, Jul 20, 2007
    #17
  18. Wade Ward <> 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/"
    Tad McClellan, Jul 21, 2007
    #18
  19. Robert Hicks <> wrote:
    > On Jul 19, 11:46 pm, Brian Blackmore <> wrote:
    > > Michele Dondi <> wrote:
    > > > On Thu, 19 Jul 2007 01:46:54 -0000, 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.
    > > >
    > > > 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. :p

    --
    Brian Blackmore
    blb8 at po dot cwru dot edu
    Brian Blackmore, Jul 22, 2007
    #19
  20. Robert Hicks

    -berlin.de Guest

    Robert Hicks <> 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::Distance - Calculate Distances and Closest Locations" on CPAN.
    GIS::Distance seems to be the aspiring successor.

    Anno
    -berlin.de, Jul 22, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. chirs
    Replies:
    18
    Views:
    744
    Chris Uppal
    Mar 2, 2004
  2. AciD_X
    Replies:
    4
    Views:
    8,069
    Jonathan Turkanis
    Apr 1, 2004
  3. Mark Healey
    Replies:
    7
    Views:
    1,451
    Tim Prince
    May 22, 2006
  4. Philipp
    Replies:
    9
    Views:
    1,089
    Mark Space
    Jul 23, 2008
  5. VK
    Replies:
    15
    Views:
    1,115
    Dr J R Stockton
    May 2, 2010
Loading...

Share This Page