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: Minor bug in -labvalclone- by NJC


From   Nick Cox <[email protected]>
To   "[email protected]" <[email protected]>
Subject   Re: st: Minor bug in -labvalclone- by NJC
Date   Fri, 22 Nov 2013 09:45:37 +0000

Thanks for your comments.

-labutil- is a user-written package of mine from SSC.

Rewriting a package requires both motivation and inclination, which I
have to report are lacking here on my part. -labutil- is really a
rag-bag of commands for manipulating labels, some of which seem at
this juncture distinctly odd. Some go back to the last century and may
well have been an answer to someone's question on Statalist.
Regardless of that, rewriting in a <command> <subcommand> style would
not I feel be particularly useful or appropriate, not least to anyone
who may use the existing commands occasionally. The programs don't
have enough unity to warrant a re-release.

One of these commands, -labmask-, is one that I still use myself a
lot. It does get mentioned on the list and received some publicity in
a Stata Journal column, so renaming such a program without  good
reason could just be confusing, even if the original program remained
accessible, as it would because of the SJ publication.

I don't quite follow your argument on checking that arguments are
integers. You seem to be saying that (a) it is unnecessary (b) it is
insufficient to rule out problems with extreme requests (c) it is not
your own style, to each of which I answer "Yes".
But I will look at the code for -labmask- (SSC, SJ) to judge whether
it can be improved.

Nick
[email protected]


On 22 November 2013 01:39, Sergiy Radyakin <[email protected]> wrote:
> Hi, Nick,
>
> if you are on it now, why not combine these 12 programs into
> labutil.ado with sub-commands? labutil copy, labutil mask, etc. Just a
> bit fewer files to manage.
>
> I've noticed you are trying to also check for labelling integers in
> several of the programs from the -labutil- package. I'd rather have
> Stata to issue this error message. For example in -labmask-:
>
> * integers only!
> capture assert `varlist' == int(`varlist') if `touse'
> if _rc {
> di as err "may not label non-integers"
> exit 198
> }
>
> Stata would still stumble at the "label define ...., modify" later on,
> with similar message. But if you want to handle all invalid cases in
> advance of that, being integer is not sufficient to be 'label-able':
>
> sysuse auto, clear
> egen double order = rank(-mpg), unique
> replace order=100000000*order
> labmask order, val(make)
>
> so inrange(`varlist',c(minlong), c(maxlong)) becomes handy.
>
> But I'd rather ditch the check unless it is preventing something else
> to go wrong in the program.
>
> Best, Sergiy
>
>
>
>
>
> On Thu, Nov 21, 2013 at 8:04 PM, Nick Cox <[email protected]> wrote:
>> Thanks to Sergiy for the public heads-up.
>>
>> I will get it fixed.
>> Nick
>> [email protected]
>>
>>
>> On 22 November 2013 00:45, Sergiy Radyakin <[email protected]> wrote:
>>> Bug in -labvalclone- by NJC
>>> http://fmwww.bc.edu/repec/bocode/l/labvalclone.ado
>>>
>>> ===Example:
>>> clear
>>> label define a 1 "US" 2 "UK" 3 "UA"
>>> labvalclone a aa
>>>
>>> ===Output:
>>> unrecognized command:  laabel
>>> r(199);
>>>
>>> ===Why does it happen:
>>> Because replacing blindly code is not safe. Nick is trying to check
>>> for this problem by having a safety check of the old argument earlier
>>> in the program:
>>> if "`old'" == "label" | "`old'" == "define"
>>> but later is doing a replacement of a SUBSTRING, not a WORD-by-word replacement.
>>>
>>> ===Suggested fix:
>>> Simply flank both args (old and new) with spaces:
>>> local line: subinstr local line " `old' " " `new' "
>>>
*
*   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