[30759] in Perl-Users-Digest
Perl-Users Digest, Issue: 2004 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Nov 25 16:09:48 2008
Date: Tue, 25 Nov 2008 13:09:12 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 25 Nov 2008 Volume: 11 Number: 2004
Today's topics:
Re: File::Find and error detection <steffl@bigfoot.com>
Re: File::Find and error detection <someone@example.com>
Re: Function calls using ampersand & in Perl, what is i <jurgenex@hotmail.com>
help with callbacks (?) <leave.alone@btinternet.com>
Re: help with callbacks (?) sln@netherlands.com
Imager with UTF8 <jcharth@gmail.com>
Re: Imager with UTF8 <smallpond@juno.com>
Re: Imager with UTF8 <jcharth@gmail.com>
Re: Imager with UTF8 <RedGrittyBrick@spamweary.invalid>
Mysql -> Perl - MS-Excel ? <noemail@nothere.com>
Package Installation - can it be done locally? <noemail@nothere.com>
Re: The end of dynamic scope <xueweizhong@gmail.com>
Re: win32 vs linux (bignum) <nema@yahoo.com>
Re: win32 vs linux (bignum) <jurgenex@hotmail.com>
Re: win32 vs linux (bignum) sln@netherlands.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 25 Nov 2008 11:25:21 -0800
From: Erik Steffl <steffl@bigfoot.com>
Subject: Re: File::Find and error detection
Message-Id: <A6udnVtoApK_zLHUnZ2dnUVZ_gCdnZ2d@posted.rawbandwidth>
Tad J McClellan wrote:
> Erik Steffl <steffl@bigfoot.com> wrote:
>
>> Read the docs however I cannot find a way to detect errors when using
>> File::Find module - it prints the errors to stdout
>
>
> It prints the messages to STDERR (like it is supposed to).
supposed to?
printing error messages is acceptable for scripts/programs but a
function/module/library should provide return value, exception, status
variable, callback or something of that nature so that script that uses
it can figure out what's wrong and decide how to handle it.
>> but there doesn't
>> seem to be a way to detect that errors occured, e.g. permission error etc.
>
>> eval {
>> find(\&wanted, $dir);
>> };
>> if($@) {
>> chomp($@);
>> die "error from File::Find::find [$@]\n";
>> }
>
>
>> So I see there is a problem but script is unaware of it. It seems
>> like a somewhat unforgivable limitation, what am I missing?
>
>
> The return value from find().
hmmm... not mentioned in docs, is it there to stay or is it just a
coincidence?
> Replace the code above with something like:
>
> {
> local *STDERR;
> my $err;
> open STDERR, '>', \$err or die "could not capture STDERR $!";
>
> if (find(\&wanted, $dir) ) {
> print "find ran OK\n";
> }
> else {
> print "problem running find: $err\n";
> }
> }
that's certainly possible however it does not solve the problem, I am
not only interested whether it ran ok or not but exactly where/why it
failed (at the point of failure instead of after everything is done) and
ability to stop or continue processing if it fails.
and of course, I want to redirect STDERR to log... (if wanted prints
to stderr...)
erik
------------------------------
Date: Tue, 25 Nov 2008 12:35:09 -0800
From: "John W. Krahn" <someone@example.com>
Subject: Re: File::Find and error detection
Message-Id: <1kZWk.381$VX5.153@newsfe14.iad>
Erik Steffl wrote:
> Tad J McClellan wrote:
>> Erik Steffl <steffl@bigfoot.com> wrote:
>>
>>> Read the docs however I cannot find a way to detect errors when
>>> using File::Find module - it prints the errors to stdout
>>
>>
>> It prints the messages to STDERR (like it is supposed to).
>
> supposed to?
>
> printing error messages is acceptable for scripts/programs but a
> function/module/library should provide return value, exception, status
> variable, callback or something of that nature so that script that uses
> it can figure out what's wrong and decide how to handle it.
>
>>> but there doesn't seem to be a way to detect that errors occured,
>>> e.g. permission error etc.
>>
>>> eval {
>>> find(\&wanted, $dir);
>>> };
>>> if($@) {
>>> chomp($@);
>>> die "error from File::Find::find [$@]\n";
>>> }
>>
>>
>>> So I see there is a problem but script is unaware of it. It seems
>>> like a somewhat unforgivable limitation, what am I missing?
>>
>>
>> The return value from find().
>
> hmmm... not mentioned in docs, is it there to stay or is it just a
> coincidence?
If you read the source for File::Find you will find that find() does not
in fact return a value (at least on the version I have here.)
John
--
Perl isn't a toolbox, but a small machine shop where you
can special-order certain sorts of tools at low cost and
in short order. -- Larry Wall
------------------------------
Date: Tue, 25 Nov 2008 07:49:32 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Function calls using ampersand & in Perl, what is it?
Message-Id: <qf7oi4985tj1ig50diguvj5lo1npc1vvno@4ax.com>
rthangam <ramesh.thangamani@gmail.com> wrote:
>Yeah only that is the difference. &foo() passes @_ to foo() subroutine
>from the caller, but foo() doesn't pass it.
No, it is not. The ampersand overrides prototypes.
jue
------------------------------
Date: Tue, 25 Nov 2008 19:32:41 GMT
From: dan <leave.alone@btinternet.com>
Subject: help with callbacks (?)
Message-Id: <tpYWk.27952$hv.26404@newsfe13.ams2>
hi,
Firstly, I'm not sure if this post is about callbacks, but here goes.
I have two modules, in moduleA I have
$self->{_coderef} = undef; # and later on...
$self->{_coderef}->sayhello if defined $self->{_coderef};
moduleB contains the subroutine
sub sayhello {
print 'hello';
}
Now I can write a script that says
my $testA = new moduleA;
my $testB = new moduleB;
$testA->{_coderef} = $testB;
Now the code
$self->{_coderef}->sayhello if defined $self->{_coderef};
prints 'hello'.
OK so far so good, but now I wonder if there is a way I can change
moduleA so that it does not contain the string 'sayhello'. Instead the
script passes the subroutine name to moduleA. I have tried various things
but so far no luck.
Any ideas? Sorry no actual code.
dan
------------------------------
Date: Tue, 25 Nov 2008 20:10:31 GMT
From: sln@netherlands.com
Subject: Re: help with callbacks (?)
Message-Id: <9rmoi49827g0fmgm0dh39vmtvu99iuqj6c@4ax.com>
On Tue, 25 Nov 2008 19:32:41 GMT, dan <leave.alone@btinternet.com> wrote:
>hi,
>
>Firstly, I'm not sure if this post is about callbacks, but here goes.
>
>I have two modules, in moduleA I have
>
>$self->{_coderef} = undef; # and later on...
>$self->{_coderef}->sayhello if defined $self->{_coderef};
>
>moduleB contains the subroutine
>
>sub sayhello {
> print 'hello';
>}
>
>Now I can write a script that says
>
>my $testA = new moduleA;
>my $testB = new moduleB;
>$testA->{_coderef} = $testB;
>
>Now the code
>
>$self->{_coderef}->sayhello if defined $self->{_coderef};
>
>prints 'hello'.
>
>OK so far so good, but now I wonder if there is a way I can change
>moduleA so that it does not contain the string 'sayhello'. Instead the
>script passes the subroutine name to moduleA. I have tried various things
>but so far no luck.
>
>Any ideas? Sorry no actual code.
>
>dan
From ModuleA:
$self->{_coderef}->sayhello
is really:
$testB->sayhello()
So Dumper $self->{_coderef} would probably reveal an
instance object $testB, of class type ModuleB.
Then the actual call would be ModuleB::sayhello($testB)
This is a runtime where $self->{_coderef} should contain a
instance of that type class.
Maybe it could be done in an eval, I don't know. There is
probably a way.
Did you try something like this?
$call = "\$self->{_coderef}->$methodname";
eval $call;
Not sure.
------------------------------
Date: Tue, 25 Nov 2008 07:31:19 -0800 (PST)
From: joe <jcharth@gmail.com>
Subject: Imager with UTF8
Message-Id: <4e8a6dbe-010b-4294-95c7-d889a58207db@v4g2000yqa.googlegroups.com>
Hello. Does anyone know if I can print japanese text with imager. This
is what i did but so far it prints numbers and symbols, no japanese
characters. THanks.
my $font = Imager::Font->new(
file => '/usr/share/fonts/truetype/freefont/FreeSans.ttf',
index => 0,
color => $blue,
size => 10.5,
aa => 1);
$img->string(
font=>$font,
text=>$line2,
x=>$x2,
y=>75);
------------------------------
Date: Tue, 25 Nov 2008 09:09:28 -0800 (PST)
From: smallpond <smallpond@juno.com>
Subject: Re: Imager with UTF8
Message-Id: <9e42bd34-3fe8-47ce-9c11-30f9b9113623@d32g2000yqe.googlegroups.com>
On Nov 25, 10:31 am, joe <jcha...@gmail.com> wrote:
> Hello. Does anyone know if I can print japanese text with imager. This
> is what i did but so far it prints numbers and symbols, no japanese
> characters. THanks.
>
> my $font = Imager::Font->new(
> file => '/usr/share/fonts/truetype/freefont/FreeSans.ttf',
> index => 0,
> color => $blue,
> size => 10.5,
> aa => 1);
>
> $img->string(
> font=>$font,
> text=>$line2,
> x=>$x2,
> y=>75);
FreeSans has Japanese?
------------------------------
Date: Tue, 25 Nov 2008 10:15:07 -0800 (PST)
From: joe <jcharth@gmail.com>
Subject: Re: Imager with UTF8
Message-Id: <4093d56f-1b49-49b4-8fc1-8258f64221df@r40g2000yqj.googlegroups.com>
I doubt there is a ttf with many languages. It works great with
english not sure what to do here I have found a couple of posts but no
details on how to implement it. Does imager have a built in font with
all the languages? thanks
On Nov 25, 12:09=A0pm, smallpond <smallp...@juno.com> wrote:
> On Nov 25, 10:31 am, joe <jcha...@gmail.com> wrote:
>
>
>
> > Hello. Does anyone know if I can print japanese text with imager. This
> > is what i did =A0but so far it prints =A0numbers and symbols, no japane=
se
> > characters. THanks.
>
> > my $font =3D Imager::Font->new(
> > =A0 =A0file =A0=3D> '/usr/share/fonts/truetype/freefont/FreeSans.ttf',
> > =A0 =A0index =3D> 0,
> > =A0 =A0color =3D> $blue,
> > =A0 =A0size =A0=3D> 10.5,
> > =A0 =A0aa =A0 =A0=3D> 1);
>
> > $img->string(
> > =A0 =A0font=3D>$font,
> > =A0 =A0text=3D>$line2,
> > =A0 =A0x=3D>$x2,
> > =A0 =A0y=3D>75);
>
> FreeSans has Japanese?
------------------------------
Date: Tue, 25 Nov 2008 20:15:08 +0000
From: RedGrittyBrick <RedGrittyBrick@spamweary.invalid>
Subject: Re: Imager with UTF8
Message-Id: <gghmci$3o4$1@news.motzarella.org>
joe wrote:
> On Nov 25, 12:09 pm, smallpond <smallp...@juno.com> wrote:
>> On Nov 25, 10:31 am, joe <jcha...@gmail.com> wrote:
>>
>>> Hello. Does anyone know if I can print japanese text with imager. This
>>> is what i did but so far it prints numbers and symbols, no japanese
>>> characters. THanks.
>>> my $font = Imager::Font->new(
>>> file => '/usr/share/fonts/truetype/freefont/FreeSans.ttf',
>>> index => 0,
>>> color => $blue,
>>> size => 10.5,
>>> aa => 1);
>>> $img->string(
>>> font=>$font,
>>> text=>$line2,
>>> x=>$x2,
>>> y=>75);
>> FreeSans has Japanese?
>
> I doubt there is a ttf with many languages.
"supporting most major code pages and character sets in modern use ...
Ascender Uni is a 39MB TrueType (TTF) font with approximately 53,000
glyphs" - http://www.ascenderfonts.com/font/ascender-uni.aspx
Arial Unicode MS also has over 50,000 glyphs.
Bitstream Cyberbit has over 10,000 glyphs
...
Not that I'm recommending the idea of pan-unicode fonts. I believe there
are significant issues for the CJK character sets (which I think may
need to have different language-specific glyphs for many Unicode
codepoints). This might or might not be what joe's question is about.
--
RGB
------------------------------
Date: Tue, 25 Nov 2008 13:31:04 -0500
From: me <noemail@nothere.com>
Subject: Mysql -> Perl - MS-Excel ?
Message-Id: <lueoi4dlbssnpsemt01pf4po5i36fir7u1@4ax.com>
A customer of mine wants to create an excel spreadsheet directly form
a MYSQL database. From the poking around I did, it seems like I would
need to have the package Spreadsheet::WriteExcel installed.
Are there any other alternative packages/options, or is that the only
choice?
Thanks,
------------------------------
Date: Tue, 25 Nov 2008 13:36:42 -0500
From: me <noemail@nothere.com>
Subject: Package Installation - can it be done locally?
Message-Id: <h3hoi4thotlrdv3ef189b4ase1pto3n147@4ax.com>
If I need to use a package that is not available on a shared server
can I install that locally without the use of a system account? Or do
packages always have to be installed at the system level or with
elevated privs that I won't have?
In this case, the package is Spreadsheet::WriteExcel - but I am also
interested in the options when the package is something else, e.g.
Net::SMTP, etc.
Thanks,
------------------------------
Date: Tue, 25 Nov 2008 08:29:47 -0800 (PST)
From: Todd <xueweizhong@gmail.com>
Subject: Re: The end of dynamic scope
Message-Id: <8bfc1270-3a21-43d6-aab3-4756ab4a959b@i24g2000prf.googlegroups.com>
Finally, i got the answer using -MTerse to check the op tree and the
PP codes.
1. IF case
`if (A) { B }' is equal as:
A and B
so here there is no new scope generated.
2. WHILE case
But for `while (local $a) { B}' it's parsed as:
it's enclosed in enterloop .. leaveloop, a real dynamic save stack
exists.
For my variable, it's compile time bounded based on lexical '{' '}'
text only, no dynamic scope create needed, so it's compile time only
scope.
Feel good to get rid of this frustration. :)
-Todd
------------------------------
Date: Tue, 25 Nov 2008 15:30:13 +0100
From: turkish <nema@yahoo.com>
Subject: Re: win32 vs linux (bignum)
Message-Id: <ggh25m$hfk$1@ss408.t-com.hr>
sisyphus wrote:
>> I get different results when running same algorithm on different
>> platforms. What went so terribly wrong here? :)
>>
>
> You used bignum - that's what "went wrong" :-)
:)
> Afaict, both $brojnik and $nazivnik (is that a political symbol ?) are
No, these are another terms for numerator and denominator. :)
> calculated to the same value on both platforms, but it's the division
> ($brojnik/$nazivnik) that creates the difference.
Yes, and it seems that problem goes beyond linux vs windows.
Dividing same large numbers using python/java gives correct result while
perl/ruby/php are wrong regardless of the OS.
> Taking a Devel::Peek::Dump() of the returned value ($brojnik/
> $nazivnik) reveals some different field settings between linux and
> win32 - which might be worth investigating.
> It should also be possible to create a simpler demo of the problem -
> but I failed in that quest, too :-)
>
> This is definitely worthy of a bug report - though a simpler demo for
> that bug report would be preferable.
use bignum;
my ($n, $d) = <DATA>;
chomp($n, $d);
print $n/$d;
__DATA__
40238726007709377354370243392300398571937486421071463254379991042993851239862902059204420848696940480047998861019719605863166687299480855890132382966994459099742450408707375991882362772718873251977950595099527612087497546249704360141827809464649629105639388743788648733711918104582578364784997701247663288983595573543251318532395846307555740911426241747434934755342864657661166779739666882029120737914385371958824980812686783837455973174613608537953452422158659320192809087829730843139284440328123155861103697680135730421616874760967587134831202547858932076716913244842623613141250878020800026168315102734182797770478463586817016436502415369139828126481021309276124489635992870511496497541990934222156683257208082133318611681155361583654698404670897560290095053761647584772842188967964624494516076535340819890138544248798495995331910172335555660213945039973628075013783761530712776192684903435262520001588853514733161170210396817592151090778801939317811419454525722386554146106289218796022
383897147608850627686296714667469756291123408243920816015378088989396451826324367161676217916890977991190375403127462228998800519544441428201218736174599264295658174662830295557029902432415318161721046583203678690611726015878352075151628422554026517048330422614397428693306169089796848259012545832716822645806652676995865268227280707578139185817888965220816434834482599326604336766017699961283186078838615027946595513115655203609398818061213855860030143569452722420634463179746059468257310379008402443243846565724501440282188525247093519062092902313649327349756551395872055965422874977401141334696271542284586237738753823048386568897646192738381490014076731044664025989949022222176590433990188601856652648506179970235619389701786004081188972991831102117122984590164192106888438712185564612496079872290851929681937238864261483965738229112312502418664935314397013742853192664987533721894069428143411852015801412334482801505139969429015348307764456909907315243327828826986460278986432113908350
6217095002597389863554277196742822248757586765752344220207573630569498825087968928162753848863396909959826280956121450994871701244516461260379029309120889086942028510640182154399457156805941872748998094254742173582401063677404595741785160829230135358081840096996372524230560855903700624271243416909004153690105933983835777939410970027753472000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
14887338741396604108836218987068397819515734169330307832552614964463631525147056089659539353020968301885437350481455158516435403120762983029708143341331125565290146112787030472070558647314210247036525976597784518092962753931708751743427749813657515530486192136342088200123427578504060322268353183572626247684288099604317729196932385458475870787960678089474805708323607303725130632023014879405880088044425973858266587929771882570002658468366509416402778571870881449528235149699570523837807193374172499257253080329249482755483689253643954520965116467976006881581562502101250730317449718557752552479483242397797858641026386246065305342383763338299798804251426068321399476365271733915649901592715774415472458296798952361296871772675924137165979347968382886768388509048400469844428499523227069062942721623939098937588340238777157515568891409171768985250095842525138027339737717540062795966278680090918275933243483396153221137907390132418600198174540107671636662142790982001042896637128055202939
683626448277265970382094413684209458162026605677549391645057402598469869530573463082258684211076188260727348872289588911568206112878444837409973091425945918369740745707209513812281716958724110851326071095151377636895662101661415015659862946356501206391326713122836788609529711241312058219893887204378865996340580885186675061657006875734884482244425305903813716473827156698957576512329604792763641150051463059212316087778601478651563197581218398997460441030535693709023282770248260738731169939793856526818637224852114356256743074517095933572917787115242437958826232003607322617412997607082434068594882266482291534379837634370964375348040273367085219398753790481822034810177719602236505565210811303560690642065746922411180102378946048721520239612733413047730989068621588697781037337647167385696944081157256721257664363581037586646971667003754609168413277462354155210048777002439363830584897240493890798948838108607229018130353379262326268822714886836557184096243603337010655180334599435813695
05321722720193665102822583486757396388249600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Hm.. perhaps using some example with external text file? :)
------------------------------
Date: Tue, 25 Nov 2008 07:56:00 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: win32 vs linux (bignum)
Message-Id: <lq7oi45a14hjkf0n64hpvch82ng28pr1fc@4ax.com>
Matija Papec <nema@yahoo.com> wrote:
>
>I get different results when running same algorithm on different
>platforms. What went so terribly wrong here? :)
>
> return $brojnik / $nazivnik;
Your problem is that you are using floating point arithmetic in the line
above.
As you know from computer numerics floating point arithmetic is
inherently problematic and very much system dependent.
jue
------------------------------
Date: Tue, 25 Nov 2008 18:57:36 GMT
From: sln@netherlands.com
Subject: Re: win32 vs linux (bignum)
Message-Id: <mmgoi45duh8a61t082dbsr4o9btqqjv91e@4ax.com>
On Thu, 13 Nov 2008 09:03:57 +0100, Matija Papec <nema@yahoo.com> wrote:
>
>I get different results when running same algorithm on different
>platforms. What went so terribly wrong here? :)
>
>
>linux debian v5.10
>result:
>270288240945436551019305908463402626133344424635003137400602091930237777421360473851797325724922730460543802875678603168471867361078540080081808473288115110060581000433119131429793939577717447508918397345219433071259594386723113371250852722071254367796680880783950950640887679135140232038177361100800
>
>win32 strawberry v5.10
>result:
>270288240945436550000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>
>==================
>use bignum;
>
>sub f {
> my ($n) = @_;
> my $f = 1;
> while ($n > 1) {
> $f *= $n;
> $n -= 1;
> }
> return $f;
>}
>
>sub p {
> my ($n,$k) = @_;
>
> if ($n == $k or $k == $0) { return 1 }
^
error
> elsif ($n < $k) { return 0 }
> else {
> my $brojnik = f($n);
> my $nazivnik = f($k)*f($n-$k);
> # print "$brojnik\n$nazivnik\n";
> return $brojnik / $nazivnik;
> }
>}
>
># my ($x,$y) = @ARGV;
>my ($x,$y) = (1000, 500);
>printf ("%.f", p($x,$y) );
^^^^^^
What does print p($x,$y),"\n"; give you?
I get this with 5.8.8 Perl (but this is just a float
to string conversion):
$inv1 = ($nazivnik / $brojnik);
$inv2 = ($brojnik / $nazivnik);
$ratio = $inv1 * $inv2;
print "\nratio = $ratio\n\n";
ratio = 1.0000000000000000000000000000000000000001449960144929226517452630725078430893586
^
40 decimal places
I'm wondering if 40 decimal places is enough precision for you.
I think taking PI as an example of precision is pretty good.
In analytic physical science's, math, probability/statics,
where pi is used extensively, if you can't do the inverse, ie; solve pi to 40
decimal places, then you don't need 40 decimal places. I'm not talking number
series/period used specifically to roll out the next digit of pi.
Because the physical reality terms are not accurate to do the inverse,
you can use PI to 1 trillion digits in physical/math equations using
intermediate results, itterating for hundreds of thousands of years, but this:
1.0000000000000000000000000000000000000001449960144929226517452630725078430893586
is really 1, always was, always will be.
Read the first and last paragraphs below.
sln
-------------------------------------------
PI:
While the value of pi has been computed to more than a trillion (10 ** 12) digits,
elementary applications, such as calculating the circumference of a circle,
will rarely require more than a dozen decimal places.
For example, a value truncated to 11 decimal places is accurate enough to
calculate the circumference of the earth with a precision of a millimeter,
and one truncated to 39 decimal places is sufficient to compute the circumference
of any circle that fits in the observable universe to a precision comparable
to the size of a hydrogen atom.
Calculating p:
p can be empirically estimated by drawing a large circle, then measuring its
diameter and circumference and dividing the circumference by the diameter.
Another geometry-based approach, due to Archimedes, is to calculate the perimeter, Pn,
of a regular polygon with n sides circumscribed around a circle with diameter d. Then
p = lim(n->infinity) of Pn/d
That is, the more sides the polygon has, the closer the approximation approaches p.
Archimedes determined the accuracy of this approach by comparing the perimeter of the
circumscribed polygon with the perimeter of a regular polygon with the same number of
sides inscribed inside the circle. Using a polygon with 96 sides, he computed the
fractional range:
3-10/17 < pi < 3-1/7
p can also be calculated using purely mathematical methods. Most formulas used
for calculating the value of p have desirable mathematical properties, but are
difficult to understand without a background in trigonometry and calculus.
However, some are quite simple, such as this form of the Gregory-Leibniz series: ...
While that series is easy to write and calculate, it is not immediately obvious why it yields p.
In addition, this series converges so slowly that 300 terms are not sufficient to calculate p
correctly to 2 decimal places. However, by computing this series in a somewhat more
clever way by taking the midpoints of partial sums, it can be made to converge much faster.
...
And on and on with simulated series/periods, supercomputers, years of calculations.
Now for the good stuff. What uses PI?
---------------------------------------------
Use in mathematics and science:
Mathematics ..
pi is ubiquitous in mathematics, appearing even in places that lack an obvious
connection to the circles of Euclidean geometry.
Higher analysis and number theory
The frequent appearance of pi in complex analysis can be related to the behavior
of the exponential function of a complex variable, described by Euler's formula.
[snip] .. A consequence is that the gamma function of a half-integer is a rational multiple of vp.
Physics ..
Although not a physical constant, pi appears routinely in equations describing
fundamental principles of the Universe, due in no small part to its relationship
to the nature of the circle and, correspondingly, spherical coordinate systems.
- The cosmological constant.
- Heisenberg's uncertainty principle, which shows that the uncertainty in the
measurement of a particle's position (?x) and momentum (?p) can not both be
arbitrarily small at the same time.
- Einstein's field equation of general relativity.
- Coulomb's law for the electric force, describing the force between two electric
charges (q1 and q2) separated by distance r.
- Magnetic permeability of free space.
- Kepler's third law constant, relating the orbital period (P) and the semimajor
axis (a) to the masses (M and m) of two co-orbiting bodies.
Probability and statistics ..
In probability and statistics, there are many distributions whose formulas contain pi, including:
- The probability density function for the normal distribution with mean µ and standard deviation s,
due to the Gaussian integral.
- The probability density function for the (standard) Cauchy distribution.
Note that since for any probability density function f(x), the above formulas can be used
to produce other integral formulas for pi.
Buffon's needle problem is sometimes quoted as a empirical approximation of pi in
"popular mathematics" works. Consider dropping a needle of length L repeatedly on
a surface containing parallel lines drawn S units apart (with S > L). If the needle
is dropped n times and x of those times it comes to rest crossing a line (x > 0),
then one may approximate pi using the Monte Carlo method
Though this result is mathematically impeccable, it cannot be used to determine more than
very few digits of pi by experiment. Reliably getting just three digits (including the initial "3")
right requires millions of throws, and the number of throws grows exponentially with the number
of digits desired. Furthermore, any error in the measurement of the lengths L and S will transfer
directly to an error in the approximated pi. For example, a difference of a single atom in the
length of a 10-centimeter needle would show up around the 9th digit of the result.
In practice, uncertainties in determining whether the needle actually crosses a line when
it appears to exactly touch it will limit the attainable accuracy to much less than 9 digits
^^^^^^^^^^^^^^
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2004
***************************************
