Did something change with -collect layout- when using var ?

[Scott Adams]

Hi,
I had some code like this, where var1, var2, and colvar1 are all categorical.
Layout specifications that used to work in March 2024 are now giving "layout specification does not identify any items" message
Pretty sure this is due to the update of April 2024 which does note a change in how categorical variables are specified in collect layout.

table (var) (colvar1) ///
   ,statistic(fvfrequency var1 var2) statistic(fvpercent var1 var2) nototal

collect layout (var[var1 var2])(colvar1#result[fvfrequency fvpercent]) //this used to work but now "layout does not specify" message

collect layout (var[i.var1 i.var2])(colvar1#result[fvfrequency fvpercent]) //seems between March 2024 and now, i. is needed.

The problem is that this breaks quite a bit of code for me.
I am a little confused as to why the original code without "i." worked anyway, as it also does not work if I revert to v. 17.

So I am just wondering whether specifying "i." inside var[] is from here on required/expected?

(Maybe this post will help someone else as well who finds reports now missing tables, and tables in reports now missing a bunch of variables.)

Thanks,
Scott

[Simon Pfaff]

Hallo Scott,

I have a couple of ados, where I use "collect layout" quite a bit. Since I am not eager to change anything, I have not updated Stata, yet ;-)

Your question if

specifying "i." inside var[]

is required, is pretty relevant for me, too.

Thanks a lot for bringing that up! I need to have an eye on this one...

Simon

[Jeff Pitblado (StataCorp)]

The change was due to a bug fix in Stata 17 and Stata 18.

See help whatsnew in Stata 18, dated 04apr2024 item number 8.
For Stata 17 the update is dated 21may2024 item number 2.

8. collect did not follow the same factor-variable expansion rules as
Stata's fvvarlist for dimensions across, coleq, colname, roweq,
rowname, and var. This has been fixed.

For example,

. sysuse auto
. collect : regress mpg foreign#rep78 foreign
. collect layout (colname[foreign]) (result[_r_b])

Notice that in the model specification, foreign is present in two
terms. The first term is the interaction foreign#rep78, and here
foreign is treated as a factor variable. The second term is foreign
and, without a factor-variable operator, it is treated as a continuous
predictor. Before the fix, the layout was incorrectly translated to

. collect layout (colname[i.foreign]) (result[_r_b])

instead of keeping foreign as an unadorned variable name. Prior to the
fix, the only work-around was to use c. notation, as in
colname[c.foreign], to prevent translation to colname[i.foreign].

[Scott Adams]

Thanks Jeff, but I find the -whatsnew- a little cryptic and wasn't sure how it applied to my problem.

I had an "unadorned" categorical variable from a -table- command and expected it to translate to "i." because it was used in a statistic(fvfrequency) option (which does not accept "c.").

However it seems that since the update the unadorned variable is assumed continuous -- therefore var[var1] returns nothing and var[i.var1] works ?

Seems safest is to always use either c. or i., and I will need to update code.

Best,
Scott