[George Ford]

add weight options to egen mean

[Arnold Levinson]

Could you expand the column for value labels after --svy: tabulate--? Right now it only shows 8 characters, and when labels start with similar words one has to run --tabulate varname-- to see the full labels. Minor inconvenience, but since there's lots of room in the results table, maybe an easy change?
Thx...arnold

[Richard Williams]

I would like to see a het option added to gsem, similar to the option that is already available in hetprobit, hetoprobit, and the user-written oglm.

AI claims there already is a het option in gsem, and I think we should do everything we can to keep AI from looking bad. ;-)

https://www.statalist.org/forums/for...option-in-gsem

[Brandon Istenes]

I would like for the expression "x > y" to evaluate to missing when x is missing.

I have been programming for many years and cannot imagine why someone would *want* for "missing" to be treated as "infinity." If it simplifies things for Stata's calculations internally, let that be an implementation detail which is hidden from the user. As it stands, all it does is make code harder to reason about, and make it very easy to get mysterious bugs. It is unintuitive and surprising behavior.

To support backward compatibility with Stata scripts that intentionally use "missing" to mean "infinity," or use numerical comparison to check for missingness, this should probably be controlled by a setting.

[Clyde Schechter]

There are problems with the suggestion in #424. To see the problem, suppose we want to evaluate the expression -(x > y) | (a > b)-, and suppose that x is missing. If the x > y part evaluates to missing, then how do we evaluate missing | (a > b)? In the current situation, missing, like all non-zero numeric expressions, is treated as true when logical operators are applied. So the net result would necessarily be true. But that seems inconsistent with the intention of #424, which, I presume, is that if x is missing we really don't know whether x > y or not, so we shouldn't call it true: it really should equal the truth value of (a > b). I could come up with other similar situations where the evaluation of logical expressions would become paradoxical if we adopted the convention proposed in #424. I think the only way out of this would be to convert all logical operators to 3-valued logic.

Now, I would have no objection to moving to 3-valued logic: I not infrequently find myself having to emulate 3-valued logic in my code, and would be happy to have it built-in. But that's a major change, and people who are not used to working with 3-valued logic might find this as great a difficulty as adjusting to the current convention that missing values are greater than any real number.

But I think adopting the convention that x > y evaluates to missing when x is missing while still keeping two-valued logic would be the worst of both worlds.

[Daniel Schaefer]

I would also prefer a 3 value logic system in Stata and I think that is what #424 really wants. This has been debated on this forum before (and reportedly many times at Stata Corp) but Brandon Istenes, I'm skeptical this change will be made at this point because it will likely break a mountain of legacy code.

adopting the convention that x > y evaluates to missing when x is missing while still keeping two-valued logic would be the worst of both worlds.

[Daniel Schaefer]

Although (just thinking about this a bit more) there is a versioning system that supports code written on older Stata standards already. Maybe it's possible after all.