(08-15-2022, 04:22 PM)Pete Wrote: Nice! Thanks for speed testing.
I developed my string math routine as a way to never get caught in "computer" binary math errors. VAL() even fails when strings get too big, so I took that into account, too. I find this to be a great system for big number accounting, probably useful for chemistry molar calculations, but too slow for the kinds of massive numbers produced, as when calculating pi.
BTW: The pi algorithm I used is based on Leibniz's formula. There are other methods, but I'm not sure which is the fastest or most accurate. What's funny is the stone age method of putting a thread around a cylinder of known diameter is faster at getting to 3.14. I imagine at 15min to get that with my routine using Leibniz calculations, it would take several hours to get anything better than 3.14159.
Pete
I hear you on the computer binary math errors, wouldn't it make sense to extend QB64 with native types that hold the bigger numbers and do the calculations without error, natively, at machine code speed? Or if we already have big enough types, to fix whatever under the hood causes these calculation errors?
Because the string math is a good exercise, but it sounds like a band-aid for a bigger problem that needs to be fixed for real. Does that make sense?