Hi, I am new to this forum and I hope I am posting the thread in the right forum.
I have a huge C program running perfectly fine in 64 bit UNIX systems (runs for 5000 iterations). I want the same results while running in WINDOWS.
My current systems supports Windows 7 Professional 32 bit version. I made some changes to my makefile and ran it from command line in WINDOWS. Though the code runs, the results seem weird. I get 1.#IND (Indeterminate) and very huge floating point results in WINDOWS system. I use "double" in UNIX but the same datatype creates some problem in WINDOWS.
I would like to know if the problem is using 32 bit version and so should I shift to 64 bit version of WINDOWS to have the same compatibility?
What changes should I make to the datatypes if at all?
You can't just blindly substitute things and hope that'll fix it, if anything that'll make it worse -- these things matter. You need to track down where the problem is originating, which may have nothing to do with the calculations themselves but the things that feed values into them. It may be assuming certain things to be certain sizes when the variable types are actually totally different sizes on 32-bit machines.
Try compiling with -Wall and investigating all warnings, especially ones about truncated values.
Absolutely. Thanks for the reply. I also have one specific question if I should try out things in 64 bit Windows.
Do you think migrating from 64 bit Unix machine to 32 bit Windows could create problems?
It's not because it's 64-bit UNIX and 32-bit Windows. It's because certain things may have depended on certain types being certain sizes, and when you change architecture, they may change. Similar problems can be had moving from 32-bit windows to 64-bit UNIX, 32-bit UNIX to 64-bit Windows, 32-bit UNIX to 64-bit UNIX, 64-bit UNIX to 32-bit UNIX, 32-bit Windows to 64-bit Windows, and 64-bit Windows to 32-bit Windows.
It's not a Windows vs UNIX thing, it's from programmers that were either sloppy or didn't know better.
A 64-bit Windows environment is still radically different from most 64-bit UNIX(lp64?) environments, presumably because Microsoft just had to be different :wall: but to track down the problems, track them down, don't just blindly mess around with it.
I figured out the exact line of my huge code, as to where the NaN is generated. It appears to be QNaN and is propagating throughout the code. On performing a pointer arithmetic on that line, for example, "x = x + (yz)" where x, y and z are generated as 0 in a particular iteration. And x = 0 + (00) gives me a NaN. From the searches I performed on the web, there is nothing which says 00 gives NaN and it cannot be, obviously. One possibility is infinity0 gives NaN but when I printed 'y' and 'z', they are indeed 0.
Also, I did the same print's in my UNIX machine, and 0 + (0*0) gives 0.
Any suggestions over this? Does this imply there is any BUG in the code?
NAN can be generated by 0/0, but can also be generated when it tries to use a floating-point value that's actually bonkers and invalid. It's also generated by inf*0 as you suspected.
Post the actual code please. I suspect there's more to it; ordinary calculations don't just go bonkers on ordinary numbers for no reason.
Unfortunately I cannot post the code as its too huge and also for few privacy reasons.
I was able to rectify the NAN errors finally!!!.. Since the code was extremely huge, I had
some pain in locating the exact spot where the NAN was generated (It was QNAN and was propagating throughout the code).
Double datatype Addition and Multiplication were causing the errors and I typecasting the individual operands and the errors were gone!!
I have to try and do this for the rest of my code. But I am not sure why and how exactly
these errors are prevented by typecasting. Your views on this? (This code is very old,
written around 1990's for UNIX based systems)