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: encode vs destring
From
Nick Cox <[email protected]>
To
"[email protected]" <[email protected]>
Subject
Re: st: encode vs destring
Date
Fri, 26 Jul 2013 23:16:15 +0100
As you say, this is for StataCorp.
My own view, just as a user, is that -encode- and -decode- could
benefit from some overhaul. Although I don't think either is an answer
here, see not only Roger Newson's -sencode- (SJ etc.) but also
-multencode- (SSC).
Nick
[email protected]
On 26 July 2013 22:49, Sergiy Radyakin <[email protected]> wrote:
> Thank you Nick,
>
> I was more concerned to hear that there is something that could go
> wrong if the -replace- option was added. Specifically the labels might
> get de-attached or there might be ambiguity which name will the
> value-labels schema receive, or something along these lines, similarly
> to why some commands support some types of weights that others don't
> support.
>
> Context: I am dealing with a bunch of files converted from Excel with
> allstring option, so yes, there are a bunch of variables that need to
> become numbers again, and no, there is no need to retain the original
> string variables as copies.
>
> The replace option just seem to fit to encode. Can it be added? (and
> since encode is built-in, this question is for StataCorp).
>
> Thank you, Sergiy
>
> PS: it does save only a couple of lines of code per variable: drop and
> rename, so no need to get an extra dependency to the project in the
> form of external commands:
>
> encode province, generate(p)
> drop province
> rename p province
> --------------------------------------
> encode province, replace
>
> On Fri, Jul 26, 2013 at 5:32 PM, Nick Cox <[email protected]> wrote:
>> -destring- was written that way; -encode- wasn't.
>>
>> Does that count as a reason? Perhaps not, but the original rationale
>> for -destring- (I can speak confidently on this point as its original
>> author) was largely to correct mistaken input, i.e. string input was a
>> mistake and the variable(s) should be numeric.
>>
>> The original rationale for -encode- was, in contrast, largely to let
>> users have it both ways.
>>
>> Nick
>> [email protected]
>>
>>
>> On 26 July 2013 22:20, Sergiy Radyakin <[email protected]> wrote:
>>> Is there any reason why Stata command encode does not support the
>>> replace option, which Stata command destring does support?
>>> Sergiy
>>> *
>>> * 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/
*
* 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/