Results of 32-bits Stata should be the same as the results of 64-bits Stata, however, that is not the case

[LydiaSmit]

I copied 12 months of data from Stata 32-bit (on computer 1) to Excel. After that, I annualized the data in Excel.
Computer 1 'temporarily' couldn't handle my whole .do-file and datasets, so I decided to run my .do-file on the whole dataset on 'computer 2' which has 64-bit Stata.

The results of 32-bits Stata should be the same as the results of 64-bits Stata, however, that is not the case.
The 32-bits Stata eventually gave me the results I want, however, I want to be able to work with Stata 64-bits in the coming days.

Could someone tell me the reason why Stata 64-bits gives different results and how I can solve this issue.

[Sergiy Radyakin]

....
I decided to run my .do-file on the whole dataset on 'computer 2' which has 64-bit Stata.
...
Could someone tell me the reason why Stata 64-bits gives different results and how I can solve this issue.

So, what's in your .do-file then? Which commands did you use? in what sequence? How are the results different? (different numbers? different graphs? different error messages?). While the results are different is there any indication which results are correct? Do you get the difference for other data?

In general 32- and 64-bit versions are two different programs using different commands. But they are stemming from the same source code, so the hope is that they will produce the same results (which is not necessarily true: the 32-bit compilers might have bugs different from 64-bit compilers). StataCorp also does a lot of testing to make sure this is indeed happening. Precision will almost surely be different. If your results differ in 15th digit after comma - forget about it. Otherwise elaborate, please.

From the background, the best guess would be that Stata behaves perfectly fine, but you are using some user-written ado files, and the first computer has version X installed while the second is having version Y installed. Make sure the code the computers are running is exactly the same (take two logs and dif them).

The 32-bits Stata eventually gave me the results I want

If this is a clinical trial, don't publish the results just yet, until the source of discrepancies is determined. Even if you found a version of the results that you wanted. It's good that you asked.


Best, Sergiy Radyakin

[Steve Samuels]

Did the two computers operate on (direct copies of) the same .dta files?

[Svend Juul]

LydiaSmit wrote:
I annualized the data in Excel.

What does that mean?

[LydiaSmit]

What does that mean?

Converting monthly data into year/annual data. The best way of doing that is probably by calculating the mean of the 12 monthly data and then (1+mean)^12-1. If that isn't the correct way, it would be nice if someone corrects me.

The different versions of Stata produce different numbers but this also seems to be the result of some commands in my .do-file (I don't know which yet). The 12 months of data were almost the exact same numbers, but not exactly the same. The first 3 decimals of many monthly data are the same as the 3 decimals of the monthly data in Excel, but 4th-7th decimals are different.

My apologies for the incomplete question. I copied a large part of 1 post of an other topic of mine, I don't know yet which commands exactly lead to the different outcome.

Thank you for your thorough explanation. The code I'm running on both computers should be exactly the same because I used an usb to transfer the .do-file.

Last update: somehow my .do-file also changes decimals, some numbers get other 3th-7th decimals and other numbers get other 4th-7th decimals. Which kind of Stata codes can do this? If I know which commands caused this problem, I probably can solve it

[Clyde Schechter]

Knowing that your problem is in the 3rd-7th or 4th-7th decimal places doesn't quite pin down the problem. Stata's internal representation of floating point numbers (and that of every statistical package I know of) uses a binary equivalent of scientific notation, and there are no "decimal places." More useful is to know how many significant figures are being preserved. If your numbers are agreeing to about 8 significant figures but disagreeing after that, it is probably a precision problem relating to the default float storage type. Here's an example of how even the simplest command can create such a problem:

clear*
set obs 5
gen double x = 1000000*runiform()

//  NOW COPY THE VARIABLE, BUT "FORGET" TO SPECIFY DOUBLE STORAGE TYPE
gen y = x
//  AND MAKE A COPY THAT CORRECTLY PRESERVES DOUBLE PRECISION
gen double z = x

format x y z %12.4f
list

Since nearly any command can produce this kind of problem if you are not diligent about it, it is going to be difficult to pin down where you are going wrong, and I think you will need to thoroughly familiarize yourself with precision issues in order to get this right. I highly recommend Bill Gould's http://blog.stata.com/2012/04/02/the...-to-precision/ for this purpose.

If, on the other hand, you are seeing discrepancies in high order significant digits, then some very different problem may be occurring and we would need more information to help you diagnose it. (Although problems in high order significant digits can also result from precision problems if, for example, you are calculating a variable as the difference of two variables is very close to zero.)

[LydiaSmit]

Solved. I restarted my computer and somehow it doesn't give any differences any more

Thank you for the advice Clyde.