flat assembler
Message board for the users of flat assembler.

 Index > Heap > BBP-like formulae (Originally in Test Area)
Author
windwakr

Joined: 30 Jun 2004
Posts: 827
Location: Michigan, USA
windwakr
This will be my "post random crap" thread again until it disappears like last time.

Very odd series I just "found":
The series is a small change to the BBP-type formula for ln(9/10), but produces very odd results.

Code:
```
infinity
------
\
\             1
/         -----------
/            k10^(kk)
------
k=1
```

Look at the results starting about 50 after the decimal point.

Numbers, they'll never cease to amaze me.

For lazy people....

0.10005000033333335833333335333333333350000000000001428571428571429821428571428571439682539682539682540682539682539682539683448773448773448773448781782106782106782106782107551337551337551337551337552051837051837051837051837051843718503718503718503718503718504343503718503718503718503718503719091953797836150777327247915483209606412215235744647509353391706332882803997354554630096425762060436983037602233148672277155249291472201688919955173825147627295305313881165274354128843292929980236936329923946023

EDIT: Wow, even better. Replace k10^(kk) with k10^(kkk)

EDIT2: Another pointless "post".

New BBP-type formula. It lets you extract the n-th decimal digit of ln(100/81). Ah 100/81, such a silly number.

Code:
```                    infinity
------
\
ln(100/81) =          \               1
/         -----------
/         (10^k)*(0.5*k)
------
k=1

```

To get the n-th digit:

Code:
```      n                                           infinity(probably only need a few sums here)
------                                           -----
\                                                \
\      10^(n-k) mod (0.5*k)      Mod 1   +       \    10^(n-k)        Mod 1
/          ---------------                       /    ---------
/                 0.5*k                          /      0.5*k
------                                           ----
k=1                                            j=n+1
```

Damn you, variable width font!

_________________
----> * <---- My star, won HERE

Last edited by windwakr on 20 Aug 2010, 21:39; edited 1 time in total
12 Aug 2010, 22:16
Tyler

Joined: 19 Nov 2009
Posts: 1216
Location: NC, USA
Tyler
windwakr wrote:
For lazy people....
Thanks!
13 Aug 2010, 05:38
windwakr

Joined: 30 Jun 2004
Posts: 827
Location: Michigan, USA
windwakr
Another pointless post in a pointless thread.

Played around a little with Pari/gp and the lindep function, and found this variation of the BBP Pi formula:

I think it's interesting. Except for the 16 in there, everything is a multiple of 5.

EDIT: Lol, didn't even notice something. It's just the normal formula, except that every number except the (1/16^k) is multiplied by 5. Weird.

_________________
----> * <---- My star, won HERE
17 Aug 2010, 01:13
bitRAKE

Joined: 21 Jul 2003
Posts: 2903
Location: [RSP+8*5]
bitRAKE
19 Aug 2010, 07:00
windwakr

Joined: 30 Jun 2004
Posts: 827
Location: Michigan, USA
windwakr
Neat, bitRAKE.

Here comes yet another dumb post by me.

I know that sadly there's no decimal BBP Pi algorithm, but what about Pi approximations?

Take the vector:
Code:
```[-5, 34, 29, -43, -6, 10, -7, 26, -12, -18, 0, -32, 7, -49, -19, 11, -32, 32, -13, 7, 28, 2, -30, -3, 27, -4, -25, -42, -13, -1, -21, 7, 42, 3, 4, -35, 32, -64, 25, 32, 27, 4]~
```

Now S1+S2+S3...S46, where Si =
Code:
```
oo
---
S =   v[i] *   \       1
i             /     ------
--- (10^k)*48k+i
k=0
```

You now have an approximation of Pi to ~80 digits, and you are able to extract digits from it.

I had one that was good to around 300 digits, but lost it.

Maybe someone could find an approximation that has millions/billions/trillions of digits?

_________________
----> * <---- My star, won HERE

Last edited by windwakr on 20 Aug 2010, 21:40; edited 1 time in total
20 Aug 2010, 20:43
LocoDelAssembly

Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
It is OK if I move the posts from here to Heap?
20 Aug 2010, 21:14
windwakr

Joined: 30 Jun 2004
Posts: 827
Location: Michigan, USA
windwakr
I don't care.
20 Aug 2010, 21:21
bitRAKE

Joined: 21 Jul 2003
Posts: 2903
Location: [RSP+8*5]
bitRAKE
For me the interesting thing about BBP-like algorithms is the "compression" of information. Many algorithms are possible which don't reduce the space-time complexity. BBP seems to packet-ize the space requirements and dependencies - which the "possibility of" is completely outside of obvious.
wikipedia wrote:
This process is similar to performing long multiplication, but only having to perform the summation of some middle columns. While there are some carries that are not counted, computers usually perform arithmetic for many bits (32 or 64) and they round and we are only interested in the most significant digit(s). There is a vanishingly small possibility that a particular computation will be akin to failing to add a small number (e.g. 1) to the number 999999999999999 and that the error will propagate to the most significant digit, but being near this situation is obvious in the final value produced.
Precision is a limiting factor, but a probabilistically small one. Might be an interesting challenge to determine the failure points at different precisions?
21 Aug 2010, 02:22
 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First

 Jump to: Select a forum Official----------------AssemblyPeripheria General----------------MainDOSWindowsLinuxUnixMenuetOS Specific----------------MacroinstructionsCompiler InternalsIDE DevelopmentOS ConstructionNon-x86 architecturesHigh Level LanguagesProgramming Language DesignProjects and IdeasExamples and Tutorials Other----------------FeedbackHeapTest Area

Forum Rules:
 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou can attach files in this forumYou can download files in this forum