Done Precision Limitation...

[mathewsdw@sbcglobal.net]

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! ; > ).

 

[rconn]

> I am posting here just to document an 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:
>

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

 

[mathewsdw@sbcglobal.net]

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

 

[rconn]

> 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.)

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

 

[mathewsdw@sbcglobal.net]

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

 

[LMacNeill]

Rex,
[...]
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!
[...]
- 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