Pi approximation games

[Tim Wescott]

Instead of doing productive work, I just spent a few enjoyable minutes
with Scilab finding approximations to pi of the form m/n.

Because I'm posting to a couple of nerd groups, I can be confident that
most of you probably know 22/7 off the tops of your heads.

What interested me is how spotty things are -- after 22/7, the error
drops for a bit until you get down to 355/113 (which, if you're at an
equal level of nerdiness to me will ring a bell, but not have been
swimming around in your brain to be found).

But what's _really_ interesting, is that the next better fit isn't found
until you get up to 52163/16604. Then things get steadily better until
you hit 104348/33215 -- at which point the next lowest ratio which
improves anything is 208341/66317, then 312689/99532. At this point I
decided that I would post my answers for your amusement, and get back to
being productive.

Discrete math is so fun. And these newfangled chips are just destroying
the joy, by making floating point efficient and cheap enough that you
don't need to know little tricks like pi = (almost) 355/113.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

[John S]

On 5/1/2012 6:16 PM, Tim Wescott wrote:
> Instead of doing productive work, I just spent a few enjoyable minutes
> with Scilab finding approximations to pi of the form m/n.
>
> Because I'm posting to a couple of nerd groups, I can be confident that
> most of you probably know 22/7 off the tops of your heads.
>
> What interested me is how spotty things are -- after 22/7, the error
> drops for a bit until you get down to 355/113 (which, if you're at an
> equal level of nerdiness to me will ring a bell, but not have been
> swimming around in your brain to be found).
>
> But what's _really_ interesting, is that the next better fit isn't found
> until you get up to 52163/16604. Then things get steadily better until
> you hit 104348/33215 -- at which point the next lowest ratio which
> improves anything is 208341/66317, then 312689/99532. At this point I
> decided that I would post my answers for your amusement, and get back to
> being productive.
>
> Discrete math is so fun. And these newfangled chips are just destroying
> the joy, by making floating point efficient and cheap enough that you
> don't need to know little tricks like pi = (almost) 355/113.
>

I like the idea that both 22 and 7 each fit into a byte whereas 355 does
not. And, 22/7 is hi by only .04%. Beautiful!

John S

[Tim Wescott]

245/78. It's only a bit better than twice as good as 22/7 -- then along
comes 355/113, which is over 1000 times better than 245/78.

[Joel Koltner]

Tim Wescott wrote:
> Discrete math is so fun. And these newfangled chips are just destroying
> the joy, by making floating point efficient and cheap enough that you
> don't need to know little tricks like pi = (almost) 355/113.

--> http://xkcd.com/1047/

:-)

[Joel Koltner]

John S wrote:
> I like the idea that both 22 and 7 each fit into a byte whereas 355 does
> not. And, 22/7 is hi by only .04%. Beautiful!

Jack Crenshaw's book, "Math Toolkit for Real-Time Programming"
(http://www.amazon.com/Math-Toolkit-Real-Time-Programming-ebook/dp/B003WUYQVY)
spends a lot of time discussing how to make "good enough" approximations
of various, e.g., transcendental functions... and how to know when "good
enough" really is. It's quite handy for this sort of thing...

[Steve Pope]

Suppose you do the same thing with the fine structure constant --
let me know what you discover.


Steve

[John Larkin]

On Tue, 01 May 2012 18:16:25 -0500, Tim Wescott <t...@seemywebsite.com>
wrote:

>Instead of doing productive work, I just spent a few enjoyable minutes
>with Scilab finding approximations to pi of the form m/n.
>
>Because I'm posting to a couple of nerd groups, I can be confident that
>most of you probably know 22/7 off the tops of your heads.
>
>What interested me is how spotty things are -- after 22/7, the error
>drops for a bit until you get down to 355/113 (which, if you're at an
>equal level of nerdiness to me will ring a bell, but not have been
>swimming around in your brain to be found).
>
>But what's _really_ interesting, is that the next better fit isn't found
>until you get up to 52163/16604. Then things get steadily better until
>you hit 104348/33215 -- at which point the next lowest ratio which
>improves anything is 208341/66317, then 312689/99532. At this point I
>decided that I would post my answers for your amusement, and get back to
>being productive.
>
>Discrete math is so fun. And these newfangled chips are just destroying
>the joy, by making floating point efficient and cheap enough that you
>don't need to know little tricks like pi = (almost) 355/113.

I once knew pi to 100 places, but now I've forgotten everything past
19.


--

John Larkin Highland Technology, Inc

jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro acquisition and simulation

[John Larkin]

On Tue, 01 May 2012 18:16:25 -0500, Tim Wescott <t...@seemywebsite.com>
wrote:

>Instead of doing productive work, I just spent a few enjoyable minutes
>with Scilab finding approximations to pi of the form m/n.
>
>Because I'm posting to a couple of nerd groups, I can be confident that
>most of you probably know 22/7 off the tops of your heads.
>
>What interested me is how spotty things are -- after 22/7, the error
>drops for a bit until you get down to 355/113 (which, if you're at an
>equal level of nerdiness to me will ring a bell, but not have been
>swimming around in your brain to be found).
>
>But what's _really_ interesting, is that the next better fit isn't found
>until you get up to 52163/16604. Then things get steadily better until
>you hit 104348/33215 -- at which point the next lowest ratio which
>improves anything is 208341/66317, then 312689/99532. At this point I
>decided that I would post my answers for your amusement, and get back to
>being productive.
>
>Discrete math is so fun. And these newfangled chips are just destroying
>the joy, by making floating point efficient and cheap enough that you
>don't need to know little tricks like pi = (almost) 355/113.

My old HP35 calculators have a key for pi. The newer ones hide it, a
tiny pastel shift key thing. So I just key in 3.14. Rob down the hall
uses 3.

We are increasingly using floats in embedded stuff. Our ARM LPC3250
has SIMD hardware FP operations.

[John S]

245/78 is more easily forgotten.

[Les Cargill]

but highly mnenomic - it's 2345678 with the 3 dropped and the 6 turned
into a divide sign...

--
Les Cargill

[Artemus]

"John S" <Sop...@invalid.org> wrote in message news:jnpvhd$qj3$1...@dont-email.me...

>
> 245/78 is more easily forgotten.

I learned to twin the first 3 odd digits - 113355.
Then divide the first 3 into the last 3.
Easily remembered.
Art

[Nico Coesel]

Tim Wescott <t...@seemywebsite.com> wrote:

>Instead of doing productive work, I just spent a few enjoyable minutes
>with Scilab finding approximations to pi of the form m/n.
>
>Because I'm posting to a couple of nerd groups, I can be confident that
>most of you probably know 22/7 off the tops of your heads.

Now you mention it :-)

>Discrete math is so fun. And these newfangled chips are just destroying
>the joy, by making floating point efficient and cheap enough that you
>don't need to know little tricks like pi = (almost) 355/113.

You can always declare a constant or use pi=4*arctan(1) although I
seldomly see the latter.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

[John S]

Off the subject, but this one is really funny...

http://xkcd.com/1020/

[Randy Yates]

That's mean - at the end "not all these are wrong" - several looked
close (at least in my head).
--
Randy Yates
DSP/Firmware Engineer
919-577-9882 (H)
919-720-2916 (C)

[glen herrmannsfeldt]

In comp.dsp Tim Wescott <t...@seemywebsite.com> wrote:
> Instead of doing productive work, I just spent a few enjoyable minutes
> with Scilab finding approximations to pi of the form m/n.

> Because I'm posting to a couple of nerd groups, I can be confident
> that most of you probably know 22/7 off the tops of your heads.

> What interested me is how spotty things are -- after 22/7, the error
> drops for a bit until you get down to 355/113 (which, if you're at an
> equal level of nerdiness to me will ring a bell, but not have been
> swimming around in your brain to be found).

Yes. It was the first problem in the book for the HP 25C calculator
that I got many years ago.

> But what's _really_ interesting, is that the next better fit
> isn't found until you get up to 52163/16604. Then things get
> steadily better until you hit 104348/33215 -- at which point
> the next lowest ratio which improves anything is 208341/66317,
> then 312689/99532. At this point I decided that I would post
> my answers for your amusement, and get back to being productive.

There is an algorithm that some calculators use for converting a
decimal result to a fraction. If I remember, that one easily finds
successively better fractions approximating any given value.

I don't remember the details, but I do remember how funny it is,
in that at one point it takes two fractions, and adds their numerators
and denominators, before goint to the next step.

I believe it is described in the manual for one of the HP
calculators that does that conversion.

Otherwise, I have the TI-92, which will generate fraction (rational)
results, then you ask for an approximate result. Some calculations
will give a symbolic pi result.

> Discrete math is so fun. And these newfangled chips are just
> destroying the joy, by making floating point efficient and
> cheap enough that you don't need to know little tricks
> like pi = (almost) 355/113.

-- glen

[robert bristow-johnson]

On 5/1/12 8:14 PM, Steve Pope wrote:
> Tim Wescott<t...@seemywebsite.com> wrote:
>
...

>>
>> 245/78. It's only a bit better than twice as good as 22/7 -- then along
>> comes 355/113, which is over 1000 times better than 245/78.
>
> Suppose you do the same thing with the fine structure constant --
> let me know what you discover.
>

not quite m/n but

alpha = cos(pi*137)/137 * tan(pi*(29*137))/(pi*(29*137))

