Notice: On March 31, it was **announced** that Statalist is moving from an email list to a **forum**. The old list will shut down at the end of May, and its replacement, **statalist.org** is already up and running.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

From |
"Roger B. Newson" <r.newson@imperial.ac.uk> |

To |
statalist@hsphsun2.harvard.edu |

Subject |
Re: st: RE: Re: STATA mistakes divisions! |

Date |
Fri, 16 Mar 2012 19:55:20 +0000 |

Roger References

Roger B Newson BSc MSc DPhil Lecturer in Medical Statistics Respiratory Epidemiology and Public Health Group National Heart and Lung Institute Imperial College London Royal Brompton Campus Room 33, Emmanuel Kaye Building 1B Manresa Road London SW3 6LR UNITED KINGDOM Tel: +44 (0)20 7352 8121 ext 3381 Fax: +44 (0)20 7351 8322 Email: r.newson@imperial.ac.uk Web page: http://www.imperial.ac.uk/nhli/r.newson/ Departmental Web page: http://www1.imperial.ac.uk/medicine/about/divisions/nhli/respiration/popgenetics/reph/ Opinions expressed are those of the author, not of the institution. On 16/03/2012 18:36, Nick Cox wrote:

I said precision of 1 part in 10^7, meaning relative precision. I didn't mean absolute values of that order (or finer). Nick On Fri, Mar 16, 2012 at 5:40 PM, Tiago V. Pereira <tiago.pereira@mbe.bio.br> wrote:Some general comments/questions: (1) Nick has asked "What science are you in that needs precision to 1 part in 10^7? Particle physics?" I can comment on my area: genetics. We routinely need calculations with very high precision (1-10^8 often) That's EXACTLY why I am using Stata. (2) Maarten wrote: "Some computations are even done in quad precision (approximately 34 decimal digits)." Question: Can one perform every calculation in quad precision? I would very interested in that.Thu, Mar 15, 2012 at 3:48 PM, Francesco Vidoli wrote:But therefore by default, without writing in every division "float", STATA mistake divisions? It's not only a visualization problem, we are trying to compare a SAS OLS regression and results simply do not add up if you calculate the variables of SAS or STATA ...No, there is no mistake. This is a phenomenon known as precision, and it is a result of the fact that computers cannot store most numbers with infinite precision. Stata (note: not STATA) has some smart defaults on how much precision to use for variables, computations, scalars, etc. In short data is by default stored with less precision (about 7-8 decimal digits) than computations (about 17-18 decimal digits). This is smart as even the 7-8 digits is complete overkill for real world data. Some nice examples of this can be found here: <http://blog.stata.com/2011/06/17/precision-yet-again-part-i/>. However if you want to do computations with variables than you want to overwrite this default, as many tiny rounding errors can start to add up to a large or at least noticeable error. You do so as follows: gen double varname = expression The key part is -double-, that tells you that the variable is supposed to be stored in double precision, i.e. about 18 decimal digits, which corresponds to the precision used by SAS and others. This is also what Stata programs do internally when they are using variables to do computations. Some computations are even done in quad precision (approximately 34 decimal digits).* * For searches and help try: * http://www.stata.com/help.cgi?search * http://www.stata.com/support/statalist/faq * http://www.ats.ucla.edu/stat/stata/

* * For searches and help try: * http://www.stata.com/help.cgi?search * http://www.stata.com/support/statalist/faq * http://www.ats.ucla.edu/stat/stata/

**References**:**RE: st: RE: Re: STATA mistakes divisions!***From:*"Tiago V. Pereira" <tiago.pereira@mbe.bio.br>

**Re: st: RE: Re: STATA mistakes divisions!***From:*Nick Cox <njcoxstata@gmail.com>

- Prev by Date:
**st: What is the current maximum number of "symbols" a Mata function can take?** - Next by Date:
**st: meta-regression - fitting quadratics** - Previous by thread:
**Re: st: RE: Re: STATA mistakes divisions!** - Next by thread:
**st: out of sample prediction after xtreg** - Index(es):