1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Precision Limitation...

Discussion in 'Suggestions' started by mathewsdw@sbcglobal.net, Oct 18, 2009.

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

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,092
    Likes Received:
    85
    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
     
  3. 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

     
  4. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,092
    Likes Received:
    85
    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
     
  5. 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
     
  6. LMacNeill

    Joined:
    Dec 2, 2009
    Messages:
    3
    Likes Received:
    0
    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
     

Share This Page