[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
st: low level graphing issues
hi fellow listers,
i recently had to dive deeper into low level graphing than i ever thought i
would, and the experience made me question the unquestionable, namely that
stata is by far the greatest piece of software, over all categories, i ever
had the chance to pirate (kidding). here's the list of the most important
first, there is the seemingly simple routine of translating x-y coordinates
from the data domain into the row-column 23063, 32000 graph window realm
([G] gph, one of the examples). only it does not work, at least with the
stacked bar graph i used it didn't. my gph line'd vertical lines of a given
length, intended to be sitting right on the x axis, ended up hovering above
it. i had to fine-tune a multiplier term for the row coordinate to do the
job. (yline(num) as a high level graph option draws lines with the right row
coordinates though.) i guess is it because -graph- miscalculates the values
of r(ay), r(by), etc.?
then, how come there isn't a Graph2gph translator? am i the only one who
draws a graph, makes additions with gph, and wants to save the result
quickly and easily? or is there a workaround i have missed?
for that matter, in high level graphing, it would be convenient to be able
to write "graph, saving(filename)" in the command line, and save the last
graph without having to find and add the extra option to its command, which
might sometimes be in a do or ado file many directories away.
i understand that gph is under replacement with something better. the latter
two are mainly convenience issues, but for the data(xy) to window(rc)
conversion to work with pinsharp precision is still a minimum requirement in
i would be grateful for workarounds, ideas, and development plans/wish lists
from users and statacorp people alike.
* For searches and help try: