Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.

# Re: st: Stata cannot do math?

 From Nick Cox 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
>> 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/
```