Is it possible to set the precision for the subtraction operator?

[tonh]

Hi everyone.
I have two complex double precision numbers that are suppose to be equals. Each one is the result of different sets of equations.
When I subtract one from the other the result is not zero.
I think this can be explain by the fact that they are quite large numbers (about 1E+101), causing the subtraction operator to drop (or round, or do something not legit with) the two numbers. Moreover, if I repeat the subtraction with different large numbers, I obtain about half of the time the expected result (zero) and the rest of the time I obtain a value between 1E+84 and 1E+86.
What I would like is to get the result right everytime, so I thought about setting a precision to the subtraction operator. Is that possible? If it is, how am I suppose to do that and if not, what's wrong with the subtraction operator?

Thanks
tonh

[GerdW]

Hi tonh,

there's nothing wrong with the subtract operator, it's the way you use it

Floats cannot take arbitrary precision! That's a fact and you have to cope with it! There are great articles on wikipedia that explain this behaviour very well!

What about rounding your calculation result? DBLs are "precise" to about ~1e-17, so when calculating with numbers in the range of 1e101 you should round to 1e85 to cancel out calculation errors due to rounding...
And more important: NEVER compare floats for equality!!!


Message Edited by GerdW on 07-21-2008 10:09 PM

[tonh]

Hi GerdW
Thank you for your answer. That helped me to figure out my problem.
tonh

[tonh]

Another question arises, what do I do if I want to subtract those two big numbers knowing that the difference between them is less than what the default precision could give me? For example: 1E+101 -(1E+101-1E+17) does not equal to zero which is what a normal computation would give me. Is there any way to obtain the good answer?

tonh

[johnsold]

You will need to be very careful about the order of operations. If you can subtract the 1E101 parts first and add the 1E17 part later you would get the correct answer.

However, if you cannot decompose the problem into pieces which allow this type of calculation without overflow/underflow, then you need to do something else.

One possibility is to develop your own arbitrary precision arithmetic routines. If you represent your 101 digit number as an array of 101 integers, then do digit by digit arithmetic, you can keep the precision you need. It will be much slower than working with standard numeric representations and you cannot use the built-in math functions. If you need to do Fourier transforms or cosine(x), you will need to write your own routines.

Lynn

[tonh]

Thanks for the info...

[tonh]

Is there any available librairies that someone created for the usual operators and functions (+,-,*,/,exp,sin,cos...etc) which would take as input the number of digits you want to keep in the operations/functions?

tonh

[johnsold]

Search for the Prime Factors Coding Challenge. Some ways of handling many digits were used in that. No trig functions, though.

Lynn

[Kevin_Price]

Thought 1: 1e+101 is pretty big!  Do you *need* all your calcs to carry such a big exponent?  For example, can you run all the calcs on values that have been scaled by 1e-100, then at the end of all the calcs scale back by 1e+100? 

Thought 2: If you just need to compare for approximate equality, you could divide the difference by the larger of the two values being subtracted.  If you subtract two virtually equal 1e+101 values, you may get a difference in the order of 1e+85.   The division will give you a ratio of ~1e-16.  Ratios in that realm will mean that the two original values are about as nearly equal as the floating point representation can express.   This type of method scales pretty well to work with both very small and very large floating point numbers.

Thought 3: If the inputs to your calcs are in the order of 1e+85 or less, you may really have your work cut out for you.  You'll need to think carefully about floating point representation error at each step of the calculations to know where you can round, truncate, approximate, etc.  There may be places where rounding will be *necessary* and other places where it is *disastrous*.

To summarize: you need to apply some of your error knowledge to your code.  The 1e+101 calculated values probably don't have more than 6-8 *significant* digits of accuracy, right?  (Most numbers come from some kind of measurement, or a rounded-off value for a scientific constant, etc.)  You'll need to analyze your values and calcs to understand about how many digits of the 1e+101 numbers are truly *significant*.  Then your code will need to treat values which differ by less than that amount as if they are truly equal.

-Kevin P.

[tonh]

Here is something I found on the internet about big numbers arithmetics
http://gmplib.org/
From what I can read (and test throught the "try it" section) it works perfectly. The only problem is I have NO idea of what this thing is and how to link labview to that.
Anyone got ideas?
tonh
Ps thank you for the propositions Kevin, they are all good ideas, thought I cant use them (mainly because the problematic operations are done on numbers that go from very little ones to really big ones)