Statalist


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

Re: st: Parallel lists processing with nested value lists


From   Gawrich Stefan <[email protected]>
To   "'[email protected]'" <[email protected]>
Subject   Re: st: Parallel lists processing with nested value lists
Date   Tue, 19 Aug 2008 10:03:24 +0200

Thanks to Phil Schumm for his very concise version!

Nick Cox wrote:
I am not clear precisely what your argument is. 
The essence of this is to put what you want in macros like 
local l1  "price Price~of~the~car~in~$ green black 5"
and then take them out again as a series of constituent words. It's the
putting them in that's going to be a pain, and very likely that will
take quite as much programmer time as any other saving being discussed. 
--snip--


I don't think that parallel lists are easier to set up in general, it
depends on the use:
It's faster to write values of one kind (e.g. colors) one after another in a
local. 
But it needs a lot more attention to put every item in the right place.  
(Given many runs and parallel values: In the nested list case its easier 
to alter the number of runs (just skip/add set(s) of values) but in the
parallel lists case its 
easier to alter the number of values processed in parallel (just skip/add
local(s), secondary local(s) and alter command(s)). And I agree with Phil
Schumm that a nested list is presumably the less error-prone way.

When parameter setup in both ways needs equal time I'd prefer the nested
lists approach because it needs no additional manual setup.


**********************


Here's a syntax comparison based on the Stata FAQ example:
http://www.stata.com/support/faqs/lang/parallel.html

local agrp "cat dog cow pig"  
 local bgrp "meow woof moo oinkoink" 
 local n : word count `agrp'  
 forvalues i = 1/`n' {
    local a : word `i' of `agrp' 
    local b : word `i' of `bgrp' 
    di "`a' says `b'" 
 }

As I wrote earlier I feel that this syntax is not the best solution
imaginable. If Stata could recognize certain locals as parallel lists in
some way, the user wouldn't be bothered with manual setup and use of
secondary locals.

Phil Schumms remark towards nested lists made me think of an automated
routine.
I wrote a version of it but Phil presented a more concise solution. 
Listen to the animals with his version:

loc ldef "animal voice" 
loc plist `" `"cat meow"'  `"dog woof"' `"cow moo"' `"pig oinkoink"' "'
foreach item of loc ldef {
loc `item': list posof "`item'" in ldef
}
foreach plot of loc plist {
tokenize `"`plot'"'
di " ``animal'' says ``voice''"
}

One could even go further and skip ldef for the tokenize naming (1, 2  .. x)
if it's not too confusing. 
Here a case with three parallel values, one value with a blank in it ("oink
oink") and the build up of local "plist" over two lines: 

loc plist `" `"cat meow mice"'  `"dog woof bones"' "'
loc plist `" `plist' `"cow moo grass"' `"pig "oink oink" leftovers"' "'
foreach plot of loc plist {
tokenize `"`plot'"'
di " `1' says `2' and eats `3'"
}
 

Best wishes

Stefan



*
*   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–2024 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index