2:54 p.m.
Ok, I see Jack's points.
That's a request for a suggestion for a different issue.
I have a matrix with some nan values (produced by the splendid function
"aggregate" ;-)) and I want to substitute the nan with zeros.
I have tried the replace command but it does not work with nan inside
matrices (while it works when the nan are in series).
The following command (which uses the fact that a nan is different from
itself) works as expected:
matrix m2 = (m1 - m1 .= 0)? m1 : 0
But I was asking if there is a more direct way to substitute nans inside
a matrix.
Bye
Giuseppe
On Mon, 6 Oct 2014, Giuseppe Vittucci wrote:
> Dear all,
>
> a few comments on the ideas that Jack and the others have suggested.
> I leave aside the issue of the icons for the moment.
>
> I really like the suggestion to give gretl users the possibility to open
> the log window automatically when they launch the program, or at least
> introduce an icon at the bottom of the main window to open the log.
I like the latter proposal better than the former. Having the log open
automatically may be distracting and a waste of screen space. I, for
example, often use the gretl GUI client simply for writing hansl code. The
command log would be no use for me whatsoever.
> One possible issue associated with this suggestion is that this
> increases further the number of open windows in gretl. The need to
> constantly move across quite independent windows is something that
> sometimes I find really annoying. I appreciate the reasons behind this
> strategy and I am not suggesting to switch to a completely different
> setting. A possible escape and, according to me, a way to have the best
> of both worlds is giving users the possibility to join/divide the
> frames. I am thinking about something similar to what you can do in
> Blender:
>
http://wiki.blender.org/index.php/Doc:2.6/Manual/Interface/Window_system/...
> If you introduce also the possibility to save a given arrangement, this
> will give the possibility to easily customize the workspace in a very
> flexible way, without harming users with small screens. This way a user
> can also easily recreate any frame arrangement he/she is more familiar
> with (rstudio, stata, matlab,eviews...). (Any small change that reduces
> switching costs should be welcome if we want to increase the number of
> users.)
This has been discussed many times. I personally don't want the gretl GUI
to become a window manager, and I think Allin feels the same way too. By
the way, have you tried Alt-PgUp/Alt-PgDn?
> Finally, some thoughts about the suggestion to introduce in the log
> windows a "gears icon" to re-run the commands.
> I suggest to increase the linkages between the log window and the shell:
> instead of automatically re-run a command, by clicking on a command in
> the log window this simply appears in the shell (it is not automatically
> run), so you can modify it before running it (that's because most of the
> time you do not want to re-run exactly the same command, but a slightly
> different version of it).
>
> I know that the previous commands can be recovered using the up arrow in
> the shell, but when the command is quite "old" and you do not remember
> exactly how far it is in the history, this process can be quite time
> consuming.
I take it that you use the word "shell" as a synonym of "console". In
practice, you're suggesting to Stata-ize gretl. Heresy! ;)
More seriously: I think that, from the viewpoint of workflow opimisation,
that would be bad. From my limited experience, this is a bad habit I've
seen it Stata users: (a) try something (b) see what happens (c) retry
with minimal variation and so on, and so forth, until you hit something
that you like.
Let's leave aside for the moment the fact that this IMHO leads to very bad
econometrics: this is very personal judgement, and I'm no David Hendry or
Joshua Angrist to force down people's throats my own ideas of what's right
and wrong. I suspect this leads to very inefficient workflow.
The way I see it, the right place for experimenting isn't the console:
it's a hansl script. That's why we're giving you the possibility of
running a selection of code, to keep more than one tab open, etcetera. So,
a hypothetical scenario close to what I think you have in mind is: (1) run
something from the menu (2) copy-n-paste the relevant line(s) ion the
command log into a hansl script (3) play with that (4) when you're happy,
save the script.
> Of course, it goes without saying that:
> - these are just a bunch of comments (that I wrote down just because
> Jack asked for them), so take them as they are
> - these issues might be probably better discussed in the Gretl-devel
> list (which I have just subscribed...);
> - this is an open source project and the power to decide where to go
> should be proportional to the time spent in the project and the capacity
> to make things happen, and I lack of both... ;-)
This is a community: the strenght of the project comes from the
possibility, which is open to everyone, to contribute by doing what
they're good at. Some folks are good at translating, some folks are good
at finding bugs, one guy is stellarly good at writing C code. ;)