I am posting here just to document a rather unimportant bug and suggest a documentation change. The bug: Precision to the right of the decimal place does not go out to a maximum of 10,000 places, but effectively out to only 4,089 (? - weird number) places. Following is a very simple batch file that can be used to verify this: @Echo Off SetLocal Set Precision=4080 Do Forever Set Var=%@Eval[1/6=1.%Precision] @Echo Precision: %Precision Set Precision=%@Inc[%Precision] EndDo EndLocal Quit 0 I would suggest as a simple workaround that you just change the documentation to show exactly what precision is actually available under exactly what circumstances (I've noticed that one can go higher than this in some relatively unimportant cases), rather than changing the program source code (although you can certainly do that if you want! ; > ).

This doesn't have anything to do with precision -- you're limited to 4095 chars for a single argument in TCC. So the parser is complaining not about the precision but rather about the length of the variable argument being passed to SET. Rex Conn JP Software

Rex, that’s a very simple and completely understandable limitation. However, for me this just reinforces the idea that this limitation should be documented (as a reminder) where you state “The maximum size is 20,000 digits (10,000 digits to the left of the decimal point and 10,000 decimal places).”, because it makes that statement much less meaningful! Specifically, if I understand you correctly (and I believe I do), this means that you can’t effectively feed the output of one very-many-significant-digit calculation into a subsequent calculation because there is no place to hold the result of the first calculation to feed into the second calculation. And in how many circumstances would one have a calculation that creates that many significant digits without wanting to the results into a further calculation? (I know you can do such things as display the square root of two to 10,000 decimal places, but I don’t think that’s too useful. In my case, I was testing an iterative (not recursive, it approaches PI very quickly and asymptotically) algorithm to calculate PI to as many as I could generate decimal places, and I wanted to compare its output to very-many-significant-digit representations of PI that are freely available on the web to test the iterative algorithm's accuracy. Not too useful either, I’ll be the first to admit, but doing that kind of thing is kind of a low-level hobby for me.) - Dan

A batch interpreter is probably not the *best* tool for this kind of work ... :-) The 20K digit precision is real, though in most cases it's limited to the internal calculations and/or writing to the display or a file. Doing an extremely high precision calculation and then attempting to use that as an argument to other commands (internal or external) is unlikely to be generally useful, and certainly not worth the very high (2 - 4x) additional memory it would require for the interpreter to be able to handle arguments of that size. The maximum argument size is documented (in several places) in the help file. For v11, this limit has been increased from 4095 to 8191. Rex Conn JP Software

Rex, again my main point is that this limit should be (re-)stated in the documentation at the point where the 10,000-digits statement is made as a reminder (or you should make sure the "display" part is there everywhere you talk about the number of digits and probably in bold type). I have (happily) used Take Command/4NT for many years now (probably from pretty close to when it first came out for Windows NT), and I only generally completely read the "what's new" section when I pick up a new version, not the whole documentation file. And, since this has never been an issue for me in the past, remembering that it is "4095" is somewhat beyond my capabilities given that, if I've ever read it at all, it was probably many years ago (my memory's not that good!). And I would also guess that I'm not alone in this. As for the "not the best language" comment, I am aware of no other generally available computer language (or C++ class or library) that will do calculations to this kind of precision without a lot of work by the programmer! (Congratulations to you for your at least somewhat limited support in the matter. And I applaud the "to 8191" part!) At any rate, I promise I'll leave this topic alone after this as I've (more than ;)) said my piece on the matter... - Dan Mathews

Mathematica will do these calculations with practically no work by the programmer. It's not cheap but might be worth your while if you have much need of this feature. See this for general information http://www.wolfram.com/products/mathematica/index.html and this for specific information about how Mathematica handles precision http://reference.wolfram.com/mathematica/tutorial/ArbitraryPrecisionNumbers.html