actually i think that sqrt(4*pi*alpha) = 0.30282212 is the more
fundamental number than the fine-structure constant. the fine-structure
constant should be thought of as a consequence of this number.

--

r b-j r...@audioimagination.com

"Imagination is more important than knowledge."

[robert bristow-johnson]

i've sent him some series that were simpler and better than his (at
least those that were published at the time). i have no idea what rules
of optimization he was using.

he wrote back. didn't see anything happen about it since.

[John Devereux]

We had a teacher that insisted it was exactly equal!

--

John Devereux

[Steve Pope]

John Devereux <jo...@devereux.me.uk> wrote:

>John S <Sop...@invalid.org> writes:

>> I like the idea that both 22 and 7 each fit into a byte whereas 355
>> does not. And, 22/7 is hi by only .04%. Beautiful!
>
>We had a teacher that insisted it was exactly equal!

I recall the time when you couldn't consider 25.4 mm to be exactly
one inch. But, they fudged enough standards so that it is now exact.

Prior to that, neither the British inch nor the American inch
measures 25.4 ... and they deviated from that value in opposite
direction!


S.

[John Devereux]

Even the integer-only cortex M3s we use take less than a microsecond for
most things. On a 72MHz STM32F2:

Double Precision:
0.415us / 49.852 cycles /multiply
0.378us / 45.403 cycles /add
2.414us / 289.702 cycles /divide
Single Precision:
0.194us / 23.350 cycles /multiply
0.250us / 30.052 cycles /add
0.610us / 73.202 cycles / divide



--

John Devereux

[John Devereux]

spo...@speedymail.org (Steve Pope) writes:

> John Devereux <jo...@devereux.me.uk> wrote:
>
>>John S <Sop...@invalid.org> writes:
>
>>> I like the idea that both 22 and 7 each fit into a byte whereas 355
>>> does not. And, 22/7 is hi by only .04%. Beautiful!
>>
>>We had a teacher that insisted it was exactly equal!
>
> I recall the time when you couldn't consider 25.4 mm to be exactly
> one inch. But, they fudged enough standards so that it is now exact.

Aha, good idea, we should standardize pi to a more convenient value! :)

(Didn't they already try that?)

> Prior to that, neither the British inch nor the American inch
> measures 25.4 ... and they deviated from that value in opposite
> direction!

I suppose the american inch was bigger...




--

John Devereux

[Martin Brown]

On 02/05/2012 00:16, Tim Wescott wrote:
> Instead of doing productive work, I just spent a few enjoyable minutes
> with Scilab finding approximations to pi of the form m/n.
>
> Because I'm posting to a couple of nerd groups, I can be confident that
> most of you probably know 22/7 off the tops of your heads.
>
> What interested me is how spotty things are -- after 22/7, the error
> drops for a bit until you get down to 355/113 (which, if you're at an
> equal level of nerdiness to me will ring a bell, but not have been
> swimming around in your brain to be found).
>
> But what's _really_ interesting, is that the next better fit isn't found
> until you get up to 52163/16604. Then things get steadily better until
> you hit 104348/33215 -- at which point the next lowest ratio which
> improves anything is 208341/66317, then 312689/99532. At this point I
> decided that I would post my answers for your amusement, and get back to
> being productive.
>
> Discrete math is so fun. And these newfangled chips are just destroying
> the joy, by making floating point efficient and cheap enough that you
> don't need to know little tricks like pi = (almost) 355/113.

As a physicist I found the classic approximations

pi^2 = g
pi x 10^7 seconds in a year

quite handy to within 1% slide rule accuracy

--
Regards,
Martin Brown

[Martin Brown]

On 02/05/2012 01:59, Nico Coesel wrote:
> Tim Wescott<t...@seemywebsite.com> wrote:
>

>> Discrete math is so fun. And these newfangled chips are just destroying
>> the joy, by making floating point efficient and cheap enough that you
>> don't need to know little tricks like pi = (almost) 355/113.
>
> You can always declare a constant or use pi=4*arctan(1) although I
> seldomly see the latter.

Dunno what it is like now, but arctan(1) was a risky choice on some old
machines as the series convergence was at its worst for that argument
value and the tradeoff between accuracy and speed could cause trouble.
You were at the mercy of the trig library if you did it this way.

--
Regards,
Martin Brown

[David Brown]

On 02/05/2012 01:16, Tim Wescott wrote:
> Instead of doing productive work, I just spent a few enjoyable minutes
> with Scilab finding approximations to pi of the form m/n.
>
> Because I'm posting to a couple of nerd groups, I can be confident that
> most of you probably know 22/7 off the tops of your heads.
>
> What interested me is how spotty things are -- after 22/7, the error
> drops for a bit until you get down to 355/113 (which, if you're at an
> equal level of nerdiness to me will ring a bell, but not have been
> swimming around in your brain to be found).
>
> But what's _really_ interesting, is that the next better fit isn't found
> until you get up to 52163/16604. Then things get steadily better until
> you hit 104348/33215 -- at which point the next lowest ratio which
> improves anything is 208341/66317, then 312689/99532. At this point I
> decided that I would post my answers for your amusement, and get back to
> being productive.
>
> Discrete math is so fun. And these newfangled chips are just destroying
> the joy, by making floating point efficient and cheap enough that you
> don't need to know little tricks like pi = (almost) 355/113.
>

Wikipedia is often a great starting point for these sorts of things. It
typically has enough information to give you some hints - but not so
much that you can't have fun finding out more:

<http://en.wikipedia.org/wiki/Pi#Continued_fractions>


At university I remember a project that involved calculating all the
digits of pi. It was written using a functional programming language
(similar to Haskell) - the result was an unending list of the digits of
pi. But since the language used lazy evaluation, it didn't bother
calculating the entries until you tried to print them out. I used
polynomial expansions of arctan() to do the sums.

[Nico Coesel]

So you are saying the inch is in fact metric?

[Uwe Hercksen]

David Brown schrieb:

> At university I remember a project that involved calculating all the
> digits of pi.

Hello,

it is known since centuries that calculating all the
digits of pi is not possible. Pi has an infinite number of digits.

Bye

[Dennis]

"John Devereux" <jo...@devereux.me.uk> wrote in message
news:87fwbjo...@devereux.me.uk...

> John Devereux

Boasting again? ;)

[David Brown]

On 02/05/2012 11:21, Nico Coesel wrote:
> spo...@speedymail.org (Steve Pope) wrote:
>
>> John Devereux<jo...@devereux.me.uk> wrote:
>>
>>> John S<Sop...@invalid.org> writes:
>>
>>>> I like the idea that both 22 and 7 each fit into a byte whereas 355
>>>> does not. And, 22/7 is hi by only .04%. Beautiful!
>>>
>>> We had a teacher that insisted it was exactly equal!
>>
>> I recall the time when you couldn't consider 25.4 mm to be exactly
>> one inch. But, they fudged enough standards so that it is now exact.
>>
>> Prior to that, neither the British inch nor the American inch
>> measures 25.4 ... and they deviated from that value in opposite
>> direction!
>
> So you are saying the inch is in fact metric?
>

Most imperial units are defined in terms of the metric units these days.
Originally they were only rough definitions (I believe an inch was
variously defined as the length from a thumb joint to the end of the
thumb, or alternatively as the length of three grains of barley). Then
they were a bit more standardised (such as the length of a particular
metal rod). But now they use specific metric definitions - so an inch
is precisely 25.4 mm - and will stay that way even if the definition of
a millimetre varies!

[David Brown]

<http://en.wikipedia.org/wiki/Lazy_evaluation>

The most relevant section, "working with infinite data structures", is
missing - but I hope you get the point anyway.

mvh.,

David

[Syd Rumpo]

On 02/05/2012 09:07, Martin Brown wrote:

<snip>

> As a physicist I found the classic approximations
>
> pi^2 = g
> pi x 10^7 seconds in a year
>
> quite handy to within 1% slide rule accuracy

Which is why a 1m pendulum has a half period of ~1 second using the
classic formula two pi root ell over gee or:

l g / sqrt pi * 2 *

in RPN

Cheers
--
Syd

[Albert van der Horst]

In article <jnq291$5dj$1...@speranza.aioe.org>,

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>In comp.dsp Tim Wescott <t...@seemywebsite.com> wrote:
>> Instead of doing productive work, I just spent a few enjoyable minutes
>> with Scilab finding approximations to pi of the form m/n.
>
>> Because I'm posting to a couple of nerd groups, I can be confident
>> that most of you probably know 22/7 off the tops of your heads.
>
>> What interested me is how spotty things are -- after 22/7, the error
>> drops for a bit until you get down to 355/113 (which, if you're at an
>> equal level of nerdiness to me will ring a bell, but not have been
>> swimming around in your brain to be found).
>
>Yes. It was the first problem in the book for the HP 25C calculator
>that I got many years ago.
>
>> But what's _really_ interesting, is that the next better fit
>> isn't found until you get up to 52163/16604. Then things get
>> steadily better until you hit 104348/33215 -- at which point
>> the next lowest ratio which improves anything is 208341/66317,
>> then 312689/99532. At this point I decided that I would post
>> my answers for your amusement, and get back to being productive.
>
>There is an algorithm that some calculators use for converting a
>decimal result to a fraction. If I remember, that one easily finds
>successively better fractions approximating any given value.
>
>I don't remember the details, but I do remember how funny it is,
>in that at one point it takes two fractions, and adds their numerators
>and denominators, before goint to the next step.

