Velocity Reviews - Computer Hardware Reviews

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

Reply
 
 
Ilya Zakharevich
Guest
Posts: n/a
 
      07-22-2007
[A complimentary Cc of this posting was sent to
Robert Hicks
<(E-Mail Removed)>], who wrote in article <(E-Mail Removed) .com>:
> 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.


For some unfathomable reasons, Perl uses non-invertible transformations
between strings and numbers. So if your handling of numbers involves
converting them to strings, then back, the precision will be lost.

perldoc perlnumber

for details.

Hope this helps,
Ilya
 
Reply With Quote
 
 
 
 
Ilya Zakharevich
Guest
Posts: n/a
 
      07-22-2007
[A complimentary Cc of this posting was sent to
Mirco Wahab
<(E-Mail Removed)-halle.de>], who wrote in article <f7n0q3$26ae$(E-Mail Removed)-freiberg.de>:
> From my own experiences: Perl is not *that* slow in
> numerical thinks.


The slowdown due to *literal* translation of a C program to a Perl
program is, in my experience, between 80x and 200x. Whether it is
tolerable depends in the usage pattern.

Hope this helps,
Ilya
 
Reply With Quote
 
 
 
 
Ilya Zakharevich
Guest
Posts: n/a
 
      07-22-2007
[A complimentary Cc of this posting was sent to
Sisyphus
<(E-Mail Removed)>], who wrote in article <46a03093$0$25982$(E-Mail Removed)> :
> According to my Math::BigFloat (version 1.51) documentation you can, for
> example:
>
> use Math::BigFloat lib => 'GMP';


I do not know how it happens now, but some time ago the architecture
of Math::BigInt and Math::BigFloat modules was absolutely broken
performance-wise: AFAIK, instead of *delegating* the work to the
optimized modules, it creates *wrappers* about the optimized stuff.

Since the wrappers are written in Perl, the performance should suffer
a lot - unless you do calculations with madly big numbers (as in
crypto), so each "elementary operation" takes long enough to make
overhead of Perl wrappers is not crucial.

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


Hope this helps,
Ilya
 
Reply With Quote
 
Mirco Wahab
Guest
Posts: n/a
 
      07-22-2007
Ilya Zakharevich wrote:
> [A complimentary Cc of this posting was sent to
> Mirco Wahab
> <(E-Mail Removed)-halle.de>], who wrote in article <f7n0q3$26ae$(E-Mail Removed)-freiberg.de>:
>> From my own experiences: Perl is not *that* slow in
>> numerical thinks.

>
> The slowdown due to *literal* translation of a C program to a Perl
> program is, in my experience, between 80x and 200x. Whether it is
> tolerable depends in the usage pattern.


OK, if the program does depend *only* on
number crunching, the ratio I'd expect
would be around 1:100, as can also can
be seen from the numerical benchmarks
on http://shootout.alioth.debian.org,
eg. http://shootout.alioth.debian.org/de...nbody&lang=all
(planetary body movement simulation)
or http://shootout.alioth.debian.org/de...lbrot&lang=all
(mandelbrot set generation)

Thanks & regards

M.
 
Reply With Quote
 
Sisyphus
Guest
Posts: n/a
 
      07-23-2007

"Ilya Zakharevich" <(E-Mail Removed)> wrote in message
news:f807p7$2p1p$(E-Mail Removed)...
..
..
> So if your handling of numbers involves
> converting them to strings, then back, the precision will be lost.
>


It seems to me that you're saying that the following script will output
"Precision lost" (for some numeric value of $num, at least):

--------------------------
use warnings;
use strict;

my $num = 1.237e-6;
my $str = "$num";

if($num == $str) {print "Precision preserved\n"}
else {print "Precision lost\n"}
--------------------------

Do you have an example of such a value for $num ?

Cheers,
Rob

 
Reply With Quote
 
Jürgen Exner
Guest
Posts: n/a
 
      07-23-2007
