Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.
From | Nick Cox <njcoxstata@gmail.com> |
To | statalist@hsphsun2.harvard.edu |
Subject | Re: st: Stata cannot do math? |
Date | Thu, 19 May 2011 11:40:22 +0100 |
There are no doubt several levels of subtlety here, but I think the best short summary is that Stata uses double precision arithmetic by default. Stata's default default [repetition intended] numeric type is -float-, which is why most clashes occur. Many readers will recall a spirited debate a short while ago about that, which I don't want to (try to) re-open. The "133" below is just a side-effect of the fact that this dialogue was executed while I had 133 observations in a dataset. . di 100.1 == 100.1 1 . di float(100.1) == 100.1 0 . di float(100.1) == float(100.1) 1 . gen double x = 100.1 . count if x == 100.1 133 . gen float x2 = 100.1 . count if x2 == 100.1 0 . count if x2 == float(100.1) 133 Nick On Thu, May 19, 2011 at 11:25 AM, Ronan Conroy <rconroy@rcsi.ie> wrote: > On 2011 Beal 19, at 01:20, Conor Hughes wrote: > >> Hi, >> Stata can certainly do math, just not quite the same math you're used >> to. This is an issue of floating point arithmetic. For example, >> replace >> count a == 100.1 >> in your code with >> count a == float(100.1) > > > I have a basic puzzle, which has just occurred to me: Stata cannot find any observations that satisfy the condition > > count if a == 100.1 > > we know that Stata is representing the contents of the variable a as an inexact binary representation of 100.1, but why does it not represent the right hand argument in exactly the same way, causing the two to be equal? How does Stata represent the quantity 100.1 when it evaluates the expression a == 100.1? > > Curious… * * 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/