That is standard fare in continued fractions. Everybody interested in
these kind of approximations should take a look at this fascinating
subject.

>
>I believe it is described in the manual for one of the HP
>calculators that does that conversion.
>
>Otherwise, I have the TI-92, which will generate fraction (rational)
>results, then you ask for an approximate result. Some calculations
>will give a symbolic pi result.
>
>> Discrete math is so fun. And these newfangled chips are just
>> destroying the joy, by making floating point efficient and
>> cheap enough that you don't need to know little tricks
>> like pi = (almost) 355/113.
>
>-- glen

It depends. Pi has been calculated to billions of decimals.
Simple floating point doesn't get you there.

Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[John Larkin]

There was a short PDP-8 assembly program that printed the digits of e
forever.


--

John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators

Custom timing and laser controllers

Photonics and fiberoptic TTL data links

VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators

[mwi...@the-wire.com]

John Larkin wrote:

> There was a short PDP-8 assembly program that printed the digits of e
> forever.

In order ?

Mel.

[George Herold]

On May 1, 8:26 pm, John Larkin <jlar...@highlandtechnology.com> wrote:
> On Tue, 01 May 2012 18:16:25 -0500, Tim Wescott <t...@seemywebsite.com>

> wrote:
>
>
>
>
>
> >Instead of doing productive work, I just spent a few enjoyable minutes
> >with Scilab finding approximations to pi of the form m/n.
>
> >Because I'm posting to a couple of nerd groups, I can be confident that
> >most of you probably know 22/7 off the tops of your heads.
>
> >What interested me is how spotty things are -- after 22/7, the error
> >drops for a bit until you get down to 355/113 (which, if you're at an
> >equal level of nerdiness to me will ring a bell, but not have been
> >swimming around in your brain to be found).
>
> >But what's _really_ interesting, is that the next better fit isn't found
> >until you get up to 52163/16604.  Then things get steadily better until
> >you hit 104348/33215 -- at which point the next lowest ratio which
> >improves anything is 208341/66317, then 312689/99532.  At this point I
> >decided that I would post my answers for your amusement, and get back to
> >being productive.
>
> >Discrete math is so fun.  And these newfangled chips are just destroying
> >the joy, by making floating point efficient and cheap enough that you
> >don't need to know little tricks like pi = (almost) 355/113.
>

> My old HP35 calculators have a key for pi. The newer ones hide it, a
> tiny pastel shift key thing. So I just key in 3.14. Rob down the hall
> uses 3.

Grin... I always just let 2*pi = 10, so pi = 5!

(and then remember there's a 1.59 floating around)

George H.

>
> We are increasingly using floats in embedded stuff. Our ARM LPC3250
> has SIMD hardware FP operations.
>

> --
>
> John Larkin         Highland Technology, Inc
>
> jlarkin at highlandtechnology dot comhttp://www.highlandtechnology.com

>
> Precision electronic instrumentation
> Picosecond-resolution Digital Delay and Pulse generators

> Custom laser drivers and controllers

> Photonics and fiberoptic TTL data links

> VME thermocouple, LVDT, synchro   acquisition and simulation- Hide quoted text -
>
> - Show quoted text -

[Uwe Hercksen]

David Brown schrieb:

> <http://en.wikipedia.org/wiki/Lazy_evaluation>
>
> The most relevant section, "working with infinite data structures", is
> missing - but I hope you get the point anyway.

Hello,

even with infinite data structures, with finite time and finite RAM, it
is not possible to compute all digits of pi.

Bye

[mwi...@the-wire.com]

That's where David Brown blew it -- when he wrote "it didn't bother
calculating the entries until you tried to print them out". Without that,
you can fall back on the idea that logical truths exist a priori, and argue
that what's impossible is to *print* all digits of pi.

There's an argument about LISP that goes: it's easy to write a LISP
interpreter in LISP such that the source code can be printed on a sheet of
paper; it's also easy to quine that source code so that it's applied to
itself; then you have a LISP interpreter executing on a sheet of paper. I/O
bandwidth is the only problem. Maybe with e-paper ..

Mel.
>
> Bye

[tm]

"George Herold" <ghe...@teachspin.com> wrote in message
news:b406f594-a809-4b4e...@m7g2000vbg.googlegroups.com...

________________________________________

1 + 1 = 3 for extremely large values of 1!

[k...@att.bizzzzzzzzzzzz]

Shoulda been a congressman.

[VWWall]

meter (m)

"The metre is the length of the path traveled by light in vacuum during
a time interval of 1/299 792 458 of a second."

kilogram (kg)

"The kilogram is equal to the mass of the international prototype of the
kilogram."

second (s)

"The second is the duration of 9 192 631 770 periods of the radiation
corresponding to the transition between the two hyperfine levels of the
ground state of the caesium 133 atom."

Note that the kilogram is now the only one defined by a physical object.
("International prototype").

Let's define pi as in Euler's identity: e^i*pi + 1 = 0

--
Virg Wall

[VWWall]

Nico Coesel wrote:
> spo...@speedymail.org (Steve Pope) wrote:
>
>> John Devereux <jo...@devereux.me.uk> wrote:
>>
>>> John S <Sop...@invalid.org> writes:
>>>> I like the idea that both 22 and 7 each fit into a byte whereas 355
>>>> does not. And, 22/7 is hi by only .04%. Beautiful!
>>> We had a teacher that insisted it was exactly equal!
>> I recall the time when you couldn't consider 25.4 mm to be exactly
>> one inch. But, they fudged enough standards so that it is now exact.
>>
>> Prior to that, neither the British inch nor the American inch
>> measures 25.4 ... and they deviated from that value in opposite
>> direction!
>
> So you are saying the inch is in fact metric?
>

See: http://www.unc.edu/~rowlett/units/index.html

"Meanwhile, only a few Americans know that the legal definitions of the
English customary units are actually based on metric units. The U. S.
and British governments have agreed that a yard equals exactly 0.9144
meter and an avoirdupois pound equals exactly 0.453 592 37 kilograms. In
this way, all the units of measurement Americans use every day are based
on the standards of the metric system. Since 1875, in fact, the United
States has subscribed to the International System of Weights and
Measures, the official version of the metric system."

--
Virg Wall, P.E.

[Steve Pope]

Nico Coesel <ni...@puntnl.niks> wrote:

>spo...@speedymail.org (Steve Pope) wrote:
>
>>John Devereux <jo...@devereux.me.uk> wrote:
>>
>>>John S <Sop...@invalid.org> writes:
>>
>>>> I like the idea that both 22 and 7 each fit into a byte whereas 355
>>>> does not. And, 22/7 is hi by only .04%. Beautiful!
>>>
>>>We had a teacher that insisted it was exactly equal!
>>
>>I recall the time when you couldn't consider 25.4 mm to be exactly
>>one inch. But, they fudged enough standards so that it is now exact.
>>
>>Prior to that, neither the British inch nor the American inch
>>measures 25.4 ... and they deviated from that value in opposite
>>direction!
>
>So you are saying the inch is in fact metric?

Yes, that would be one way of saying it. Inches are now defined
in terms of SI units, which have replaced "metric".

Steve

[TTman]

"Tim Wescott" <t...@seemywebsite.com> wrote in message
news:_f2dnZ4A5_JU8z3S...@web-ster.com...

> Instead of doing productive work, I just spent a few enjoyable minutes
> with Scilab finding approximations to pi of the form m/n.
>
> Because I'm posting to a couple of nerd groups, I can be confident that
> most of you probably know 22/7 off the tops of your heads.
>
> What interested me is how spotty things are -- after 22/7, the error
> drops for a bit until you get down to 355/113 (which, if you're at an
> equal level of nerdiness to me will ring a bell, but not have been
> swimming around in your brain to be found).
>
> But what's _really_ interesting, is that the next better fit isn't found
> until you get up to 52163/16604. Then things get steadily better until
> you hit 104348/33215 -- at which point the next lowest ratio which
> improves anything is 208341/66317, then 312689/99532. At this point I
> decided that I would post my answers for your amusement, and get back to
> being productive.
>
> Discrete math is so fun. And these newfangled chips are just destroying
> the joy, by making floating point efficient and cheap enough that you
> don't need to know little tricks like pi = (almost) 355/113.
>

> --
> My liberal friends think I'm a conservative kook.
> My conservative friends think I'm a liberal kook.
> Why am I not happy that they have found common ground?
>
> Tim Wescott, Communications, Control, Circuits & Software
> http://www.wescottdesign.com

Yes total nerd :)

[halong]

On May 2, 1:44 am, John Devereux <j...@devereux.me.uk> wrote:
> spop...@speedymail.org (Steve Pope) writes:
> > John Devereux  <j...@devereux.me.uk> wrote:

>
> >>John S <Soph...@invalid.org> writes:
>
> >>> I like the idea that both 22 and 7 each fit into a byte whereas 355
> >>> does not. And, 22/7 is hi by only .04%. Beautiful!
>
> >>We had a teacher that insisted it was exactly equal!
>
> > I recall the time when you couldn't consider 25.4 mm to be exactly
> > one inch.  But, they fudged enough standards so that it is now exact.
>
> Aha, good idea, we should standardize pi to a more convenient value! :)
>

