Use of the arithmetical coprocessor

You don't have to explicitly code for them. Since the FPU is built in the compiler knows to cut code for the FPU. You access them every time you code *, /, ^, and most trig functions.

M

I don't think the compiler does it by default, because my results are not accurate enough.

Sorry, I reopen the question.

Change your data type if you're not getting enough accuracy. What type of accuracy are you looking for? CPU should be giving you at least 16 digits on transendentals.

M

I need the highest accuracy possible. And I already use a double.

What are you computing that you need more than what double's can give? How did you determine that there wasn't "enough" accuracy?

"Double (double-precision floating-point) variables are stored as IEEE 64-bit (8-byte) floating-point numbers ranging in value from -1.79769313486232E308 to -4.94065645841247E-324 for negative values and from 4.94065645841247E-324 to 1.79769313486232E308 for positive values. The type-declaration character for Double is the number sign (#)."

The Mathco functions aren't going to give you anything tighter than this.

M

The problem is not the double var, it's the precision of the computation (I have a function that does thousands of calculations with very small numbers). So I need to use the coprocessor.

Again, you *ARE* using the co-processor! It's *AUTOMATIC*. You CAN'T TURN IT OFF. Every time you execute a math instruction the MATHCO DOES IT!

M

The problem is not the double var, it's the precision of the computation (I have a function that does thousands of calculations with very small numbers). So I need to use the coprocessor.

The precision of the computation is limited by the precision of the *VARIABLES*. Again *YOU ARE ALREADY USING THE MATH COPROCESSOR*. IT IS PART OF THE CPU CHIP. There is no additional precision available!

M

so the question is a moving target.
Now, it is:

where can I find a good abritrary precision number package for VB.
Thank you

Ahhh! Now *THAT* is a different question! To that, I don't know. What kind of data are you crunching? Sometimes if you change the order of operations you can keep things normalized.

You state that you're doing thousands of calculations with small numbers. Why not scale the numbers *up* prior to doing your operations and then divvy down as required. You're not going to get past 16 significant digits no matter what.

What kind of math are you doing? There are programs like MathCAD and such that are designed to do higher precision work.

M