1. Can GRETL test whether a given sample is normally distributed?
2. I haven't found a Q-Q plot test in GRETL, (like in SAS e.g.). I think it
would be a good thing to add it.
3. Is there a portable version of GRETL?
first of all, as always many thanks to Allin and Jack for the new
release! Gretl continues to get better and better at what I still
consider to be a remarkable pace.
One interface-related example of that is the text-area-splitting in some
windows that was recently introduced. It got me thinking about some
aspects of gretl's general interface -- sometimes I have too many gretl
windows floating around for my taste. It gets confusing and switching to
the one I want sometimes takes a while because I have to flip through so
So I would like to suggest to somehow consolidate the various windows a
little in order to reduce the number of open windows.
For example, what about integrating the script output window into the
respective script window itself? In the upper part you might have the
script, and in the lower part the output.
In the same spirit, I think the session view window could be integrated
into the main window, side by side.
I used to think that such GUI reforms are very difficult to program, but
as I said, the recent window-splitting additions inspired some hope. But
of course these are just general thoughts and in a sense that would be a
luxury, not really a necessity.
I am playing with Gretl 1.8.6cvs on Mac OS X 10.6.2.
Load a script: two Gretl windows are now open (Main + script)
The View menu is not activated but I do have two gretl windows open.
2. Why Scalars?
Run for example klein.inp. Then we have a Main window, a klein.inp window and a script output window.
Now the View, Windows menu is active and shows three windows: Scalars, klein.inp and script output.
Scalars? There is no scalars window open. When I click on Scalars an empty scalar window is opened.
3. Window switching
Switching windows on Mac OS X is easy: Command+` or Command+Shift+`
which is an activity distinct from switching application.
As it stands now, I feel that the Window menu is a bit too buried in the View menu.
A main menu entry Windows could be considered.
Some keyboard shortcuts to switch windows could be quite useful but the problem is going to be to find shortcuts that will operate on all systems. Ctrl+1 etc seems logical but won't work on Mac OS X Leopard and Snow Leopard because of Spaces. Of course, Alt+Tab is always available but that switches between all open windows.
Ctrl+` to switch between Gretl windows only?
Mac users may have noticed that the gretl snapshots for OS X are
not refreshed as often as the Windows snapshot. That's because
I'm able to build, package and publish the Windows snapshot from
my Linux laptop at Wake Forest University, with a fast internet
connection, while up till now I have had to make the Mac builds at
home, using borrowed CPU cycles on my wife's iMac, and uploading
via a relatively slow DSL connection.
But I have now set up a linux-to-OS X cross-compiler on my machine
at work: if this works OK I'll be able to keep the Mac snapshots
up to date with ease.
There are test files at
(gretl-intel.dmg.gz and gretl-ppc.dmg.gz -- please note the .gz
I'm not able to produce Apple-type compressed disk images -- which
I think requires the use of closed-source Apple tools. So I have
just gzipped the dmg files.
If anyone is able to test these, that would be very helpful. The
gretl-intel image works fine on OS X 10.4.11, but it would be nice
to know if it works right on more recent OS X. And if anyone
still runs on ppc, ditto for that image.
I have a reproducible crash (on gretl 1.8.6, but don't know if the cause
was recently introduced or not).
It happens when you call the main function in the attached function
package with the same series in the first and second arguments (target
and cause), like so:
# in the context of denmark.gdt
matrix check = BreitungCandelonTest(LRM,LRM,null,3,100,0.05)
This is of course rubbish, but gretl shouldn't crash. (not a freeze, but
I will update the function package to check for such bad input and then
upload the new version to the server. So for testing use the package
attached to this email, not the one that will soon be on the server.
browsing (sifting?) through the feature request tracker there is one
very old request still open, namley "access to the ranking() command
from the GUI - ID: 1906097".
Actually we were in the process of discussing this shortly before 1.8.5
was released (see
but discussion stopped before anything was decided.
>> * access to the ranking() command from the GUI - ID: 1906097
>> IMHO there is no reason not to decide on what to do with it now, no? Is
>> there a plan to implement it (probably in the vicinity of 'add logs'
>> etc.) or should it be discarded?
> I'm not very enthusiastic. If we add rankings to the GUI menu
> we'd presumably have to add sorted series also, and my feeling is
> that this would clutter the menu.
I certainly don't have any problem with discarding that request.
However, let me point out for the sake of the argument that in principle
it would be possible to add a submenu 'other' where ranking() along with
all other transformations could be collected. The main menu wouldn't be
cluttered even in the long term. I'm not saying that that is necessarily
the best approach, but it would mean a step towards "everything is also
available in the GUI". So I think either of the two approaches would be
ok: Either leave it as it is now and have users look up the (excellent)
online or offline documentation for other functions, or throw everything
in a new submenu 'add-other'.
(The last paragraph was by myself.)
I think it's time for a decision: either discard this request (main
reason: avoid clutter) or introduce a sub-menu (main reason: try to make
all functions accessible via GUI).
Your votes, please.
First, thank you Sven for uploading this function.
For some data I get the following message which I can't interpret
Date strings inconsistent
error in new starting obs
error in function BreitungCandelonTest
> smpl 1 numoffreqs
Error executing script: halting
> matrix BC1 =
What's the problem here?
I suggest to change the icon for "code view" in the function package
list window. Currently its a cogwheel (right word?) which to me would
rather mean "execute". An intuitive alternative would be an eye of some
BTW, I like the new icon for "new script"!
and while I'm at it: In the OS taskbar the function package list window
only has a generic icon (Ubuntu 9.10, cvs self-compiled) instead of the
gretl icon. Same goes for the function package call (parameter input)
window. (and maybe for other windows as well?)