Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
I wrote possibly the most inefficient algorithm ever to calculate the user's choice for any number of digits of pi.


Code:
2->dim(|LM)
2->dim(|LV)
0->Z
0->C
Disp "DIGITS TO CALCULATE
Prompt N
100^(N-1)->|LM(2)
1->|LM(1)
0->|LV(1)
0-1->|LV(2)
Repeat Z

   |LV(1)->U
   |LV(2)->Y

   (|LM(1)-|LM(2))/(|LM(1)+|LM(2))U+2|LM(2)/(|LM(1)+|LM(2))Y->|LV(1)
   2|LM(1)/(|LM(1)+|LM(2))U+(|LM(2)-|LM(1))/(|LM(1)+|LM(2))Y->|LV(2)

   If |LV(2)-|LV(1)<0 or |LV(1)<0
   Then
      C+1->C
   Else
      1->Z
   End

   (0-1)|LV(1)->|LV(1)

   If |LV(2)-|LV(1)<0 or |LV(1)<0
   Then
      C+1->C
   Else
      C+1->C
      1->Z
   End
   
   Disp C/(10^(N-1))
   
End


As you can probably see, it doesn't use any trigonometry or calculus. In fact, the inspiration for this algorithm comes from probably the most unexpected place possible: idealized elastic collisions in classical Newtonian Dynamics.

Basically, the math describes the velocities of two objects (one which is 100^(N-1) times the mass of the other, where N= the number of digits to calculate) as the larger one pushes the smaller one toward an immovable wall over a frictionless floor.

The only thing the algorithm outputs is the number of collisions (divided by powers of ten based off how many digits it will calculate).

A fantastic video illustrating this phenomenon by YouTuber 3blue1brown says it way better than I could:

https://www.youtube.com/watch?v=HEfHFsfGXjs

This is elegant and all, but this algorithm takes pi(10^(N-1)) loops of the repeat function to complete.
As such I made the program count up to the final value on the screen to make the process the tiniest bit more fun to watch as you wait patiently for an output only a few digits long.

I just found it very interesting that it's possible to calculate pi using only a ratio (even though pi is irrational) and iterations of very simple algebra. Hope you guys find it food for thought!
I wonder how long this actually works before you run into numerical issues. Surely it's before 7 digits of pi (mass ratio = 10^14 and the calculator only has 14 digits of precision) but maybe there are problems before that.
lirtosiast wrote:
I wonder how long this actually works before you run into numerical issues. Surely it's before 7 digits of pi (mass ratio = 10^14 and the calculator only has 14 digits of precision) but maybe there are problems before that.


I assume the maximum number of accurate digits would be limited by the maximum velocity of the smaller mass. If it's bouncing back and forth at a velocity more than the calculator's accuracy limit, then it won't be able to factor that velocity correctly. Not sure when this would happen though, I suppose I could store the velocity values into a table and look at maximums somehow, but I don't know the mathematical relationship between the max velocity and the mass ratio so it's hard to say. I've tested it up to five digits though and it worked fine then.
I'd never heard of this method before so I looked it up and this is definitely one of the most interesting ways to calculate pi Razz
I found this very interesting and thought I壇 give it a try on my TI 84 Plus SE calculator. I ran it with 3 digits and got 3.14 . It took 28.64 seconds to run, displaying each result as it ran. I then changed it to display the final result when it finished and that took 18.52 seconds. I then tried it on my iPad and here are the results for that. Again, it was changed to display the result when it was finished running. This show the value of Pi and the seconds it took to run on the iPad.


3.0覧覧覧0.000009059906
3.1覧覧覧0.000030040740
3.14覧覧-0.000205039978
3.141覧覧0.002496004104
3.1415覧覧-0.018313169479
3.14159覧覧0.110126018524
3.141592覧1.021538019180
3.1415926覧-9.554212808609
3.1415926591.802348136902

Another thing I was able to do on my ipad was to use the Physics engine and graphics to program 2 balls and a wall. As the first ball rolled into the second ball, the program counted the number of collisions the second ball had with the wall and the first ball. The count was 31 which resulted in a value of 3.1 for 2 digits of Pi. That was using a mass of 100 for the first ball and a mass of 1 for the second ball. I tried a mass of 1000 for the first ball, but the physics engine wasn稚 able to handle the speed of the second ball during all the collisions and the second ball passed thru the first ball and went off the screen.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement