Just to be clear, does -dN mean that changes the length of $calc(1/3) similar to the $calc(math,N) I had suggested, or just changes the precision used inside the 30 digit display?
I intended the $calc(,N) to only be something that affects the display length and not the actual precision of of the actual calculation.
--
I didn't ask for 50 specifically, just that $pi had more digits than the output of 30
it seems reasonable that - in BF mode where fractions are returned with 30 digits, that the 20 digit fraction of $pi should be lengthened to have more digits than that.
... would have 100 digits.
And no I don't think the fraction needs to be that long, but should probably be at least slightly more than the 30 $calc can return.
I'm not caring so much about the length of fractions for tiny numbers in .bf results except for things like $log2(2) not giving me 1 -- as I am about the integer portion of big results. If everyone else wants to shorten $pi to be slightly longer than the default 30 digit precision, or shorten from the backwards-compatible length of 20 down to NASA's 15, I'm golden with that, as long as they accept the problems I mention below.
To further clarify my reasoning...
When $pi is used in a calculation, it seemed reasonable that any imprecise fraction should not be caused by $pi itself, such as where $calc($pi + 1/10^30) shouldn't have a lot of zeroes in the middle causing a 30-digit result that's smaller than the 30-digit value for true-PI. Because $calc was able to make use of longer inputs, that was probably the reasoning for $pi originally having 20 digits.
I was just using the same reasoning that $pi in .bf mode should have 'more than 30' as the number of digits it has. Whether that's adding +20 to the 30 digits or just +3 I have no opinion, other than the final used-digit should probably be rounded up if the next unused digit is 5-or-greater.
I can't think of any examples where $pi is used as the base for exponentiation, offhand, but that does apply to the 'e' constant for which I gave an absurdly long length. There is no 'anti-log' function from which to obtain 'e', and any such result would have rounding issues also. So I had made something like $e to return that constant so I could use $e in calculations where 'e' is commonly used as both a multiplier and the base for an exponent that's obviously more sensitive to precision than multiplication:
//var -s %e1.bf $calc(2.001^11), %e2.bf $calc(2.002^11), %m1.bf $calc(2.001*11), %m2.bf $calc(2.002*11)
* Set %e1.bf to 2059.292202282269582789281320220022
* Set %e2.bf to 2070.64097859678712285217803266253
* Set %m1.bf to 22.011
* Set %m2.bf to 22.022
... and obviously a shorter length of the $pi fraction would shorten the result of multiplications involving integers that aren't a power of 10.
If only 6 digits of precision is needed, the 355/113 approximation can get that for you:
//var -s %a.bf $calc(355/113 - $pi)
* Set %a.bf to 0.000000266764189062422312368932
I admire what NASA did in the 60's and 80's. They went to the moon using computers weaker than our phones, and sent probes out of the Solar System where there's no Geek Squad to come out to fix things that go wrong.