But who want to use your PY to calculate the circle circumference,
with given diameter

???

[glen herrmannsfeldt]

In comp.dsp VWWall <vw...@large.invalid> wrote:

(snip)

> kilogram (kg)

> "The kilogram is equal to the mass of the international
> prototype of the kilogram."

There are at least two projects to redefine the kilogram, such
that it isn't dependent on a physical object.

One involves a more accurate determination of Avogadro's number.

-- glen

[Piergiorgio Sartor]

On 05/02/2012 01:16 AM, Tim Wescott wrote:
> Instead of doing productive work, I just spent a few enjoyable minutes
> with Scilab finding approximations to pi of the form m/n.
>
> Because I'm posting to a couple of nerd groups, I can be confident that
> most of you probably know 22/7 off the tops of your heads.
>
> What interested me is how spotty things are -- after 22/7, the error
> drops for a bit until you get down to 355/113 (which, if you're at an
> equal level of nerdiness to me will ring a bell, but not have been
> swimming around in your brain to be found).
>
> But what's _really_ interesting, is that the next better fit isn't found
> until you get up to 52163/16604. Then things get steadily better until
> you hit 104348/33215 -- at which point the next lowest ratio which
> improves anything is 208341/66317, then 312689/99532. At this point I
> decided that I would post my answers for your amusement, and get back to
> being productive.
>
> Discrete math is so fun. And these newfangled chips are just destroying
> the joy, by making floating point efficient and cheap enough that you
> don't need to know little tricks like pi = (almost) 355/113.
>

You might find fun at the opposite game too, have a look:

http://mathworld.wolfram.com/AlmostInteger.html

bye,

--

piergiorgio

[Syd Rumpo]

On 02/05/2012 16:20, George Herold wrote:

<snip>

>
> Grin... I always just let 2*pi = 10, so pi = 5!
>

That's known as a 'Selleck' or a 'Magnum PI'.

Cheers
--
Syd

[John Larkin]

On Wed, 02 May 2012 21:09:05 +0200, Piergiorgio Sartor
<piergiorgio.sartor.th...@nexgo.REMOVETHIS.de>
wrote:

This is cool.

http://mathworld.wolfram.com/ResistorNetwork.html

I did this by hand recently...

http://dl.dropbox.com/u/53724080/Circuits/R-pak_values.JPG

One could also do the set of possible voltage dividers and
corresponding opamp gains.

[David T. Ashley]

On Wed, 02 May 2012 06:57:46 +0100, John Devereux
<jo...@devereux.me.uk> wrote:

>John Larkin <jla...@highlandtechnology.com> writes:
>
>> On Tue, 01 May 2012 18:16:25 -0500, Tim Wescott <t...@seemywebsite.com>

>> wrote:
>>
>>>Instead of doing productive work, I just spent a few enjoyable minutes
>>>with Scilab finding approximations to pi of the form m/n.
>>>
>>>Because I'm posting to a couple of nerd groups, I can be confident that
>>>most of you probably know 22/7 off the tops of your heads.
>>>
>>>What interested me is how spotty things are -- after 22/7, the error
>>>drops for a bit until you get down to 355/113 (which, if you're at an
>>>equal level of nerdiness to me will ring a bell, but not have been
>>>swimming around in your brain to be found).
>>>
>>>But what's _really_ interesting, is that the next better fit isn't found
>>>until you get up to 52163/16604. Then things get steadily better until
>>>you hit 104348/33215 -- at which point the next lowest ratio which
>>>improves anything is 208341/66317, then 312689/99532. At this point I
>>>decided that I would post my answers for your amusement, and get back to
>>>being productive.
>>>
>>>Discrete math is so fun. And these newfangled chips are just destroying
>>>the joy, by making floating point efficient and cheap enough that you
>>>don't need to know little tricks like pi = (almost) 355/113.
>>

>> My old HP35 calculators have a key for pi. The newer ones hide it, a
>> tiny pastel shift key thing. So I just key in 3.14. Rob down the hall
>> uses 3.
>>

>> We are increasingly using floats in embedded stuff. Our ARM LPC3250
>> has SIMD hardware FP operations.
>

>Even the integer-only cortex M3s we use take less than a microsecond for
>most things. On a 72MHz STM32F2:
>
>Double Precision:
> 0.415us / 49.852 cycles /multiply
> 0.378us / 45.403 cycles /add
> 2.414us / 289.702 cycles /divide
>Single Precision:
> 0.194us / 23.350 cycles /multiply
> 0.250us / 30.052 cycles /add
> 0.610us / 73.202 cycles / divide

You are living in a state of sin.

Die ganzen Zahlen hat der liebe Gatt gemacht, alles andere ist
Menschenwerk.

DTA

[John Devereux]

Err... well it will give the correct result in a sufficiently curved
space-time. I can't help it if people are using it in the wrong
universe!


--

John Devereux

[glen herrmannsfeldt]

In comp.dsp Tim Wescott <t...@seemywebsite.com> wrote:
> Instead of doing productive work, I just spent a few enjoyable minutes
> with Scilab finding approximations to pi of the form m/n.

> Because I'm posting to a couple of nerd groups, I can be confident that
> most of you probably know 22/7 off the tops of your heads.

> What interested me is how spotty things are -- after 22/7, the error
> drops for a bit until you get down to 355/113 (which, if you're at an
> equal level of nerdiness to me will ring a bell, but not have been
> swimming around in your brain to be found).

See: http://www.mindspring.com/~alanh/fracs.html

> But what's _really_ interesting, is that the next better fit isn't found
> until you get up to 52163/16604. Then things get steadily better until
> you hit 104348/33215 -- at which point the next lowest ratio which
> improves anything is 208341/66317, then 312689/99532. At this point I
> decided that I would post my answers for your amusement, and get back to
> being productive.

According to the above, they go 3/1, 22/7, 333/106, 355/113,
103993/33102, 104348/33215, the next two you note, and then
833719/265381, well, try out the site.


(snip)

The javascript code for the above site, which says no license
and free to copy, uses the following to do the computation:

var maxNumerator = getMaxNumerator(d);
var d2 = d;
var calcD, prevCalcD = NaN;
for (var i = 2; i < 1000; i++) {
var L2 = Math.floor(d2);
numerators[i] = L2 * numerators[i-1] + numerators[i-2];
if (Math.abs(numerators[i]) > maxNumerator) return;

denominators[i] = L2 * denominators[i-1] +
denominators[i-2];

calcD = numerators[i] / denominators[i];
if (calcD == prevCalcD) return;

appendFractionsOutput(numerators[i],
denominators[i]);

if (calcD == d) return;
prevCalcD = calcD;
d2 = 1/(d2-L2);
}

I haven't gone through it in detail, but you can see that it
is pretty fast. Each is generated directly from the previous one,
with no loop through successive denominators.

-- glen

[Stef]

In comp.arch.embedded,

David T Ashley <das...@gmail.com> wrote:
>
> Die ganzen Zahlen hat der liebe Gatt gemacht, alles andere ist
> Menschenwerk.

You may want to check the spelling on that one. ;-)

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

If all the world's a stage, I want to operate the trap door.
-- Paul Beatty

[VWWall]

Avogadro's number is currently: 6.02214129*10^23 entities per mole and
has an uncertainty of plus or minus 27 counts in its last two digits.

Another requires the precise definition of Planck's constant which is:

6.62606957*10^−34 and has an uncertainty of plus or minus 29 counts in
its last two digits.

I wonder if either or both of these "constants" can be defined as the
ratio of integers. :-)

--
Virg Wall

[Les Cargill]

VWWall wrote:
> glen herrmannsfeldt wrote:
>> In comp.dsp VWWall <vw...@large.invalid> wrote:
>>
>> (snip)
>>
>>> kilogram (kg)
>>
>>> "The kilogram is equal to the mass of the international prototype of
>>> the kilogram."
>>
>> There are at least two projects to redefine the kilogram, such
>> that it isn't dependent on a physical object.
>>
>> One involves a more accurate determination of Avogadro's number.
>>
> Avogadro's number is currently: 6.02214129*10^23 entities per mole and
> has an uncertainty of plus or minus 27 counts in its last two digits.
>

Any uncertainty is an artifact of measurement. It's a *count*, so ...

> Another requires the precise definition of Planck's constant which is:
>
> 6.62606957*10^−34 and has an uncertainty of plus or minus 29 counts in
> its last two digits.
>
> I wonder if either or both of these "constants" can be defined as the
> ratio of integers. :-)
>

Avogadro's Number is a natural number - so yes.

--
Les Cargill

[George Herold]

Chuckle... That's great...

I was thinking that most of the time I let 1/2pi = 1.6/10 or pi = 10
x 5/16 which is better than 1%.

George H.

[mac]

But who needs to approximate Pi? It's marked right there on the C and D
scales!

Slide rules are good for arbitrary rational approximations - look for
(nearly) aligned tick marks. And the L scale on a 10" works as a ruler.

-- not sent from my Pickett.

[glen herrmannsfeldt]

In comp.dsp VWWall <vw...@large.invalid> wrote:

(snip, I wrote)

>> One involves a more accurate determination of Avogadro's number.

> Avogadro's number is currently: 6.02214129*10^23 entities per mole and
> has an uncertainty of plus or minus 27 counts in its last two digits.

The ongoing project involves weighing and counting the number
of atoms in a silicon sphere. When you figure out how many are
in a kg, that could be, should be, an integer.

