Hi,
for most plotting commands, the user has the option --output=filename to send output to a specified file or mode (display). This option exists for the following commands:
- boxplot
- gnuplot
- plot
- hfplot
- panplot
- qqplot
- rmplot
- scatters
However, for the following statistics offering to store the results as a plot, the option, which does the very same thing, is named --plot=mode-or-filename:
- freq
- corrgm
- corr
- hurst
- pergm
- xcorrgm
I found this distinct naming inconsistent and suggest to add an alias, namely --output=filename, for all listed commands (assuming I haven't forgotten any). This alias would avoid issues with backward incompatibilities.
Best,
Artur
I think the difference is that the second group of commands do actually produce something other than a plot, namely a calculation or a test result. And so you couldn't just use "output", because it wouldn't be clear that you're talking of the plot.
In principle an overall alias like "plotfile" or something like that could be introduced, but I'm not sure I actually like that.
cheers
sven
Thanks for your comment, Sven.
Definitely a fair point to distinguish between a "statistical output" and a "plot". I would like to remind that for statistics we currently have the
$resultaccessor which actually returns some statistics like the test statistics or pvalue. I am not aware of any statistics which could be returned or stored via the --output flag -- but I may be wrong.My major reason for this request is to make things simple(r) and more consistent for the user. Having a single option gretl/hansl-wide for all commands/ functions for storing plots would make things simpler I would say.
I think the naming of the option is of 2nd order importance and could be discussed.
Artur
When I wrote "you couldn't use", I meant that the name "output" wouldn't be very clear, not that it would be technically impossible. BTW, for test commands the accessors are actually $test and $pvalue, not normally $result.
Yes, I agree that a general alias is something to think about in principle. I don't have a definitive opinion about it yet, that's what I wanted to say.
After looking at this again, personally I think it's not very important because there is actually a consistent logic between the difference, like I mentioned in my first reaction. But I'm not against a "--plotfile" alias option (or even re-using the --plot option for the first group, although it would sound a little redundant: gnuplot .... --plot=myfile.pdf). However, @allin and @jacklucchetti, I understand that those double-dash options are sometimes not so easy to squeeze in and so maybe that's an obstacle?
Yes, I agree that this ticket has not that high priority.
I think that in the meantime (since the latest post in January 2023) there's a new aspect: Many of the mein plotting commands now have an --outbuf option. Surely we don't want to add yet another option to these other commands here like 'freq'. But it's not clear to me whether the --plot option for these commands can also be used to fill a string buffer like the --outbuf option does. Probably not, but in some sense this may be debatable.
Yes, good point we should discuss in our meeting.
IMO there's no need for action here. Why would anyone want the equivalent of --outbuf in this context? Presumably as a convenience for constructing a composite plot. But from gretl 2023c the recommended way of constructing such a plot will be gpbuild, and it can get a plot buffer from freq and friends by internal means. If anyone really wants to get hold of a plot buffer from a command that doesn't offer the --outbuf option, for Do-It-Yourself purposes, it's not difficult to call for a gnuplot command file via the --plot option then grab a buffer via readfile().
OK, I think I agree, and so I'm closing this. Sorry, Artur, but now that the other commands have both --output and --outbuf, I think the harmonization argument has lost much of its appeal, and the functionality isn't restricted anyway.