Sisyphus wrote:
> "Ilya Zakharevich" <(E-Mail Removed)> wrote in message
>> So if your handling of numbers involves
>> converting them to strings, then back, the precision will be lost.

>
> It seems to me that you're saying that the following script will
> output "Precision lost" (for some numeric value of $num, at least):
>
> --------------------------
> my $num = 1.237e-6;
> my $str = "$num";
>
> if($num == $str) {print "Precision preserved\n"}
> else {print "Precision lost\n"}
> --------------------------
>
> Do you have an example of such a value for $num ?


Oldest suspect in the world:
my $num = 1/3;
and the program above will print
Precision lost

jue


 
Reply With Quote
 
Sisyphus
Guest
Posts: n/a
 
      07-23-2007

"Jürgen Exner" <(E-Mail Removed)> wrote in message
news:5tWoi.423$zJ4.143@trndny03...
..
..
>> It seems to me that you're saying that the following script will
>> output "Precision lost" (for some numeric value of $num, at least):
>>
>> --------------------------
>> my $num = 1.237e-6;
>> my $str = "$num";
>>
>> if($num == $str) {print "Precision preserved\n"}
>> else {print "Precision lost\n"}
>> --------------------------
>>
>> Do you have an example of such a value for $num ?

>
> Oldest suspect in the world:
> my $num = 1/3;
> and the program above will print
> Precision lost
>


Aaah, yes ... I understand. Thanks, jue.

Cheers,
Rob

 
Reply With Quote
 
Brian Blackmore
Guest
Posts: n/a
 
      07-23-2007
Ilya Zakharevich <(E-Mail Removed)> wrote:
> [A complimentary Cc of this posting was sent to
> Robert Hicks
> <(E-Mail Removed)>], who wrote in article <(E-Mail Removed) .com>:
> > 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.


> For some unfathomable reasons, Perl uses non-invertible transformations
> between strings and numbers. So if your handling of numbers involves
> converting them to strings, then back, the precision will be lost.


Yes, but I would question which programming languages don't suffer
from this behavior? As is mentioned by perlnumber, converting from
floating point to string is performed by the C compiler, whence Perl
is at the mercy of the system on which it was compiled. Moreover, I
must admit a bit of childish moronicity here in claiming that I know
of no language whatsoever that stores floats with infinite
precision, whence string conversion is always faulty.

If one uses a quotient field class, well then one is doing symbolic
algebra in one way shape or form, and again I wouldn't place blame
on the Perl numeric types.

Indeed, I was also thinking of something simple like 1/3, but have
you an example of a language where "1/3"=1/3? Or are there so many
that I'm just being dim?

--
Brian Blackmore
blb8 at po dot cwru dot edu
 
Reply With Quote
 
Michele Dondi
Guest
Posts: n/a
 
      07-23-2007
On Mon, 23 Jul 2007 17:52:47 +0000 (UTC), Brian Blackmore
<(E-Mail Removed)> wrote:

>Indeed, I was also thinking of something simple like 1/3, but have
>you an example of a language where "1/3"=1/3? Or are there so many


Do you mean assignment to a constant string? ;-p


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-23-2007
http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de wrote:
> 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.


I'll also add that I don't expect you to have any difficulty with
precision either, whether or not you're converting numbers to
strings and vice-versa. For instance, at fifteen digit precision,
one finds a change of one-one millionth of a second for epoch time,
leading to a 10^-9th change (degrees) in GHA Aries or Sol Azi.

Then again, taking the length of one degree of longitude at the
equator, fifteen digits of precision gives a direct error of 1nm, or
in other words, 10^-13 percent error. Indeed, rounding errors
propagate, etc., but that won't be as notable a problem than the
simple fact that you can't predict path one billion cycles ahead
anyway. Besides that, positioning information should probably not
be considered accurate to more than a meter anyway simply because of
common safety concerns, etc.

If you need to know the position of your ships to more precision
than one nanometer...

--
Brian Blackmore
blb8 at po dot cwru dot edu
 
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