This also makes sense from data compression theory. If the digits of an irrational / transcendental number share some of the properties of a random string, then you shouldn't be able to compress it. And finding a fractional representation with fewer total digits is a form of data compression.
Is the symbol for pi considered "compression"? Why or why not?
You have to include an algorithm for decompressing it into enough information to answer a relevant question (in this post's case) "what is the nearest multiple of 10^-n, for some given n?"
Otherwise, it is a (very useful) abstraction. It isn't compression, it is a technique for avoiding expansion in cases where an expanded form is never needed.
((8^(5/4))^(((2/(0-(7+1)))^9)^(3-6))) = 2.718281848685499 ~ e +/- 2.0226453845140213e-08 That was fun. Although I'm having trouble confirming the answer... - Also I'm meant to be packing. http://play.golang.org/p/G_Y5SblSuv for some brute force eval :) Edit: This could be a nice demonstration for a genetic algorithm: A clearly defined fitness function yet an unknown (unknowable?) goal, and a distinct representation o…
I have one of those, a symbolic regressor (not genetic) lying around in a broken state. The last working version gave: short: 2981^ (1/8) less short: (2574 + 4903 ^ (1/4))/950 I used: http://apod.nasa.gov/htmltest/gifcity/e.1mil Perhaps I am misunderstanding your output but it is only correct up on till: 2.7182818
Digit concatenation was not allowed in the original challenge. If digit concatenation is allowed, then I believe that the best known is:
(1+9^(-4^(7x6))^(3^(2^85))
which gives e to 18457734525360901453873570 decimal digits.
Very neat: naive attempts to memorize Pi with rational-number shortcuts (i.e., fractions with integers in the nominator and denominator, such as 22/7 and 355/113) seem pointless, because getting more decimal digits of Pi right requires that one memorize a correspondingly larger number of digits in the numerator and/or denominator, defeating the purpose of these native attempts. -- PS. The author is offering a prize t…
I might be different, but 355/113 is very easy to remember and is not 7 unique segments of information. I just think "double the odds" 113355 We know we want a fraction, not a single number, so split down the middle: 113/355 And we know pi won't be less than 1, so flip it: 355/113. Knowing that the digits sequences are doubled lets you do some cheap, mental run length encoding. In a case where you need a hand calcula…
Required information for your approach:
Repeat the digits
Use odd digits
Use increasing sequence
Use three digits
Split the result in half and divide
Pi is greater than 1
But since humans have associative memory, these are easier to learn than a seemingly arbitrary digits sequence.
Ideally you add 14%. Why do you say 5% (or nothing) is better than 10%?
He's taking the % of the wrong number: the number you get after multiplying by three, not the original. I do what you do: 3, +10% + 5% (which is easy after getting the 10%).
It is easier to add 5% first, then triple, skipping the middle step.
I stumbled across this interesting paper about the subject at some point: http://cogprints.org/3667/1/APRI-PH-2004-12b.pdf I know a lot of you will gloss over this, but I think you will be surprised at how interesting it is if you read it. Basically, it tries to see if mathematical equations have meaning by determining how well they "compress" the results. For instance, the author says the equation eπ−π=19.9990999...…
How do you define e succinctly enough to make that representation efficient?
I don't like how he's measuring accuracy, here. Something that produces (3.149) is treated as closer than (3.139). 22/7 looks marginally better, if we compare actual error. It's the same number of characters as 3.14, but about 20% less error. 355/113, meanwhile, is not only better than 3.14159 (same number of characters) but actually even better than 3.141592 (about 60% less error). It's also easier to remember, due…
Yes, Jon's metric for measuring the value of an approximation is wrong and so is his conclusion.
Why is the conclusion wrong? It still seems like the trend should be the same.
I think blog.wolfram.com is probably the best company blog I've seen, from a marketing perspective. A large number of the entries are basically of the form "Here is an interesting problem, and here's how I solved it with Wolfram products". They generally let the problem have the spotlight rather than focus on the Wolfram products, so it doesn't feel like you are getting pitched. Here's a related problem, but for e: u…
((8^(5/4))^(((2/(0-(7+1)))^9)^(3-6))) = 2.718281848685499 ~ e +/- 2.0226453845140213e-08 That was fun. Although I'm having trouble confirming the answer... - Also I'm meant to be packing. http://play.golang.org/p/G_Y5SblSuv for some brute force eval :) Edit: This could be a nice demonstration for a genetic algorithm: A clearly defined fitness function yet an unknown (unknowable?) goal, and a distinct representation o…
This is expected behavior. The best fractions are tied to the http://en.wikipedia.org/wiki/Continued_fraction representation of pi. The ones which have a chance of giving you several "free" digits are going to be tied to large terms in the representation. Glancing at http://oeis.org/A001203/b001203.txt gives you a sense that large terms are kind of rare. http://mathworld.wolfram.com/Gauss-KuzminDistribution.html quan…
This also makes sense from data compression theory. If the digits of an irrational / transcendental number share some of the properties of a random string, then you shouldn't be able to compress it. And finding a fractional representation with fewer total digits is a form of data compression.
I dunno, I think sum_{i=0}^{\infty} (-1)^i 4/(2i+1) is a pretty good compression for an infinite string.
Yes, Jon's metric for measuring the value of an approximation is wrong and so is his conclusion.
Why is the conclusion wrong? It still seems like the trend should be the same.
The conclusion is that they are useless, but this is predicated on a notion that there is some use to which they can be put. The "trend" therefore is not what matters - who cares if I can't find a hugely accurate rational form past what I couldn't remember anyway? What matters is those few near the start. He dismisses 22/7 as being no better than 3.14 because it only agrees in the same number of digits; it is in fact more accurate, and easier to use for some operations. 355/113 is not only easier to remember but also substantially more accurate than the decimal approximation with the same number of digits. Rarely will you need more accuracy than that in your head (or on your napkin). If you need more in your program, M_PI is also 4 characters...
Setting MaxExtraPrecision to "to use as much automation as it needs to resolve numerical values" looks very interesting. It seems like it is being lazy, because the amount of precision needed isn't known until after the result is used (in this case the function that counts number of correct digits).