-- glen

[Jon]

pi/4 = 1 - 1/3 + 1/5 - 1/7 + ...

pi/4 = Sum [(-1)^p]/(2p+1) p = 0 to oo

max error =|[((-1)^p)/(2p+1)]-[(-1)^(p+1)]/(2(p+1)+1)|

for instance if I want to calculate pi to the nearest E = +/- 10^-50, the
series will have to be carried out p times such that

10^-50 = |1/(2p+1)-1/(2p+3)|

E(2p+3)(2p+1)=(2p+3) - (2p+1)

E(4p^2 + 8p + 3) = 2

4p^2 + 8p + (3 - 2/E) = 0

p = (-2 +/-{4-(3-2/E)}^.5)/2

for E = 10^-50, p = 10^25

for E = 1/2^128 , p = 10^20

[HardySpicer]

On May 3, 4:18 am, VWWall <vw...@large.invalid> wrote:
> Nico Coesel wrote:

> > spop...@speedymail.org (Steve Pope) wrote:
>
> >> John Devereux  <j...@devereux.me.uk> wrote:
>

> >>> John S <Soph...@invalid.org> writes:
> >>>> I like the idea that both 22 and 7 each fit into a byte whereas 355
> >>>> does not. And, 22/7 is hi by only .04%. Beautiful!
> >>> We had a teacher that insisted it was exactly equal!
> >> I recall the time when you couldn't consider 25.4 mm to be exactly
> >> one inch.  But, they fudged enough standards so that it is now exact.
>
> >> Prior to that, neither the British inch nor the American inch
> >> measures 25.4 ... and they deviated from that value in opposite
> >> direction!
>
> > So you are saying the inch is in fact metric?
>
> See:http://www.unc.edu/~rowlett/units/index.html
>
> "Meanwhile, only a few Americans know that the legal definitions of the
> English customary units are actually based on metric units. The U. S.
> and British governments have agreed that a yard equals exactly 0.9144
> meter and an avoirdupois pound equals exactly 0.453 592 37 kilograms. In
> this way, all the units of measurement Americans use every day are based
> on the standards of the metric system. Since 1875, in fact, the United
> States has subscribed to the International System of Weights and
> Measures, the official version of the metric system."
>
> --
> Virg Wall, P.E.

That's the British customary units, not English, that's the language
you are confusing with the country which is Great Britain. another
common mishtake made by americans.

[Robert Adams]

On May 2, 1:16 am, Tim Wescott <t...@seemywebsite.com> wrote:
> Instead of doing productive work, I just spent a few enjoyable minutes
> with Scilab finding approximations to pi of the form m/n.
>
> Because I'm posting to a couple of nerd groups, I can be confident that
> most of you probably know 22/7 off the tops of your heads.
>
> What interested me is how spotty things are -- after 22/7, the error
> drops for a bit until you get down to 355/113 (which, if you're at an
> equal level of nerdiness to me will ring a bell, but not have been
> swimming around in your brain to be found).
>

> But what's _really_ interesting, is that the next better fit isn't found

> until you get up to52163/16604.  Then things get steadily better until

> you hit 104348/33215 -- at which point the next lowest ratio which
> improves anything is 208341/66317, then 312689/99532.  At this point I
> decided that I would post my answers for your amusement, and get back to
> being productive.
>

> Discrete math is so fun.  And these newfangled chips are just destroying
> the joy, by making floating point efficient and cheap enough that you
> don't need to know little tricks like pi = (almost) 355/113.
>

> --
> My liberal friends think I'm a conservative kook.
> My conservative friends think I'm a liberal kook.
> Why am I not happy that they have found common ground?
>
> Tim Wescott, Communications, Control, Circuits & Softwarehttp://www.wescottdesign.com

I've recently discovered a program called Wolfram Alpha. If you have
an obsessive interest in series expansions, you can spend hours with
this program.

Bob

[John Devereux]

Probably, but there are a lot of sins. Could you be more specific? :)

> Die ganzen Zahlen hat der liebe Gatt gemacht, alles andere ist
> Menschenwerk.

The cycles and times were of course measured averages, the inputs would
have varied. It was just a quick-and-dirty test. This sort of
information seems hard to find for real-world chips.


--

John Devereux

[David Brown]

On 02/05/2012 17:32, Uwe Hercksen wrote:
>
>
> David Brown schrieb:
>
>> <http://en.wikipedia.org/wiki/Lazy_evaluation>
>>
>> The most relevant section, "working with infinite data structures", is
>> missing - but I hope you get the point anyway.
>
> Hello,
>
> even with infinite data structures, with finite time and finite RAM, it
> is not possible to compute all digits of pi.
>

> Bye
>

Calculate pi using "infinite precision" numbers, and you get it to
infinite precision. Obviously you can't print out the whole answer -
but you can print out as much of the answer as you want, until the
machine runs out of memory or time.

An "infinite precision number" is usually held as a list of digits,
along with a method for calculating more digits. You can then write
functions that can add, subtract, multiply and divide such numbers. It
is particularly convenient to use a functional programming language for
such tasks, as they are good at working with unlimited lists, and with
manipulating functions (such as the digit generator function).

To calculate pi, the easiest way is to note that atan(1) = pi/4, and
atan(x) = x - x^3 / 3 + x^5 / 5 - x^7 / 7 + ... Once you have the
individual parts in place, the rest is easy. Of course, you end up with
lots of unlimited lists of unlimited lists, etc.

Mathematically speaking, what you have is precise representation of
/all/ the digits of pi. You can't display them all, as you have limited
ram and time - but it /is/ precise and contains /all/ the digits - just
as "0.33..." is a precise decimal representation of /all/ the digits of
1/3 (the "..." gives the method of producing any digits you want).

[Martin Brown]

On 03/05/2012 08:40, David Brown wrote:
> On 02/05/2012 17:32, Uwe Hercksen wrote:
>>
>>
>> David Brown schrieb:
>>
>>> <http://en.wikipedia.org/wiki/Lazy_evaluation>
>>>
>>> The most relevant section, "working with infinite data structures", is
>>> missing - but I hope you get the point anyway.
>>
>> Hello,
>>
>> even with infinite data structures, with finite time and finite RAM, it
>> is not possible to compute all digits of pi.
>>
>> Bye
>>
>
> Calculate pi using "infinite precision" numbers, and you get it to
> infinite precision. Obviously you can't print out the whole answer - but
> you can print out as much of the answer as you want, until the machine
> runs out of memory or time.

But that isn't how the trick was done. There is a cute expression for
the Nth hexadecimal digit representation of pi detailed at:

http://crd-legacy.lbl.gov/~dhbailey/pi/pi-alg

>
> An "infinite precision number" is usually held as a list of digits,
> along with a method for calculating more digits. You can then write
> functions that can add, subtract, multiply and divide such numbers. It
> is particularly convenient to use a functional programming language for
> such tasks, as they are good at working with unlimited lists, and with
> manipulating functions (such as the digit generator function).
>
> To calculate pi, the easiest way is to note that atan(1) = pi/4, and
> atan(x) = x - x^3 / 3 + x^5 / 5 - x^7 / 7 + ... Once you have the
> individual parts in place, the rest is easy. Of course, you end up with
> lots of unlimited lists of unlimited lists, etc.

No-one in their right mind would start from that crude series today -
its convergence for x=1 is absolutely hopeless. See for example:

http://en.wikipedia.org/wiki/Pi#Infinite_series

> Mathematically speaking, what you have is precise representation of
> /all/ the digits of pi. You can't display them all, as you have limited
> ram and time - but it /is/ precise and contains /all/ the digits - just
> as "0.33..." is a precise decimal representation of /all/ the digits of
> 1/3 (the "..." gives the method of producing any digits you want).

The algorithm that can supply the Nth digits of pi lazily *only* works
for hexadecimal digits (or base 2^N for certain N).

It doesn't work at all for the *decimal* representation of pi.

--
Regards,
Martin Brown

[Jasen Betts]

On 2012-05-02, John Devereux <jo...@devereux.me.uk> wrote:

> spo...@speedymail.org (Steve Pope) writes:
>
>> John Devereux <jo...@devereux.me.uk> wrote:
>>

>>>John S <Sop...@invalid.org> writes:
>>
>>>> I like the idea that both 22 and 7 each fit into a byte whereas 355
>>>> does not. And, 22/7 is hi by only .04%. Beautiful!
>>>
>>>We had a teacher that insisted it was exactly equal!
>>
>> I recall the time when you couldn't consider 25.4 mm to be exactly
>> one inch. But, they fudged enough standards so that it is now exact.
>

> Aha, good idea, we should standardize pi to a more convenient value! :)
>

