| Bytes | Lang | Time | Link |
|---|---|---|---|
| 063 | Python 3 | 250513T032103Z | Lucenapo |
| 1518 | APLNARS | 250403T194841Z | Rosario |
| 145 | Vyxal Ṫ | 220310T032427Z | emanresu |
| 056 | ES7 | 190322T134003Z | elipszil |
| 061 | RPL/2 | 140721T010048Z | Nacre |
| 200 | Maple | 140720T085956Z | Ilmari K |
| 006 | Mathematica | 140719T005042Z | Martin E |
| 073 | Ruby | 140719T001431Z | O-I |
| 066 | Python | 140718T233851Z | Dan Getz |
| 005 | Python | 140718T221130Z | xnor |
| 006 | CJam floating point calculation | 140718T215905Z | aditsu q |
| 554 | GNU BC | 140718T205735Z | Digital |
| 118 | CJam | 140718T185350Z | aditsu q |
| 003 | wxMaxima | 140718T205824Z | Kyle Kan |
| 005 | Haskell | 140718T205559Z | Zaq |
| 061 | Many repl languages | 140718T203054Z | xem |
| 063 | Kona | 140718T174147Z | Kyle Kan |
Python 3, 63 bytes, 80 digits
print(2.6,*b'U-\0j@- G0#0_E&&]c,>_s-7HU_%',sep='')
Using bytes to compress.
APL(NARS), 58 chars, 1518 digits
2e3⍕*(⍟2v)÷⍨+/{(⍵÷⍨¯1+⍎1⌽'v1z',⍕a)×-/÷⍳¯1+a←2×⍵}¨⍳⎕fpc←!7v
I had forgot -/ make alternate sum, so the before program was too much long...In 19' the result
2.685452001065306445309714835481795693820382293994462953051152345557218859537152002801141
174931847697995153465905288090082897677716410963051792533483259668381852315421332119
499626039328522044819409618068664166428930847788062036073705350103367263357728904990
427070272345170262523702354581068631850103237465580377502644252485286946823418994915
730661898720799413723550005793573669893395087902124464207528974145914769301844905060
179349938522547040420337798563983101570902223391000022077250965133246044443919169146
085968234821283246228292710126906974182348477675457348986254203392662351862086778136
650969658314699527183744805401219536666604964826989082754811525472117733031967594738
371939357810605923040189071134962467370684122179468107406089182766956671171668374059
047393688095345048999704717639045134323237715103219651503824698888324870935399469608
264781812056634946712578436664579740977848366204977774868276569708716319293851289931
419951861167379265462056350595138571376169712687229980532767327871051376395637190231
452890030581369109047996727575713850435650506415908209996234027790538341809851212785
294554151019232739727167968751562455868797717587182693659554502513041968186509380313
038584352986863635162073276997680665890872244479282008662254899139332970683561934192
252331025020641711415335032474299165077846638583879164060316419836995859840065464887
922606616087292452925007980469662533729845819556311521334306039715009162576850644063
025880484294953082596224282302705234019774963617850430615629230479700634337508384426
5 57
it would be 1518 digits until the space. it would calculate 7!/3.322=1517 digits show 2000
digits (that NARS it seems cut because are out the ⎕fpc precision).
The forumula used (the only that seems return in time) is
M=Sum_k=1..+oo (Zeta(2k)-1)(1-1/2+1/3-...+1/(2k-1))/k
K=exp(M/ln(2))
where K is the costant to return. The formula was find in
the link:
https://oeis.org/search?q=A247038&go=Search
It was need Zeta function written with the help builtin NARS has for calculate constants, and send data as a string.
{⍎1⌽'v1z',⍕⍵}
The series for the number M converge very well.
Because for calculate M it is need only Zeta(p) with p one even number,
if one not has the Zeta function, it is possible implement a Zeta function for input only
even numbers, and with them calculate using sum above the number K. There is one page in
the book "Analisi Matematica" I use that speak about the result of sum(1/k^s,k=1..oo)
with s even, for example sum(1/k^2,k=1..oo)=(π^2)/6, the recursive function Rh
is used for compute these sums...
⎕fpc←512
Rh←{⍵≤0:¯0.5v⋄m←⍵÷2v⋄+/{(÷!1+2×⍵)×(¯1*⍵+1)×((○1v)*2×⍵)×Rh 2×m-⍵}¨⍳m}
Zpari←{(÷1-÷2*⍵-1v)×-Rh⍵}
z←{(⍵<28)∧0=2∣⍵:Zpari ⍵⋄+/÷⍵*⍨⍳999}
Z←{⍎1⌽'v1z',⍕⍵}
Zpari(p) return Zeta(p) with p even. But for p>28 Zpari is very slow so i would prefer
the easy sum define Zeta trucated to 999 summands.... Using ⎕fpc←512 (before was ⎕fpc 128)
99⍕*(⍟2v)÷⍨+/{(⍵÷⍨¯1+z 2×⍵)×+/÷2{⍺ׯ1*⍵}/⍳2×⍵}¨⍳99v
2.6854520010653064453097148354817956938203822939944629530511523232680940881035510129
25597441398800247
99⍕*(⍟2v)÷⍨+/{(⍵÷⍨¯1+Z 2×⍵)×+/÷2{⍺ׯ1*⍵}/⍳2×⍵}¨⍳99v
2.6854520010653064453097148354817956938203822939944629530511523232680940881035510129
25597441398800247
but all this not fit well in 64 bytes...
Vyxal Ṫ, 145
‛2.»×¯⌐›‟₁⟇⟩ǐ₄cJḣsĖ↓r₍₀⁺¡₴¼ƒ∷⟨\ꜝṁ€∷₃‹ǒ Uẇḋv⁋∇I⌐ah6\⋎'*FǏ₈"ꜝṅė}₃≤
Uses a base-255 compressed string.
ES7, 56
alert`2.6854520010653064453097148354817956938203822939944629531`
RPL/2, 7 calculated digits, 61 bytes
'LN(FLOOR(1/X))/(X+1)/LN(2)' { 'X' 1e-9 1 } 1e-7 INT DROP EXP
returns 2.68545210493822 in one minute on my old (intel Core2) laptop.
No Zeta function in RPL/2 as far as I know, this is why I have used the integration (formula 15 from the Mathworld page). In principle the accuracy could be improved by replacing 1e-9 and 1e-7 by smaller number, but I was apparently lacking memory for that.
Of course resorting to the infinite product solve this point, it looks like
1 1 1e9 FOR I 1 1 I dup 2 + * / + I LN 2 LN / ^ * NEXT
and shall work as is on an HP RPL calc, but it turns out to be two order of magnitude slower (on the laptop, didn't tried on my HP !), and gives only 6 digits.
So the integration algorithm in RPL/2 does quite a good job actually.
Maple, 200+
The following Maple command computes Khinchin's constant to the requested precision (here, 200 digits):
evalf[200](exp(sum((-1)^k*(2-2^k)*ζ(1,k)/k,k=2..∞)/ln(2)));
This code should work if you copy-paste it into the Maple graphical interface. The ζ takes two bytes in UTF-8, and the ∞ three, for a total of 62 bytes.
Writing out the ASCII versions of those symbols, even with the trick of using min() instead of infinity, alas, brings the byte count up to 66:
evalf[200](exp(sum((-1)^k*(2-2^k)*Zeta(1,k)/k,k=2..min())/ln(2)));
The number of digits computed can be easily adjusted by changing the number in square brackets after evalf. On my rather old computer, 200 digits seems to finish in about half an hour; yours might be capable of more. Note that Maple rounds the result to the requested precision instead of truncating it, so the actual number of matching digits might be somewhat less.
This method of calculating the constant is based on formula (9) from the MathWorld page, cited there to Gosper (1996, pers. comm.):

This was the most efficient method that I managed to (barely) squeeze into 64 bytes or less.
Mathematica, 6
(Times@@Rest@ContinuedFraction[Pi,977])^(1.`9/976)
gives
2.68545843
and uses only 50 bytes, so there is some room for finding something better than Pi and using a larger continued fraction, but I'm not sure it'll get a lot better with a runtime of an hour. (Especially since finding a better combination would probably take several days if I'm just using brute force.)
(Of course, you were clever enough to disallow Khinchin~N~2000, where 2000 could be replaced with any number that gives you a result within an hour ;).)
Ruby - 73
Unfortunately, you can only convert up to base 36 using to_i in Ruby:
"2.#{"hmegxpkvliy1vaw4lb054ep8wsqwkz2yx9cm9jvc9yfd48j".to_i 36}"
which returns
"2.6854520010653064453097148354817956938203822939944629530511523455572188595"
Python, 64 66
print"2.%i"%int('anljsgqif7gwwwsrntcz7zv2obv6gv5us7fzfwjcaj',36)
Outputs:
2.68545200106530644530971483548179569382038229399446295305115234555
Python (5)
x=3**.1
p=1
for _ in[1]*10**6:p*=(x//1)**1e-6;x=1/(x%1)
print(p)
Output: 2.6854396408091694
(Output takes ~2 seconds.)
In solidarity with the other math solutions, I'll give an even worse-converging one that computes the geometric mean of the first million continued fraction coefficients of a single arbitrary-ish irrational number that's not of a type known to not work. Actually, I rigged that number by trying a few until I got one that coincided on an extra digit.
Funny thing: I froze my computer and had to do a hard shutdown after trying to shorten this code with the Python golf trick of replacing for _ in[1]*10**6:code with exec("code"*10**6).
CJam floating point calculation - 6
1e8{I{1.II2+*/)I2mL#*}1.?}fI
It fits in the original 32 bytes :)
Running with the java interpreter using java 8, it outputs this after about a minute on my laptop:
2.6854513126595827
The online interpreter would probably take too long.
GNU BC, 5 digits (54 byte program)
An attempt to actually calculate. GNU BC is horribly slow. This ran for 53 minutes on an Ubuntu 14.04 VM running on a mid-2012 MacBook Pro Retina. Strangely it runs faster in the VM than the OSX bare metal - presumably the GNU version is better optimised for this task than the BSD version.
for(k=r=1;r++<10^7;)k*=e(l(1/(r*(r+2))+1)*l(r)/l(2))
k
Output:
2.68544536902156538295
Note:
bc -l needs to be used for e() and l() functions (and setting scale = 20).
CJam - 118
2'."*;TeT?_aN{.i9B*ZEay
G`9~eW}nE=Lr-`B} )D>9m9"136b
Try it at http://cjam.aditsu.net/
Since stackexchange destroys some of the characters, here's a program that generates the program above; run it first, then run its output:
"2'.\""685452001065306445309714835481795693820382293994462953051152345557218859537152002801141174931847697995153465905288090 136b:c"\"136b"
Explanation:
2 pushes 2
'. pushes the dot
"…" is a string containing the rest of the digits in encoded form
128b converts the string to a number, treating the characters as digits in base 128 (via their ASCII code)
wxMaxima 3
An actually computed method!
bfloat(product((1+1/(n*(n+2)))^(log(n)/log(2)),n,1,10000));
After about 25 minutes, it returned
2.681499686663101b0
Now I understand why the Mathematica page stated that. I have 6 characters to play with, but I can't imagine adding 6 0's would (a) run in <60 min and (b) give me a more accurate solution.
Haskell, 5
Well, since nobody's posted a solution using actual maths, I decided I would, even though it's nowhere near as close as the other answers.
main=print$product[(1+1/r/(r+2))**2`logBase`r|r<-[1..99999999]]
This computes 2.6854453689859192, which is a whopping 5 characters of the constant. Wolfram was right when they said it is "difficult to calculate to high precision".
Many repl languages, 61
sorry, didn't find a better solution.
"2.685452001065306445309714835481795693820382293994462953051152"
The rules don't say that the correct number sequence can't be preceded by quotes, so I'm using this. By executing that in a JS console for example, you'll get the same string, including the quotes.