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: A bug in egen and gen?


From   Nick Cox <njcoxstata@gmail.com>
To   statalist@hsphsun2.harvard.edu
Subject   Re: st: A bug in egen and gen?
Date   Thu, 17 Feb 2011 19:23:17 +0000

You're saying, in effect, that nearly doubling storage would not
typically bite users. That will be true in some cases but not all.

There is no need to wonder. The help for -save- says there is no such
option. But -compress- before -save- is naturally a very good choice
and you could program your own wrapper for -save- that always did it.

Here is a sketch:

program jlsave
version 8
compress
save `0'
end

But if you do what you just said you wanted to do, -set type double-,
using -compress- is not going to give you back more than a fraction of
the extra storage you spend. The fraction will depend on how much you
deal with strings, always integer variables, etc.

On Thu, Feb 17, 2011 at 7:11 PM, Liao, Junlin <junlin-liao@uiowa.edu> wrote:

Storage wouldn't be a problem if we perform -compress- command
regularly. I'm wondering if Stata can let you select an option
whenever it saves data, it compresses. It will surely be handy to
solve this problem.

Nick Cox

> In practice, if StataCorp always warned you of everything that could bite you, the help would be much, much longer.
>
> Your last suggestion would typically leave -double-s in place unless it so happened that the result was integers in every observation. To see why, study Bill Gould's recent postings on the StataCorp blog.
> That would on average nearly double your storage. If you don't mind, you might as follow Stas' suggestion and -set type double-.
>
*
*   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–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index