> (Didn't they already try that?)

>
>> Prior to that, neither the British inch nor the American inch
>> measures 25.4 ... and they deviated from that value in opposite
>> direction!
>

> I suppose the american inch was bigger...
>

I have in my hands an "Nelson's Encyclopedia" printed in 1951 (12
years before the international inch) it says the metre (then
defined by scratches on a bar in Paris) is is about 1.0936143 yards
(then defined by scratches on a bar in London)

1 / 36 / 1.0936143 comes to .025399977m

so, yes the American inch was the bigger of the two.



--
⚂⚃ 100% natural

--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---

[David Brown]

On 03/05/2012 09:55, Martin Brown wrote:
> On 03/05/2012 08:40, David Brown wrote:
>> On 02/05/2012 17:32, Uwe Hercksen wrote:
>>>
>>>
>>> David Brown schrieb:
>>>
>>>> <http://en.wikipedia.org/wiki/Lazy_evaluation>
>>>>
>>>> The most relevant section, "working with infinite data structures", is
>>>> missing - but I hope you get the point anyway.
>>>
>>> Hello,
>>>
>>> even with infinite data structures, with finite time and finite RAM, it
>>> is not possible to compute all digits of pi.
>>>
>>> Bye
>>>
>>
>> Calculate pi using "infinite precision" numbers, and you get it to
>> infinite precision. Obviously you can't print out the whole answer - but
>> you can print out as much of the answer as you want, until the machine
>> runs out of memory or time.
>
> But that isn't how the trick was done. There is a cute expression for
> the Nth hexadecimal digit representation of pi detailed at:
>

I think you missed the earlier post in which I said that I /did/ do
this, as a project at university. There may be other ways to calculate
pi that are more efficient in base 16 - but that's a different matter
entirely.

> http://crd-legacy.lbl.gov/~dhbailey/pi/pi-alg
>>
>> An "infinite precision number" is usually held as a list of digits,
>> along with a method for calculating more digits. You can then write
>> functions that can add, subtract, multiply and divide such numbers. It
>> is particularly convenient to use a functional programming language for
>> such tasks, as they are good at working with unlimited lists, and with
>> manipulating functions (such as the digit generator function).
>>
>> To calculate pi, the easiest way is to note that atan(1) = pi/4, and
>> atan(x) = x - x^3 / 3 + x^5 / 5 - x^7 / 7 + ... Once you have the
>> individual parts in place, the rest is easy. Of course, you end up with
>> lots of unlimited lists of unlimited lists, etc.
>
> No-one in their right mind would start from that crude series today -
> its convergence for x=1 is absolutely hopeless. See for example:
>
> http://en.wikipedia.org/wiki/Pi#Infinite_series

As I said, it was a university project. The aim was not to calculate
pi, but to understand the usage of infinite lists, infinite precision
numbers, ways to manipulate them, and ways to prove that the code to do
so is correct. The rate of convergence is utterly irrelevant.

Just for fun, I figured out an alternative series that was faster to
converge (possibly (atan(1/2) + atan(1/3)), though I can't remember for
sure).

>
>> Mathematically speaking, what you have is precise representation of
>> /all/ the digits of pi. You can't display them all, as you have limited
>> ram and time - but it /is/ precise and contains /all/ the digits - just
>> as "0.33..." is a precise decimal representation of /all/ the digits of
>> 1/3 (the "..." gives the method of producing any digits you want).
>
> The algorithm that can supply the Nth digits of pi lazily *only* works
> for hexadecimal digits (or base 2^N for certain N).
>
> It doesn't work at all for the *decimal* representation of pi.
>

Nonsense. I did it, and I didn't find it particularly hard.

Perhaps you misunderstand what "lazy evaluation" actually is. The
algorithm you reference is a way to calculate a hexadecimal digit of pi
without having to calculate the previous digits - no such method is
known for calculating the decimal digits (though that does not mean one
does not exist). But that has nothing at all to do with lazy
evaluation, which simply means that the relevant numbers are calculated
when needed rather than in advance. It means you can work with an
unlimited list, and treat it as though it were a fully calculated
infinite list, without the computer actually having to calculate
anything until the last minute.

[Jukka Marin]

On 2012-05-02, John Devereux <jo...@devereux.me.uk> wrote:
>> I recall the time when you couldn't consider 25.4 mm to be exactly
>> one inch. But, they fudged enough standards so that it is now exact.
>
> Aha, good idea, we should standardize pi to a more convenient value! :)

We just have to slightly increase the value of 1, so pi will equal 3. :-)

-jm

[xpzzzz]

On Thu, 03 May 2012 12:53:39 +0200, David Brown wrote:

>> The algorithm that can supply the Nth digits of pi lazily *only* works
>> for hexadecimal digits (or base 2^N for certain N).
>>

An YES answer to a question that I have had rattling around for a while,
to wit -

Are there properties (aside from trivial ones) of base-n numbers not
shared by base-a-different-n numbers.

*Why* can you skip ahead to a hex digit of pi but not a dec digit?

Is this unique to pi and base 2^x, or is it true for certain irrational
numbers, or all? If only some, are there similar (lack of) algorithms
for other combinations of base and irrational number(s)?

[David T. Ashley]

On Wed, 02 May 2012 23:55:20 +0200, Stef
<ste...@yahooI-N-V-A-L-I-D.com.invalid> wrote:

>In comp.arch.embedded,
>David T Ashley <das...@gmail.com> wrote:
>>
>> Die ganzen Zahlen hat der liebe Gatt gemacht, alles andere ist
>> Menschenwerk.
>
>You may want to check the spelling on that one. ;-)

I just copied and pasted from a web page, and didn't notice "Gott" vs.
"Gatt".

I'm very much afraid to look up what "Gatt" might be in German.

DTA

[David T. Ashley]

Hey Sinner,

I was just messing with you to throw in a quote from a number theorist
indicating that God approves of the integers only ...

Floating point is trash for the masses (and for prototypes and student
projects). It has no place in serious embedded systems.

Issues:

a)Far slower on low-end micros.

b)Hard to analytically bound the error that arises from calculations
(integers are more friendly in that regard--most errors can be reduced
to the floor() function).

c)God does not approve (see the quote in German above).

DTA

[David Brown]

Proving properties of numbers, such as whether they are rational,
irrational, transcendental, normal, etc., is generally very difficult.
And many of their properties probably have no better explanation than
coincidence.

Pi is known to be "normal", meaning that if you write out its "decimal
expansion" in any base, the digits will be evenly distributed amongst
all possible digits.

[Martin Brown]

On 03/05/2012 12:50, xpzzzz wrote:
> On Thu, 03 May 2012 12:53:39 +0200, David Brown wrote:
>
>>> The algorithm that can supply the Nth digits of pi lazily *only* works
>>> for hexadecimal digits (or base 2^N for certain N).
>>>
>
> An YES answer to a question that I have had rattling around for a while,
> to wit -
>
> Are there properties (aside from trivial ones) of base-n numbers not
> shared by base-a-different-n numbers.
>
> *Why* can you skip ahead to a hex digit of pi but not a dec digit?

Because an infinite series expansion for PI is known where all the
components being summed together are of the form sum ( 1/16^k.f(k) )

It is therefore possible to start from a chosen digit position and
compute just the digits of interest from there on. The URL I posted
describes a bit more of the details of the algorithm.

> Is this unique to pi and base 2^x, or is it true for certain irrational
> numbers, or all? If only some, are there similar (lack of) algorithms
> for other combinations of base and irrational number(s)?

It is entirely possible that some other irrationals may have an elegant
series expression in some base or other, but off hand I don't know of
any other commonly known examples of this. A quick back of the envelope
playing around suggests that the golden ratio phi may well have an
expansion base 8 that is amenable to the same sort of trick.

phi = (1 + sqrt(5))/2 = 1/2 + sqrt(1 + 1/4)

series expansion for sqrt(1+x) with x = 1/4

1/2 + 1 + x/2 - x^2/2!/4 + 3x^3/3!/8 - ...

1 + 1/2 + 1/8 - sum[k=2,inf]{ 1/(-4^k) ((2k-3)!/((k-2)!k!) }

as ever subject to mistakes, typos and algebra errors.

--
Regards,
Martin Brown

[Ignacio G.T.]

In article <65c01ed5-a89a-4a80-b9f3-60967af49a00
@s9g2000pbq.googlegroups.com>, gyans...@gmail.com says...

>
>
> That's the British customary units, not English, that's the language
> you are confusing with the country which is Great Britain. another
> common mishtake made by americans.

You surely mean inhabitants of the United States of America. Mexicans,
Argentinians and Cubans, though Americans themselves, don't confuse
English and British. Another common mistake made by yankees :-)

[Spehro Pefhany]

On Wed, 2 May 2012 23:38:26 -0700 (PDT), Robert Adams
<robert...@analog.com> wrote:

>
>I've recently discovered a program called Wolfram Alpha. If you have
>an obsessive interest in series expansions, you can spend hours with
>this program.
>
>Bob

Interesting!

Taylor Maclaurin expansions are great for getting insight into
nonlinear stuff.

http://www.wolframalpha.com/entities/calculators/taylor_series_calculator/ew/pd/4g/

Of course MATLAB and such like will do this, but they don't work for
free.

[John Devereux]

David T. Ashley <das...@gmail.com> writes:

I only seem to be using ARMs now, Cortex M3 or M4 in new projects.

> b)Hard to analytically bound the error that arises from calculations
> (integers are more friendly in that regard--most errors can be reduced
> to the floor() function).

It is also hard to work with integer representations of real-world
quantities. You have to scale everything to fit, keep track of units and
scaling factors. Keep track of overflows and underflows, loss of
precision. Decide what register width to use for each step of the
calculation, and use the correct types to achieve this. Rewrite the
calculation so as to minimise the dynamic range of intermediate
values. With floats you can usually just convert to standard units at
the start of the calculation, and not worry too much about it. If you
really need high precision then there are doubles.

> c)God does not approve (see the quote in German above).

