[Fahad Mirza]

While using grmap, i feel that the graph editor should have the ability to let people zoom and choose graph size from options. Further, it will be very useful to allow the option of adding leader text and diagrams to map locations which makes visualization less crammed in spaces where districts/small regions are close by.

Similarly, the ability to add gradient colors on scatter plots (or any plot for that matter) will be very useful in visually displaying content. I see posts #2 and #3 are also referring to same concepts.

[Sergiy Radyakin]

I would like to second John Mullahy's suggestion here to add zoom capability to the output window.
In OS MS Windows the standard approach is to use the Ctrl+MouseWheel to zoom in and out.
Such zoom has been added recently to the code editor, but is still absent from the output/results window and the viewer/help window.

Until this is added, the workaround that I am using is to produce the output with a small font setting (which prevents the tables in output from wrapping), then change the font temporarily for a zoom effect. Unfortunately the horizontal scroll bar does not appear (in Stata 16.0) so any content that doesn't fit into the screen can't be reached (panned to).

Thank you, Sergiy

[Joro Kolev]

Why is -nlsur- not accepting factor variables?

This needs to be fixed.

As -nlsur- stands now, one cannot use margins after it.

[John Mullahy]

It would be useful if -twoway- offered an option to draw circles with specified characteristics at specified locations, along the lines of twoway's text(...) option. E.g., one might wish to highlight a particular set of observations in a scatter diagram. For instance

local yc=5
local xc=2
local cr=.5
twoway scatter y x, ... circle(`yc' `xc' `cr', lcol(red) lwidth(*2)) ...

where yc and xc are the y and x coordinates of the circle's center and cr is its radius.

[Sergiy Radyakin]

It would be good to have block-comment folding in the do-editor for

/*
the 
multiline
style
*/

comments.

I commonly comment-out whole blocks of code and folding them away is useful while testing large files. Currently the procedure/program definition can be folded away, but not when it is inside a comment.

[Chinh Nguyen (StataCorp)]

It would be good to have block-comment folding in the do-editor for

/*
the
multiline
style
*/

comments.

We'll try to get that into a future update.

[Sergiy Radyakin]

Dear Chinh Nguyen,

thank you very much! I hope other Stata users will find this suggestion useful too!

Best, Sergiy

[Nick Cox]

#364 John Mullahy While you're waiting for StataCorp https://www.stata-journal.com/articl...article=gr0010 explains how to draw your own circles. A generalisation is something like this -- assuming input of three numbers to a do-file that are the coordinates of the centre and the radius.

args yc xc rad 

local min = `xc' - `rad'
local max = `xc' + `rad'

c_local call function `yc' + sqrt((`rad'^2) - (x - (`xc'))^2), ra(`min' `max') lc(black) || function `yc' - sqrt((`rad'^2) - (x - (`xc'))^2), ra(`min' `max') lc(black)

Naturally I have no quarrel with anyone preferring to think of the centre as being at (xc, yc).

This code pushes back the code in the bottom line back to the calling program as a local macro in the caller space, so that it can be included in some other syntax. Circles will only appear as circles with equal scales on both axes.

[John Mullahy]

#368 Thanks Nick Cox . While my reply should perhaps be a separate topic instead of a Wishlist entry, i'll just note a different workaround I used based on twoway's scatteri.

cap preserve
cap drop _all
sysuse auto
tw (scatter price mpg, legend(off)) (scatteri 4400 34.5, msym(oh) msi(*15) mlw(*1) mlc(red))
cap restore

[Nick Cox]

John Mullahy Your suggestion is clear and beyond #368 most of my thoughts run on doing very loosely similar things in very different ways, e.g. convex hulls

https://www.statalist.org/forums/for...-scatter-plots

or polar smoothing

https://www.stata-journal.com/articl...article=gr0021

[danishussalam]

It would be nice to have a command that is superior to simple addition by gen and rowtotal by egen.

If i add five variables with some of those variables having missing values.

- egen with rowtotal gives 0 if all variables are missing which obviously is wrong, it should be missing.
- simple addition by gen give missing(.) if one of the five is missing which is also wrong.

Maybe there is a fix already which I am not aware of.

[daniel klein]

- simple addition by gen give missing(.) if one of the five is missing which is also wrong.

How is that "wrong"? If one of the values in a total is missing (i.e., unknown), then, mathematically, the result must be misssing (i.e., unknown), too. That might not be the result that you want for whatever reason but there is certainly nothing "wrong" about it.

Edit:

btw. egen's rowtotal() has a missing option that does what you want. Note however that replacing missing values with 0 in some cases (at least one non-missing missing value in a row) but not in others (all values missing in a row) is inconsistent behavior; of all possible results, I would say what you want (and what the missing option provides) is actually closest to what I would deem "wrong".


Edit was written in parallel to #373 and #375 below.

[danishussalam]

How is that "wrong"? If one of the values in a total is missing (i.e., unknown), then, mathematically, the result must be misssing (i.e., unknown), too. That might not be the result that you want for whatever reason but there is certainly nothing "wrong" about it.

Yes - You are right. It is indeed correct mathematically. My suggestion was more about the command ignoring missing values and add what's left.

[Rich Goldstein]

daniel klein re: #371 - if all variables are missing with the rowtotal option, and you want the result to be missing, use the "missing" sub-option; in addition, I agree with #372 and see nothing wrong with either command and the way they deal with missing values and the totals

[Nick Cox]

#371 to #374

If you want

missing + 42

to be treated as having the same total as

42

then you want missing to be treated as 0. There is a side-effect that it is hard to tell apart

0 + 0

0 + missing

and

missing + missing

but you can't solve all problems at once. It's also hard to tell apart

0 + 0

-2 + 2

and so on.


The point often arises with groupings at different scales in which say totals over cross-classifications of X Y are needed together with totals over categories of X. The latter can't be aggregated easily from the former if this rule isn't followed.

As pointed out, for _final_ results if you want the sum of all missings to be shown as missings, then you can have that optionally. It's just not the default.