Need Algorithm Help From Some Math Wiz's - ARCTANGENT

[Clay Clear]

For quite a while I have been coding a huge integer library of procedures that have the capability of using fractions and can use negative numbers. This all started when Mr. Eddy Van Esch kindly posted in the Source Code Forum a way to use his HIME library to do such things. And, no, I will not release my code or compiled binaries for other programmers to use, unless Eddy says I can. I think he has done outstanding work with his libraries and I will not take away from his revenue. However, I have coded a calculator program that I use instead of the Windows calculator. Unlike the calc.exe program, my program allows the user to set the fractional digits precision to whatever he wants ('course, if he sets it to something like 16384, he can go to a movie, walk the dog, etc. while the number crunching is taking place <grin>). My version of calc.exe has features that the Windows does not have, and it lacks some that it does have. All-in-all, I think my version is much more robust than the Windows version. I am quite willing to release my calculator program as Freeware, if anybody wants it. Oh, yes, my version remembers the user's settings from the last session. But, again, I will not release any INC files or anything so other programmers can use the API in my DLL's. This is out of respect for Eddy.

My problem with ARCTANGENT, and it also exist for my other HiFP_* procedures that use infinite series to calculate the numbers, happens when the input value has a value of 0.999 or higher. Because of the way the infinite series are calculated, and because my code uses "high level" functions in Eddy's HIME library, and because they use OLE strings, when the values of 0.999 or higher are passed to these procedures, the code CRAWLSSSS.

In the example of ARCTANGENT, the lines below are pseudo-code to show how my code performs the Taylor series algorithm (PB scalar variables are used to illustrate the point - in the real code, OLE strings areused):

e1##  = 0.999## 'input TANGENT value, derived earlier from my HiFP_Tangent function

exp& = 3

result## = e1##

L& = -1

do
    e2## = (e1^exp) / exp
    if e2 = 0## or e2 > 10000## then exit do 'test for too high of a value is necessary because sometimes, well, that's what the result is - indicates that the code can't go any further in the loop
    result = result + (e2 * L)
    L = L * -1
    exp = exp + 2
loop

The cause of the problem is obvious - when you multiply any number by 0.999 or higher, the number hardly decreases in value. That means it takes an ungodly number of DO / LOOP iterations before e2 = 0 or is too high.

So, my question: can one of you math wiz's provide a change to my algorithm that would greatly speed up the calculations when e1 = 0.999 or higher? Oh, yes, my code first reduces the input number to a value between 0 and 1, as required by the Taylor series.

Any help received would be very much appreciated.

[Clay Clear]

Disregard, I solved my own problem. I finally realized something about TANGENT's, and it paved the way for a simple fix that works.

[Michael Mattias]

Something wrong with the intrinsic ATN()function, which returns an extended precision value?

[Clay Clear]

You didn't truly read what I said, Michael. I am creating my own arbitray precision huge integer code. The 18 digits of precision in a PB EXT value would fall far short if I wanted my math to use, say 128, digits of precision. Because there are no scalars in PB/Windows/CPU's that can do that, I am forced to use OLE strings and therefore have to write my own math procedures.

[Michael Mattias]

I did not infer creation of an arbitrary precision reusable function from your post.

ATN() was a thought, since I have seen here questions where the answer was simply, "use the intrinsic function."