Extended precision library

[Valentin Albillo]

.
Hi again, G.E.;

(05-25-2019 10:30 AM)G.E. Wrote:  Valentin, first of all I really appreciate all your work (SSMC, "Long Live...", lots...), always interesting and enlightening to read all your ideas.

Thank you very much for your interest, much appreciated.

Quote:1. Fixed format is nice but there is always a case when you "need" more digits. Also due to precision loss on higher functions, it is simpler to raise the number of digits rather than fix the damn algorithm.

Of course, you're right. As I said, this was written 17 years ago and was intended to help HP-41C owners to implement sometihng in order to have a try at my challenge.

I'd use a different approach now, and even did at the time. For instance, I created a Windows app which implemented a fully programmable RPN calculator with lots of extras, such as the XYZTL stack being visible at all times, 999 registers, 999 program steps, 999 labels, full alphanumerics, full mathematical functions, constants, the works, and of interest for this discussion, multiprecision up to 256 decimal digits, which was all I cared for at the time.

It was nice to be able to instantly compute Gamma of a 256-decimals argument to 256 correct digits, finding roots of equations to 50, 100, 200 or 256 digits (the precision was selectable), all in perfect, compatible RPN with many extensions (full stack and register manipulations, for instance).

I wrote the user interface in VB, for simplicity, which called a DLL I wrote in Turbo Pascal 5.0, implementing all the multiprecision functionalities at blinding speed thanks to optimized, compiled code. My DLL had full arithmetic, powers, trigs, exponential, logarithm, Gamma, Factorials, Lambert W and common multiprecision constants defined up to 256 digits (Pi, e, Phi, EulerGamma, etc) for instant recall.

I never released it, it was written before I had decent Internet access, must be there somewhere.

Quote:9. Yes, absolutely right, the division algorithm is an horrible kludge ! I tried to find an efficient way, and will try the Newton method you show.

Please do, it's what I used for my TP DLL library and it did well for me.

Quote:11. The precision of the constant PI must be adjustable, the right way I think is as 4*atan(1).

But there's no use in having to recompute it each time or even once at the beginning. Simply have it inside the initialization part of your library, defined as an explicit constant (say 1024 digits) which you'll simply trim to the specified precision (say 200 digits) without having to call the arctan function. If the result is fixed and known, what's the use in computing it ? You already know what result the Atan will give ! Don't use time and memory to compute a known constant, simply define and use the constant.

Quote:Can't seem to find the SSMC#4 at the moment, will see.

I see that pier4r (thanks, Pier!) already pointed you to two versions of it. You'll find the Guidelines there and several examples which you can use for testing purposes.

Have a nice weekend.
V.
.