Xref: news2.mv.net comp.os.msdos.djgpp:7289 From: jhvogel AT me DOT umn DOT edu (Jeff Vogel) Newsgroups: comp.os.msdos.djgpp Subject: Re: math addition error? Date: 14 Aug 1996 15:23:19 -0500 Organization: me.umn.edu -- UMN Mechanical Engineering Lines: 48 Message-ID: References: NNTP-Posting-Host: ena.me.umn.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Eli Zaretskii writes: >On 12 Aug 1996, Jeff Vogel wrote: >> #include >> main() >> { >> double x=3.6053320875, y=3.6053320870; >> printf( "%lf\n", x-y ); > ^^^ >What happens if you put "%f" there? You shouldn't have to use "%lf" in >printf calls; it is only required for scanf. >If that doesn't help, seems like an emulator problem to me, since it >works on a Pentium (that has a built-in FPU). I have now reproduced the error on the Pentium, by running in native DOS (it doesn't happen on the Pentium in a DOS box), and with go32 set as: set GO#@=emu c:/djgpp/bin/emu387.exe (path to my emulator - this is ver 1.12 of DJGPP). I have upgraded my machine do djgpp v2, and found no change in the behavior. I have verified that I am using the new go32-v2, emu387.dxe, and a new cwsdpmi (I think that is the name) is on the path, though not explicitly loaded. I have also confirmed that the error is not too hard to duplicate if the two numbers are between 2.0-4.0, but the error seems to never appear outside of tha range. Let x be a number between 2 and 4, and y=x+5.e-10. Then y-x=5.e-10 about half of the time, and y-x=-3.9999999995 the other (slightly less than) half of the time. Further, it is interesting that if x=2.0, and you then add a number to x that is between about 4.65e-10 and 9.33e-10, the answer appears to be still exactly 2.0; but subtracting x from this new number gives: (x+dx)-x = dx-4.0. However, if dx is outiside of that range (larger or smaller) no error occurs. This is probably more detail than anyone wants. However, it is very important t me that I find out how to fix it. I understand that there may be limited interest in debugging stuff that depends largely on not having a co-processor, but if I can't fix it, I will have to abandon djgpp. If a solution requires working on emulator sources, I would be willing to try to help. -- Jeff Vogel jhvogel AT me DOT umn DOT edu