Also there is worrying about floating point registers in context
switches, non-atomic operations and inconsistent or ambiguous data
formats.

I do still keep most things integer until they are "used" - an array of
ADC values say. But it is kind of a load off to be able to just work
directly in the applications natural units when I want to.

--

John Devereux

[Andre]

Scilab is free...

[Richard Owlett]

I've some Canadian relatives who were very vocal on their
right to be called American.

[Jeroen Belleman]

Yeah, but you'd have an irrational number of fingers.

Jeroen Belleman

[RCIngham]

And I would not be surprised that floating-point numbers were also an
ABOMINATION UNTO NUGGAN.


---------------------------------------
Posted through http://www.EmbeddedRelated.com

[Jerry Avins]

On 5/1/2012 7:16 PM, Tim Wescott wrote:
> Instead of doing productive work, I just spent a few enjoyable minutes
> with Scilab finding approximations to pi of the form m/n.
>
> Because I'm posting to a couple of nerd groups, I can be confident that
> most of you probably know 22/7 off the tops of your heads.
>
> What interested me is how spotty things are -- after 22/7, the error
> drops for a bit until you get down to 355/113 (which, if you're at an
> equal level of nerdiness to me will ring a bell, but not have been
> swimming around in your brain to be found).
>
> But what's _really_ interesting, is that the next better fit isn't found
> until you get up to 52163/16604. Then things get steadily better until
> you hit 104348/33215 -- at which point the next lowest ratio which
> improves anything is 208341/66317, then 312689/99532. At this point I
> decided that I would post my answers for your amusement, and get back to
> being productive.
>
> Discrete math is so fun. And these newfangled chips are just destroying
> the joy, by making floating point efficient and cheap enough that you
> don't need to know little tricks like pi = (almost) 355/113.

Try sqrt(2). 7/5 is fair. 17/12 is good enough for carpentry. 41/29 has
less than one fifth of that error, but 99/70 is much better yet. In
fact, the best (in terms of accuracy per bit expended) have an odd
numerator and an even denominator.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

[Rob Gaddi]

Mac, you clearly haven't learned about the continual march of
technological progress.

It won't get better if you Pickett.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

[Robert Wessel]

BBP's original paper (link below) lists a number of other examples,
including log(2), log (9/10), pi**2, many base 2 logs, ... Others
have computed other constants (see Wiki article for links)


http://www.ams.org/journals/mcom/1997-66-218/S0025-5718-97-00856-9/home.html

http://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%93Plouffe_formula

[Les Cargill]

Octave is...

--
Les Cragill

[Spehro Pefhany]

Yup, Octave and Scilab. But not Mathematica, MathCAD, MATLAB etc.

[David T. Ashley]

On Thu, 03 May 2012 15:19:28 +0100, John Devereux
<jo...@devereux.me.uk> wrote:

>David T. Ashley <das...@gmail.com> writes:
>>
>> Issues:
>>
>> a)Far slower on low-end micros.
>
>I only seem to be using ARMs now, Cortex M3 or M4 in new projects.
>
>> b)Hard to analytically bound the error that arises from calculations
>> (integers are more friendly in that regard--most errors can be reduced
>> to the floor() function).
>
>It is also hard to work with integer representations of real-world
>quantities. You have to scale everything to fit, keep track of units and
>scaling factors. Keep track of overflows and underflows, loss of
>precision. Decide what register width to use for each step of the
>calculation, and use the correct types to achieve this. Rewrite the
>calculation so as to minimise the dynamic range of intermediate
>values. With floats you can usually just convert to standard units at
>the start of the calculation, and not worry too much about it. If you
>really need high precision then there are doubles.

Alll valid points.

But, in the interest of furthering my own point of view, I will ignore
all facts that don't support it.

Also, in the tradition set by the church, I'm introducing an "Index of
Prohibited Books" (I'll e-mail you the first revision). From this
point forward, all books that mention floating point are prohibited.

Also, any books that conjecture that the Earth revolves around the Sun
are prohibited.

Books that conjecture that the Earth revolves around the Sun and where
floating-point arithmetic was used to arrive at that conclusion are
doubly prohibited.

DTA

[David T. Ashley]

On Thu, 03 May 2012 10:57:55 -0500, "RCIngham"
<robert.ingham@n_o_s_p_a_m.gmail.com> wrote:

>>
>>c)God does not approve (see the quote in German above).
>>
>>DTA
>>
>
>And I would not be surprised that floating-point numbers were also an
>ABOMINATION UNTO NUGGAN.

Thanks for the literary link. Yet more books that I will never have
time to read. As Carl Sagan said, there is only time to read a few
thousand good books in a human lifetime. I'm not a spring chicken,
and at this point I have to choose carefully.

DTA

[Jukka Marin]

Hmm.. true, but I think I ned pi more often than the number of my fingers,
so I think it would be a win.

-jm

[Stephen Pelc]

On Thu, 03 May 2012 09:56:24 -0500, Richard Owlett
<row...@pcnetinc.com> wrote:

>> You surely mean inhabitants of the United States of America. Mexicans,
>> Argentinians and Cubans, though Americans themselves, don't confuse
>> English and British. Another common mistake made by yankees :-)
>
>I've some Canadian relatives who were very vocal on their
>right to be called American.

I thought that the PC term for "Murricans" is "USAnians".

Stephen


--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[Scott Hemphill]

John Larkin <jjla...@highNOTlandTHIStechnologyPART.com> writes:

> On Wed, 02 May 2012 11:10:53 +0200, David Brown
> <da...@westcontrol.removethisbit.com> wrote:

>
>>On 02/05/2012 01:16, Tim Wescott wrote:
>>> Instead of doing productive work, I just spent a few enjoyable minutes
>>> with Scilab finding approximations to pi of the form m/n.
>>>
>>> Because I'm posting to a couple of nerd groups, I can be confident that
>>> most of you probably know 22/7 off the tops of your heads.
>>>
>>> What interested me is how spotty things are -- after 22/7, the error
>>> drops for a bit until you get down to 355/113 (which, if you're at an
>>> equal level of nerdiness to me will ring a bell, but not have been
>>> swimming around in your brain to be found).
>>>
>>> But what's _really_ interesting, is that the next better fit isn't found
>>> until you get up to 52163/16604. Then things get steadily better until
>>> you hit 104348/33215 -- at which point the next lowest ratio which
>>> improves anything is 208341/66317, then 312689/99532. At this point I
>>> decided that I would post my answers for your amusement, and get back to
>>> being productive.
>>>
>>> Discrete math is so fun. And these newfangled chips are just destroying
>>> the joy, by making floating point efficient and cheap enough that you
>>> don't need to know little tricks like pi = (almost) 355/113.
>>>
>>

>>Wikipedia is often a great starting point for these sorts of things. It
>>typically has enough information to give you some hints - but not so
>>much that you can't have fun finding out more:
>>
>><http://en.wikipedia.org/wiki/Pi#Continued_fractions>
>>
>>
>>At university I remember a project that involved calculating all the
>>digits of pi. It was written using a functional programming language
>>(similar to Haskell) - the result was an unending list of the digits of
>>pi. But since the language used lazy evaluation, it didn't bother
>>calculating the entries until you tried to print them out. I used
>>polynomial expansions of arctan() to do the sums.
>
> There was a short PDP-8 assembly program that printed the digits of e
> forever.

Yes, it is pretty easy to write a program to calculate e. e has the
value 2.11111111... in factorial radix. The first digit after the radix
point is in the 1/2 place, the next is in the 1/6 place, and so on. All
you have to do to print out the value of e is convert to base 10.

Scott
--
Scott Hemphill hemp...@alumni.caltech.edu
"This isn't flying. This is falling, with style." -- Buzz Lightyear

[Hans-Bernhard Bröker]

On 03.05.2012 16:19, John Devereux wrote:

> It is also hard to work with integer representations of real-world
> quantities. You have to scale everything to fit, keep track of units and
> scaling factors.

That's actually pretty much the only definite advantage of floats. You
can express everything in actual SI units, and the FP engine will take
care of all the large and small powers-of-ten for you.

> Keep track of overflows and underflows, loss of
> precision.

Same with floats, except that people so get used to being able to ignore
these most of the time that when they _do_ come back to bite, the
results will be even more hilarious/disastrous.

To paraphrase another old adage: An integer can become huge; but for
your result to become totally _infinite_, you need floats.

> Decide what register width to use for each step of the
> calculation, and use the correct types to achieve this.

Same with floats unless you go "ach, to hell with excess memory
consumption" and do everything, including result storage, in maximum
available precision (double precision or more).

And then of course, there's the big catch: the actual resolution of a
single-precision float is not really all that great. The C programming
language only guarantees a resolution of 1.0e-5 --- that is less than 2
bits better than a signed fixed point number which would fit in an int16_t!

Granted, these days you're pretty much certain the FP format will be
better than the minimum required --- but I will _not_ be the one to let
reality intrude on this nice little hair-splitting session ;-P

[glen herrmannsfeldt]

In comp.dsp David Brown <da...@westcontrol.removethisbit.com> wrote:

(snip)

> I think you missed the earlier post in which I said that I /did/ do
> this, as a project at university. There may be other ways to calculate
> pi that are more efficient in base 16 - but that's a different matter
> entirely.

Not necessarily more efficient, but you can compute the Nth hexadecimal
digit of pi without computing the N-1 digits in between.

