Bookmark and Share

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


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

RE: st: Rounding Errors Stata 12


From   "Gray, Charles" <[email protected]>
To   <[email protected]>
Subject   RE: st: Rounding Errors Stata 12
Date   Wed, 13 Feb 2013 09:47:41 -0500

Yeah I've read about data types and storage. Here is what the Stata help
window says:

"Stata stores numbers in binary, and this has a second effect on numbers
less than 1.  1/10 has no perfect binary representation just as 1/11 has
no perfect decimal representation.  In float, .1 is stored as
.10000000149011612.  Note that there are 7 digits of accuracy, just as
with numbers larger than 1.  Stata, however, performs all calculations
in double precision.  If you were to store 0.1 in a float called x and
then ask, say, "list if x==.1", there would be nothing in the list.  The
.1 that you just typed was converted to double, with 16 digits of
accuracy (.100000000000000014...), and that number is never equal to 0.1
stored with float accuracy.

"One solution is to type "list if x==float(.1)".  The float() function
rounds its argument to float accuracy; see [D] functions.  The other
alternative would
be store your data as double, but this is probably a waste of memory.
Few people have data that is accurate to 1 part in 10 to the 7th.  Among
the
exceptions are banks, who keep records accurate to the penny on amounts
of billions of dollars.  If you are dealing with such financial data,
store your
dollar amounts as doubles.  See float()."

I guess I just don't follow why .8 is stored as .801. My concern with
storing the variable as a double is memory usage. I've got several other
datasets that I'll be appending onto this one and I'm just not sure I'll
be able to store the variable as a double once I've appended all of the
datasets onto each other.

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Stas
Kolenikov
Sent: Wednesday, February 13, 2013 9:38 AM
To: [email protected]
Subject: Re: st: Rounding Errors Stata 12

Read about -help data types- and -insheet- your data as -double-s. The
default -float- does not have enough accuracy. (Add it to the wish list
for Stata 13: make -double- the default type, or get rid of -float-s
whatsoever; I have -set type double- in my profile.do, and only generate
-float- variables when I need to reproduce somebody's round-off errors.)

--
-- Stas Kolenikov, PhD, PStat (SSC)  ::  http://stas.kolenikov.name
-- Senior Survey Statistician, Abt SRBI  ::  work email kolenikovs at
srbi dot com
-- Opinions stated in this email are mine only, and do not reflect the
position of my employer


On Wed, Feb 13, 2013 at 8:25 AM, Gray, Charles <[email protected]>
wrote:
> I am having an issue with Stata 12 adding decimal places to data that
I
> insheet. I simply have a dataset in .csv format. The dataset contains
a
> variable 'item_revenue.' When I open the dataset in Excel, several
> observations have a value of 60237.8 for the 'item_revenue' variable.
> However, when I insheet the dataset into Stata, these values change to
> 60237.801. My insheet command is simply,
>
> insheet using "data.csv", comma clear
>
> My understanding is that the .csv format saves only the text and
values
> as they are displayed in cells of the active worksheet. So does anyone
> know why Stata would add decimal places to a variable?
>
> Thanks,
>
> Charlie
>
> *
> *   For searches and help try:
> *   http://www.stata.com/help.cgi?search
> *   http://www.stata.com/support/faqs/resources/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/faqs/resources/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/faqs/resources/statalist-faq/
*   http://www.ats.ucla.edu/stat/stata/


© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index