[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

st: RE: question about -levelsof-

From   "Nick Cox" <[email protected]>
To   <[email protected]>
Subject   st: RE: question about -levelsof-
Date   Tue, 5 Aug 2008 17:45:45 +0100

This question has a historical aspect. I am the original author of
-levelsof-, which grew out of a program called -levels-, which in turn
grew out of a program called -vallist- (which still exists on SSC, under
different management). 

So was there a reason for my originally writing it this way? (There is a
separate question, was there a reason for StataCorp not changing it?) 

Sergiy and Roger are more confident than I at suggesting what the
reasoning was. Simply, I don't recall. But I guess that if I had been
asked at the time, I would have replied similarly: if you want that too,
it is easy to get it afterwards. I've been much impressed by the Unix
maxim that a program should do just one thing well and occasionally even
followed the precept. 

That said, I see no reason why Jeph should not clone -levelsof- and add
this -- nor no strong reason why StataCorp should not add this to
-levelsof-, except for prizing simplicity. 

This all underscores the difficulty of history of ideas. The event was
recent, the key personnel are all alive, well and relatively sane, but
very likely no one can reconstruct the exact reasoning. 

[email protected] 

Jeph Herrin

I find -levelsof- very useful, but a while back
decided it would be more useful if it also returned
the number of levels.

When I looked at the -ado- file, it seemed like
a trivial hack; the local macro -nvals- was already
there, so I just added

   return local nvals `nvals'

This seems to work, yet seems much too easy; but
looking through the code for a reason this
might sometimes fail, I couldn't find one.

So, my question is, is there a reason -levelsof-
doesn't return -nvals-? I use it so often, I worry
that maybe I'm setting myself up for disaster.

*   For searches and help try:

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