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

From |
"Le Wang" <statauser@gmail.com> |

To |
statalist@hsphsun2.harvard.edu |

Subject |
Re: st: Bug? |

Date |
Mon, 20 Oct 2008 21:20:54 -0400 |

Sergiy Thanks for your reply. Sorry for my misleading subject line. I understood that it was a precision problem, but just couldn't figure out a better way to solve it. And I totally agree with what you said. Just want to add one minor comment. To preserve the precision of the variables, if we instead use the following gen double var1=0.2 we would get the correct count. Thanks again for your help. Le On Mon, Oct 20, 2008 at 9:10 PM, Sergiy Radyakin <serjradyakin@gmail.com> wrote: > No, not a bug. > di ceil(1/0.125) > 8 > > computers work with binary fractions, not decimal fractions. that's > why you should think about numbers like 0.03 as > 0.02999999999999999999999999999 or > 0.030000000000000000000000000000001, in other words x is (x+epsilon) > where epsilon is small and can be negative - representation error. > There is no such error when the fraction is a power of 2, e.g. one > half=0.5 or one sixteenth 0.0625. This is no different as writing > 1/3=0.3333333 in decimal notation. It is not exactly 0.3333333, but we > are most of the times fine with such representation. But functions > floor() and ceil() are by their very nature very sensitive to these > small differences. When using division (multiplication) the error > propagates to higher digits. > > This is another example from the same shelf: > clear > set obs 10 > generate var1=0.2 > count if var1==0.2 > tab var1 > > You should get a zero count when you count, but 10 in the table. > Repeat the same with 0.5 and everything will be as your intuition > tells you. That's why one never compares two real numbers, but rather > one compares their difference with an epsilon. > > If you suspect a bug, it is advisable to report Stata's version, and > OS version, unless you are sure that all versions are affected (e.g. > an error in the ado file). In some cases even compile_number may be > requested: display c(compile_number) > > Hope this helps. > > Best regards, Sergiy Radyakin > > > On Mon, Oct 20, 2008 at 8:36 PM, Le Wang <statauser@gmail.com> wrote: >> Hi all, >> >> Thanks in advance for your time. >> >> I am trying to use -- ceil() -- to do the following calculations that >> are supposed to give identical results, but the results turn out to be >> different. I couldn't figure out the solution to this problem. >> >> Le >> >> The codes >> ----------------------------------------------------------------------- >> >> . di ceil((0.05-0.04)/0.01) >> 2 >> >> . di ceil((0.04-0.03)/0.01) >> 2 >> >> >> . di (0.04-0.03)/0.01 >> 1 >> >> ----------------------------------------------------------------------- >> >> -- >> >> ~~~~~~~~~~~~~~~~~~~~~~~~ >> Le Wang, Ph.D >> Assistant Professor >> Department of Economics >> University of New Hampshire >> * >> * 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/ > -- ~~~~~~~~~~~~~~~~~~~~~~~~ Le Wang, Ph.D Assistant Professor Department of Economics University of New Hampshire * * 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**:**st: Bug?***From:*"Le Wang" <statauser@gmail.com>

**Re: st: Bug?***From:*"Sergiy Radyakin" <serjradyakin@gmail.com>

- Prev by Date:
**Re: st: Bug?** - Next by Date:
**Re: st: Problem with odbc load and long path name** - Previous by thread:
**Re: st: Bug?** - Index(es):

© Copyright 1996–2016 StataCorp LP | Terms of use | Privacy | Contact us | What's new | Site index |