One use is for testing a computation using a different algorithm.

There is a web page by someone who has computed trillions of
decimal digits, doing the computation in binary and then converting
to decimal. At various points, the result is compared against
hex digits computed using the other algorithm.

-- glen

[glen herrmannsfeldt]

In comp.dsp xpzzzz <xpz...@nowhere.com> wrote:
> On Thu, 03 May 2012 12:53:39 +0200, David Brown wrote:

>>> The algorithm that can supply the Nth digits of pi lazily *only* works
>>> for hexadecimal digits (or base 2^N for certain N).
>>>

> An YES answer to a question that I have had rattling around for a while,
> to wit -

> Are there properties (aside from trivial ones) of base-n numbers not
> shared by base-a-different-n numbers.

> *Why* can you skip ahead to a hex digit of pi but not a dec digit?

As far as I know, it is that no-one has yet found the algorithm
that expands to decimal digits. It is convenient for users of
binary computers that there is one for base 16. (One could have
been less lucky, and had it come out in base 13.)

> Is this unique to pi and base 2^x, or is it true for certain
> irrational numbers, or all? If only some, are there similar
> (lack of) algorithms for other combinations of base and
> irrational number(s)?

Pi is a little unusual, in that there are many different ways
to compute it. It might be that square roots could have a
similar algorithm, but then, as I remember it, they are just
irrational but not transcendental.

There are some irrational numbers that have nice simple
definitions, such as ln(2). Roots of Bessel functions might
be another interesting case to look at.

-- glen

[Jerry Avins]

On 5/2/2012 1:43 AM, Steve Pope wrote:
> John Devereux<jo...@devereux.me.uk> wrote:
>
>> John S<Sop...@invalid.org> writes:
>
>>> I like the idea that both 22 and 7 each fit into a byte whereas 355
>>> does not. And, 22/7 is hi by only .04%. Beautiful!
>>
>> We had a teacher that insisted it was exactly equal!

>
> I recall the time when you couldn't consider 25.4 mm to be exactly
> one inch. But, they fudged enough standards so that it is now exact.
>

> Prior to that, neither the British inch nor the American inch
> measures 25.4 ... and they deviated from that value in opposite
> direction!

Actually, the US has been officially metric since 1866. At that time,
the inch was defined as 1/39.37 meters. (The standard meter was then the
distance between two marks on an iron -- later platinum-iridium -- bar
in Paris.) That made the inch 25.40000508001 millimeters long.

In 1960 the meter was defined as 1,650,763.73 wavelengths of the
orange-red line of krypton 86, and the inch was redefined to be 25.4 mm
exactly about a year earlier. (I saw no need to replace my micrometer.)
In order to maintain the integrity of old geodetic records, The old foot
is now named a survey foot. A survey foot is 1.000002 modern foot. Life
is messy.

[Jerry Avins]

On 5/2/2012 10:53 PM, glen herrmannsfeldt wrote:
> In comp.dsp VWWall<vw...@large.invalid> wrote:
>
> (snip, I wrote)
>>> One involves a more accurate determination of Avogadro's number.
>
>> Avogadro's number is currently: 6.02214129*10^23 entities per mole and
>> has an uncertainty of plus or minus 27 counts in its last two digits.
>
> The ongoing project involves weighing and counting the number
> of atoms in a silicon sphere. When you figure out how many are
> in a kg, that could be, should be, an integer.

Eh? Suppose a bag of shot with each piece weighing an ounce. An integer
number of pieces will surely not fill any arbitrary volume.

[Jerry Avins]

On 5/2/2012 9:34 PM, George Herold wrote:
> On May 2, 3:44 pm, Syd Rumpo<use...@neonica.co.uk> wrote:
>> On 02/05/2012 16:20, George Herold wrote:
>>
>> <snip>
>>
>>> Grin... I always just let 2*pi = 10, so pi = 5!
>>
>> That's known as a 'Selleck' or a 'Magnum PI'.
>>
>> Cheers
>> --
>> Syd
>
> Chuckle... That's great...
>
> I was thinking that most of the time I let 1/2pi = 1.6/10 or pi = 10
> x 5/16 which is better than 1%.

We're not so far apart. I often use 25 (~ circumference of earth in
kilomiles) / 8 (~ approximate diameter).

[Robert Wessel]

On Thu, 03 May 2012 17:30:52 -0400, Jerry Avins <j...@ieee.org> wrote:

>On 5/2/2012 10:53 PM, glen herrmannsfeldt wrote:
>> In comp.dsp VWWall<vw...@large.invalid> wrote:
>>
>> (snip, I wrote)
>>>> One involves a more accurate determination of Avogadro's number.
>>
>>> Avogadro's number is currently: 6.02214129*10^23 entities per mole and
>>> has an uncertainty of plus or minus 27 counts in its last two digits.
>>
>> The ongoing project involves weighing and counting the number
>> of atoms in a silicon sphere. When you figure out how many are
>> in a kg, that could be, should be, an integer.
>
>Eh? Suppose a bag of shot with each piece weighing an ounce. An integer
>number of pieces will surely not fill any arbitrary volume.

A lump of pure silicon must, by definition, contain an integral number
of silicon atoms.

[m II]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim Wescott wrote:

> Discrete math is so fun.

Just the opposite of Indiscreet math, which usually involves blackmail
payment sums for having made errors in judgment.

mike





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPozYrAAoJEDTMN7GV3zbXsloH/A4ZchjOLd1IcAJbBoEqTUjl
s3kp9BUlNEQsk2OcOgoAS3ugLfzgf+UnxeY0dgZPKdJnIIwtzWzkX/I0XQRLOyR8
q6nTbOVofL2laM88sNIE7lJgZcz3dIR2f3tpb+Roe4z37eyF23H+Mu45B/pi/5Pi
zHSyS9XqmqY2pgNgozjYA/IPGqtbj8XbFYYBOvA0nl6reBb7akOoHC8/ZTrPg+vh
X18WlpaY7ZVXaxlGnsK59NB3vhT6xLfh+5WW0B7Tjthr7zm24WBUGDB+cI7iwN7V
4kF9hFTsrgOqux/kJ15KCdihWgrquC1Gur7iGDBAvLb7yyhKxqnRHEQ6kcvzhAU=
=vh82
-----END PGP SIGNATURE-----

[Steve Pope]

Jasen Betts <ja...@xnet.co.nz> wrote:

>On 2012-05-02, John Devereux <jo...@devereux.me.uk> wrote:

>> I suppose the american inch was bigger...

>I have in my hands an "Nelson's Encyclopedia" printed in 1951 (12
>years before the international inch) it says the metre (then
>defined by scratches on a bar in Paris) is is about 1.0936143 yards
>(then defined by scratches on a bar in London)
>
> 1 / 36 / 1.0936143 comes to .025399977m
>
>so, yes the American inch was the bigger of the two.

I have a 30's-era CRC handbook which confirms that the Amer-inch
and Brit-inch were then different, and bracketed the value of
the Modern Inch.


Steve

[Les Cargill]

I haven't hit a case with Octave where it left me needing MATLAB...
but I don't use it very heavily.

--
Les Cargill

[Andrew Smallshaw]

On 2012-05-03, Les Cargill <lcarg...@comcast.com> wrote:
>
> Avogadro's Number is a natural number - so yes.

No. It stands to reason that Avogadro's number is not only not
integral but irrational at truly arbitrary levels of precision.
To make the arithmetic slightly easier to grasp consider for a
moment an alternative reality where atoms are rather more massive
and a C-12 atom has a mass of exactly 5g. A mole of C-12 MUST have
a mass of 12g and so a mole works out at 2.4 atoms.

In reality the mass of an atom is almost infinitely less, but there
is still the problem that n C-12 atoms have a mass of 11.9999...9998712g
but n+1 atoms have a mass of 12.0000...0003425g. There's no reason
at all to suppose that an exact integral relationship must exist.
In practice of course you could round off to the nearest atom or
even tens of billions of atoms with no real-world impact at all,
but that is not how Avogadro's number is _currently_ defined.

--
Andrew Smallshaw
and...@sdf.lonestar.org

[Tim Williams]

Too bad the binding energy amounts to more than several atoms' mass, and
likely isn't an integral number.

The mass of a silicon atom is around 27GeV/c^2, so at an average binding
energy of 2eV or so, it only takes 1.3e9 atoms in a pile (a grain of about
fractional um size) to accrue an extra atom's worth of mass-energy.

They could define it in terms of mass at infinity (unbound) per atom, but
that doesn't make much sense when you have a polished sphere or whatever
containing a few faraday volts of 'excess' binding energy.

Tim

--
Deep Friar: a very philosophical monk.
Website: http://webpages.charter.net/dawill/tmoranwms

"Andrew Smallshaw" <and...@sdf.lonestar.org> wrote in message
news:slrn3vfsjq6jg...@sdf.lonestar.org...

[Steve Pope]

Tim Williams <tmor...@charter.net> wrote:

>Too bad the binding energy amounts to more than several atoms' mass, and
>likely isn't an integral number.

>The mass of a silicon atom is around 27GeV/c^2, so at an average binding
>energy of 2eV or so, it only takes 1.3e9 atoms in a pile (a grain of about
>fractional um size) to accrue an extra atom's worth of mass-energy.

I assume they include the mass associated with binding energy
when they do the calculation.

Steve