Statalist


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

Re: st: Bug?


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/



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