VC code !!

  • Thread starter Thread starter Andry
  • Start date Start date
A

Andry

Hi
I have an issue with the VC++ code. I have a code in VBA that I am running
in VC++.
But there is a difference in the result of the two.
Following are the details of problem:

The result value, "sum", of the following expression does not tally with

that from the VBA code in the LU_Decompose function.

sum = sum-(a[k]*a[k][j])

variables:

sum, a[][] are declared as "double"

Example:

Actual values from VC++

sum = 20021.91546286768100000000 - (0.012240632695608 * 1635722.6000577677)

= -0.36407634442366543

Actual value from VB

sum = -0.364076344415514



The difference in the above two values of "sum" propagates into the

resultant value and hence the accuracy problem is observed.

Please suggest.
 
Your are using doubles, which are floating point values. Floating point
variables are not exact, so this diference.
 
Andry said:
Hi
I have an issue with the VC++ code. I have a code in VBA that I am running
in VC++.
But there is a difference in the result of the two.
Following are the details of problem:

The result value, "sum", of the following expression does not tally with

that from the VBA code in the LU_Decompose function.

sum = sum-(a[k]*a[k][j])

variables:

sum, a[][] are declared as "double"

Example:

Actual values from VC++

sum = 20021.91546286768100000000 - (0.012240632695608 * 1635722.6000577677)

= -0.36407634442366543

Actual value from VB

sum = -0.364076344415514
Click to expand...

The difference in the above two values of "sum" propagates into the
resultant value and hence the accuracy problem is observed.
Click to expand...

Floating-point calculations always have an accuracy imprecisiom, you
must live with it.
Now for your particluar problem, Intel processors have different
calculation and rounding modes for doubles, due to the fact that they
internally uses 80 bits but the doubles are stored in memory with 64
bits. I suspect your VC vode and VBA don't use the same rounding mode.

Arnaud
MVP - VC
 
Andry said:
Hi
I have an issue with the VC++ code. I have a code in VBA that I am running
in VC++.
But there is a difference in the result of the two.
Following are the details of problem:

The result value, "sum", of the following expression does not tally with
that from the VBA code in the LU_Decompose function.

sum = sum-(a[k]*a[k][j])
variables:
sum, a[][] are declared as "double"
Example:
Actual values from VC++
sum = 20021.91546286768100000000 - (0.012240632695608 * 1635722.6000577677)
Click to expand...


You need to do a bit of reading on floating point computation, especially
on subtracting two numbers that are very close to each other.

Doubles can only keep 17 digits of precision. After the multiplication,
the second value is 20022.279539212039, plus some garbage. After the
subtraction, you lose 5 digits of your precision, so the resulting value
will only have 12 valid digits. The two values you got agree to 12 digits.
 
please also be sure, that that u remind about following:
vb indices are normally one based and c/c++ are zero
based!

sum = sum-(a[k]*a[k][j])
^--^----^--^--- attention

do they use really the same values in both programs?
 
Hi
Thanks to you all for the help.
But i wanna know is there any workaround to overcome this difference in
values?
My VB app shows one value as .787888
and VC app shows it as .78789
So the VB is more accurate here. I want this result through me VC app.
What should I do? Please suggest.
Thanks!


Tim Roberts said:
Andry said:
Hi
I have an issue with the VC++ code. I have a code in VBA that I am running
in VC++.
But there is a difference in the result of the two.
Following are the details of problem:

The result value, "sum", of the following expression does not tally with
that from the VBA code in the LU_Decompose function.

sum = sum-(a[k]*a[k][j])
variables:
sum, a[][] are declared as "double"
Example:
Actual values from VC++
sum = 20021.91546286768100000000 - (0.012240632695608 *
Click to expand...
1635722.6000577677)

You need to do a bit of reading on floating point computation, especially
on subtracting two numbers that are very close to each other.

Doubles can only keep 17 digits of precision. After the multiplication,
the second value is 20022.279539212039, plus some garbage. After the
subtraction, you lose 5 digits of your precision, so the resulting value
will only have 12 valid digits. The two values you got agree to 12 digits.
Click to expand...
 
Andry said:
Hi
Thanks to you all for the help.
But i wanna know is there any workaround to overcome this difference in
values?
My VB app shows one value as .787888
and VC app shows it as .78789
So the VB is more accurate here. I want this result through me VC app.
What should I do? Please suggest.
Thanks!
Click to expand...

The number of digits you "show" is a rouding and display formatting
issue that you can control with binary-to-text conversion code. As with
math operations, binary-to-text conversion for floats is not exact and
can not be exact. So it is also up to you to avoid displaying
meaningless digits. When you say the VB is more "accurate" you are
showing ignorance of the fundamental issues. The extra digits are
"precision" not "accuracy". They may be garbage, depending on how they
were developed. I.e., this is not an easy issue, it is a fundamental
limitation of float math and binary to decimal conversion. For deeper
study search google for "What every computer scientist should know about
floating point."
 
Andry said:
Hi
Thanks to you all for the help.
But i wanna know is there any workaround to overcome this difference in
values?
My VB app shows one value as .787888
and VC app shows it as .78789
So the VB is more accurate here.
Click to expand...

What makes you think that? Just because one shows more digits does NOT
imply that the answer is more "accurate". In fact, losses due to rounding
and loss of precision in subtraction might mean that only 5 digits are
guaranteed valid. Showing you additional digits is just sponsoring
confusion.

Floating point arithmetic is not the exact science many people believe it
is.
 
Back
Top