On 3/21/2012 1:37 PM, Martin Brown wrote:
On 21/03/2012 16:53, Lynn McGuire wrote:
I have a large Win32 DLL (10 MB) that is called from
my user interface (written in C++) or from VBA in MS
Excel. In my user interface, the DLL runs in its
own space and calculates correctly. Under Excel VBA,
my DLL is having problems with double precision
accuracy. The following test passes in my user
interface but fails under my bad pentium test:

double precision chptst
double precision divtwo
double precision top
double precision bottom
data top / 4195835.0D0 /
data bottom / 3145727.0D0 /
DIVTWO = top / bottom
CHPTST = (DIVTWO * bottom) - top

In my user interface, the chptst result is zero.
Under Excel VBA, the chptst result is 0.2851266E-09.

I have tried resetting the math coprocessor in my
DLL with the following code but it is not working:

unsigned old87Status = 0;
unsigned new87ControlWord = 0;
unsigned new87ControlMask = 0;
unsigned new87result = 0;
old87Status = _status87 ();
if (old87Status != 0)
new87result = _control87 (new87ControlWord, new87ControlMask);

I think the problem is that your call to _control87(0,0) is a NOOP.

Untested but I think _control87( _PC_64+_RC_NEAR, _MCW_PC+_MCW_RC);

Ought to do the trick. Force 64 bit computation and nearest rounding.

It could also be the case that in a pure C/C++ environment the final pass of the optimising compiler is smart enough to notice that
your expression is identically zero at compile time.


I have verified this behavior in both Excel 2003
and 2010. Does anyone have any ideas here ?

Hope this helps. See the following for details

http://msdn.microsoft.com/en-us/libr...(v=VS.60).aspx

Bummer, neither of
_control87( _PC_64+_RC_NEAR, _MCW_PC+_MCW_RC);
_control87 (_PC_64, _MCW_PC);
did not help.

Something is really weird here.

Thanks,
Lynn