(08-18-2022, 09:53 AM)Jack Wrote: it works ok as far as I tested, only that limit&& has no effect but loops&& does
Correct. limit&& is not employed here, but is used in other string math sub-routines. These two variables are similar in function, but since square root processes blocks of numbers depending on odd or even digits, I didn't feel comfortable in a limit&& * 2 loop exit for this workup. What I will probably end up with is a loop that exits when the decimal places reach the limit&& length, and then do away with the loops&& variable.
My biggest concern is speed. This routine works great on decimal place of 16 or less, fair at 32 or less, and is slow at lengths of 50+. The division string math takes the longest to process, especially with very large numbers divided by very large numbers, like in the higher loop pi calculations. My guess is professionally made calculator routines have special algorithms that don't rely on long division. So while figuring out how to build an algorithm with the classic math models is fun, it isn't necessarily practical for use in say a 500-digit precision calculator program where the user might have to wait a few minutes to get the answer. Ironic that string math can be used to take precision to infinity, provided you have eternity to wait for the answer!
Pete
Edit: The good news about why to use string math over qb64 SQR is see in accuracy tests like finding SQR(78)...
8.831760866327848 (QB64 is 848 while string math, which is correct as tested on precision online calculators, is 846. This is more than a rounding situation.)
8.8317608663278468547640427269592539641746394809314