flat assembler
Message board for the users of flat assembler.
Index
> Heap > What is the best pie you can get with 9 digits? Goto page Previous 1, 2, 3 ... 26, 27, 28, 29 Next 
Author 

YONG
Latest submission by me:
(8*2) / (4^(73/(659))  1) = 3.14159260364 ... which is correct to 7 decimal places! Since my expression is based on the result generated by bitRAKE's program and bitRAKE's program is based on the script written by T.G., the honors should be shared between the three of us. So, the best answer as of now is correct to 7 decimal places: YONG & bitRAKE & T.G.: (8*2) / (4^(73/(659))  1) = 3.14159260364 ... 

08 Feb 2017, 09:06 

bitRAKE
Good thinking YONG. I don't feel I should take credit for anything, but I enjoy being included in an interesting discussion. Tomasz helped me see a high level overview of the problem  an effective way to fit the pieces together.
3^(1+((546)^(2/7))/8/9) = 3.14159262816... Smaller absolute error. We might ask for approximations of any irrational under these constraints: Euler's number, sqrt(2), etc. 

08 Feb 2017, 23:31 

YONG
pi = 3.14159265358979323846264338327950288419716939937510582 ...
So, the latest result generated by bitRAKE's program is a bit closer. The best answers as of now are correct to 7 decimal places: bitRAKE & T.G.: 3^(1+((546)^(2/7))/8/9) = 3.14159262816 ... YONG & bitRAKE & T.G.: (8*2) / (4^(73/(659))  1) = 3.14159260364 ... Hope that we can have 10 or more decimal places. If so, the old expression found by B. Ziv in 2004 will be superceded: https://www.futilitycloset.com/2010/05/12/pandigitalapproximations/ 

09 Feb 2017, 02:03 

revolution
The notes for value for e states:
... reproduces e to 18,457,734,525,360,901,453,873,570 decimal places. Another site claims the world record for digits of e is "only" 5,000,000,000,000 digits. This is about 13 orders of magnitude fewer. And this seems more reasonable. Did I misunderstand something? 

09 Feb 2017, 03:32 

sleepsleep
neville wrote:
thanks for the information, i was thinking there are 2 integers, a / b that produce infinite answer that becoming pi number, feels very weird, 

09 Feb 2017, 04:27 

YONG
revolution wrote: The notes for value for e states: https://www.youtube.com/watch?v=xgBGibfLDU I don't think we actually need to store all the decimal places for the verification process. e = lim[n > infinity] (1 + 1/n)^n As n gets bigger and bigger, the calculated value of e gets more and more decimal places. There is a wellstudied relationship between the value of n and the number of decimal places of the calculated value of e. In the given pandigital expression, n is just 9^4^42, a very big number. Refer to: https://en.wikipedia.org/wiki/E_(mathematical_constant)#Alternative_characterizations 

09 Feb 2017, 05:32 

revolution
Okay, yeah, 9^4^42 = 3^2^85. Makes sense.
Thanks for the explanation. 

09 Feb 2017, 05:44 

bitRAKE


09 Feb 2017, 06:16 

revolution
So one of those pandigital approximations does comply with the rules given here and gives 9 digits:
E. Pegg: 3+(1(98^(5))^(6))/(7+2^(4)) = 3.1415926539165... 

09 Feb 2017, 06:33 

YONG
revolution wrote: So one of those pandigital approximations does comply with the rules given here and gives 9 digits: a^(b) = 1 / a^b At least one digit is saved if we allow negative powers. 

09 Feb 2017, 06:49 

revolution
YONG wrote: ...negative powers are not allowed. YONG wrote: The rules are: 

09 Feb 2017, 06:51 

YONG
Refer to:
https://board.flatassembler.net/topic.php?p=192799#192799 I am just following the "teachings" of a wise forum member! 

09 Feb 2017, 07:01 

revolution
Yes, I am aware of that post. But you never explicitly disallowed unary minus. You just said "allowing unary minus ...". And indeed you said in that post you are keeping the same rules. And the way I read the rules unary minus is allowed. It is a basic arithmetic operation.
If you want to alter the rules then that is a different matter. So perhaps you want to state that you are modifying the rules, and what the new rules are? E. Pegg will be so disappointed. 

09 Feb 2017, 07:18 

YONG
The challenge is to find the best zeroless pandigital approximation of pi.
The rules are:  Every digit from 1 to 9 must be used exactly once.  No decimal point can be used.  Only basic arithmetic operations are allowed: +, , *, /, (), power.  No radical sign can be used.  The unary minus operation is disallowed. The rationale is to keep the rules as restrictive as possible. As of now, the best answers are correct to 7 decimal places: bitRAKE & T.G.: 3^(1+((546)^(2/7))/8/9) = 3.14159262816 ... YONG & bitRAKE & T.G.: (8*2) / (4^(73/(659))  1) = 3.14159260364 ... The goal is to have 10 or more decimal places. If achieved, the old expression found by B. Ziv in 2004 will be superceded: https://www.futilitycloset.com/2010/05/12/pandigitalapproximations/ Good luck. Last edited by YONG on 09 Feb 2017, 08:42; edited 1 time in total 

09 Feb 2017, 07:52 

revolution
YONG wrote: The rules are: E. Pegg: 3+(1(98^(05))^(06))/(7+2^(04)) = 3.1415926539165... You didn't say anything about the digit zero, so I assume it is allowed. 

09 Feb 2017, 08:22 

YONG
Thanks for pointing out the omission.
Added "zeroless" before "pandigital approximation of pi". 

09 Feb 2017, 09:22 

neville
sleepsleep wrote: feels very weird, Code: Some rational approximations of pi ................correct to: 22/7 = 3 + 1/7 = 3.142857 142857 142857... 2 decimal places only! 355/113 = 3 + 16/113 = 3.14159292035398... 6 decimal places 103993/33102 = 3 + 4687/33102 = 3.1415926530119... 9 decimal places _________________ FAMOS  the first memory operating system 

09 Feb 2017, 22:54 

YONG
A spinoff challenge:
Using this set of four digits, {1, 2, 5, 9}, form an expression that gives the exact value of 33102. Same rules apply. 2^15 + 9 = 32777 ...... Close but not good enough! 

10 Feb 2017, 03:28 

revolution
YONG wrote: A spinoff challenge: 3+4687/Get33102From(1,2,5,9) gives 9 DP. 

10 Feb 2017, 03:41 

Goto page Previous 1, 2, 3 ... 26, 27, 28, 29 Next < Last Thread  Next Thread > 
Forum Rules:

Copyright © 19992020, Tomasz Grysztar.
Powered by rwasa.