Unless someone has a better idea, I think it is quite reasonable to start with the series for arcsin(√z)/√z , apply Gauss’s relations to lower the indices and a linear transformation to obtain a relatively simple expression for the hypergeometric function in question in terms of arcsin and square roots, and substitute z = 1/2.
Of course, you can use a computer, and I take it one of Plouffe’s ideas is to use mechanical methods to find useful identities, as exemplified by the Inverse Symbolic Calculator mentioned before.
Better idea: If you’re using it for cryptography or randomness, don’t. It’s really hard to produce a good random number generator or cryptography scheme, and when amateurs try, they usually end up leaving gaping holes. Further, it’s not hard to find the random-number generators and cryptography schemes that have been created by the knowledgeable professionals and use those instead. Don’t try to reinvent the wheel.
I don’t understand this. Can’t you find the number in base 16 and then just convert to base 10?
To convert a number from base 16 to base 10, you need all of the digits.
People like to dabble in things that interest them, and professionals had to practice on something while they were still amateurs.
Mile Of Pi. Brady Haran and Matt Parker give some interesting facts on a mile long roll of paper with all the digits of Pi they could fit.
To expand on this a little, it’s because of the way that number bases place their digits - the digit places in a base 10 number are units, tens, hundreds, etc - in Hex, the’re units, sixteens, two-hundred-and-fifty-sixes, four-thousand-and-ninety-sixes, etc - so there’s no direct relationship between individual digits of a hex number and the individual digits of the same number, in decimal.
That’s not universal, though. It’s easy to switch between binary and hexadecimal–4 bits map exactly to one hex digit. No other digits are influenced.
That doesn’t work with decimal<=>hex, though, since the factors are different (no factor of 5 in hex). Add 1 to E8D4A50FFF and get E8D4A51000. Most of the digits are the same. In decimal, that changes 999999999999 to 1000000000000–all of the digits are different.
It only works in that direction though - you can’t pick out any 4 consecutive binary digits and expect them to map to a hex digit - they have to be digits 1,2,3,4 or 5,6,7,8 etc)
True, but 4 consecutive bits affect 2 hex digits at most. That’s unlike decimal-hex, where you can affect most of the digits in the converted string just by changing a single input digit (even if the number is trillions of digits long).
Agreed - that’s the common factor influence, I think - so (without testing), I expect the same sort of clean-one-way, fairly-clean-the-other relationship between bases 5 and 10
Just to show what some base 16 to base 10 conversions look like (from here):
1FFFFFFFFFFFF9 –> 9007199254740985
2FFFFFFFFFFFF9 -> 13510798882111481
2FFFFFF8FFFFF9 -> 13510798764670969
A single digit change can affect all the lower precision digits.
Yes, but 1/16 = 0.0625 exactly:
.1FFFFFFFFFFFF9 = .12499999999999990285548534529880271293222904205322…
.2FFFFFFFFFFFF9 = .18749999999999990285548534529880271293222904205322…
.2FFFFFF8FFFFF9 = .18749999837018539727839794295505271293222904205322…
So it is not changing single hexadecimal digits that is the problem, since that only affects a known finite number of decimal digits.