I have a malfunction in 1.10.0cvs (30/3/2015) on Windows 8.1
If you try to omit variables of a estimated model with the sequential
option, changing the p-value to 0.05 (intead of 0.10), Gretl gets into a
loop (?) and indicates 'Out of memory' after a cuple of minutes blocking
I tested with the banks91. gdt and the anscome.gdt and find problems
with German, Portuguese and Galician (mine) language. No problems with
Italian, English and Spanish. May be due to the comma in the box with
the p-value in former languages.(?)
Juan C. Estévez
Dpto. Economía cuantitativa
I think I've found a slight GUI bug, in a Windows snapshot, which I
think is related to the introduction of tabbed windows in the script editor:
- have one script open with unsaved changes
- click the "open" button
- gretl pops up a dialog asking if changes should be saved; but this
makes sense only if the current window tab were to be replaced
- and if I answer "no" (or "cancel"?) and open the second script then
the changes are saved anyway it seems-
I think the introduction of the array type kind of begs for an extension
of the "foreach" loop variant.
Something like this:
matrices Ms = array(3)
loop foreach i Ms
$i = I(2)
I'm aware that the same thing could be achieved with
matrices Ms = array(3)
Ms[i] = I(2)
so this is syntactic sugar and I admit that I'm influenced by Python's
"iterables" concept or whatever it's called.
One longer-term argument in favor of more "foreach" usage could be that
such a loop is almost by definition "parallelizeable"; it could be taken
to mean that the individual loop iterations are independent from each
other. I think something similar is happening with R's foreach package.
I'm trying out the new array types. And I've noticed that the error
message here is much less informative than in the analogous case where
for example a scalar would be expected.
function matrices hello (matrix in)
return in # wrong type
Gretl snapshot from March 17th just says "data error".
I noticed that when I use gretlcli.exe (which I don't do very often), in
the output I get numbers with local decimal separator comma, even though
in the (GUI) settings I have disabled the local comma.
Is that expected? If so, how does one switch off the comma for the CLI?
I know about the --english option, but I don't necessarily want to
change the language (although that would be ok as a workaround).
Or is it a bug?
matrix a = seq(1, 10, 0.5)
which gives an illegal argument error. I understand why that is, but the
doc says the 3rd argument must be positive and fractional stuff is
ignored. So I guess the doc should be changed to say it must be \geq 1.
I'm sparing gretl-users the gory detail ;-)
On Sat, 14 Mar 2015, Sven Schreiber wrote:
> Am 14.03.2015 um 15:15 schrieb Allin Cottrell:
>> On Sat, 14 Mar 2015, Sven Schreiber wrote:
>>>>> list X=dummify(Z5) --drop-first
>>> Remark for Allin and Jack:
>>> BTW, I think the error message is strange insofar as IMO the parser
>>> should complain already about the "--" in there, not about the "drop"
>>> word, no? But perhaps this has been changed since last release.
>> The "--" is in principle OK if interpreted as "minus minus", as in "y =
>> f(x) --a".
> Right. So if by coincidence "drop" and "first" were both existing
> scalars (or even series?) then no error would be issued and the
> expression would be read as:
> list X = dummify(Z5) + drop - first
> Because "drop" and "first" are not reserved words AFAICS. Maybe I'm
> being paranoid, but somehow this makes me nervous...
Yes, the statement would be read pretty much as you say. However,
"drop" and "first" will not be the names of series in the list
created by dummify(Z5), nor in fact by any invocation of dummify().
What if they're the names of scalars? Well, it's possible to cook up
a case where something of the sort appears to "work":
list X = 1 2 3
list X print
scalar drop = -4
scalar first = 3
list Y = X --drop-first
list Y print
This actually exposes a little bug. The "+" operator is not
recognized for adding a term to a list (simple concatentation is how
that's supposed to work), but when it's disguised as "--" it somehow
slips through, although it doesn't have the effect of adding series
number 4 to list Y. I'll take a look at fixing that.
On your broader point -- something that's really an error from the
user's point of view may under certain conditions go through as a
totally unintended command -- well, I think that's the price to be
paid for flexibility. I don't think we want to be saying to users
"Did you really mean minus minus?"
the following terms are not syntax-colored in the latest snapshot:
and from the new plot...end plot block:
Don't know if the plot options "with-lines" etc. should also be colored
(without the leading double-dash I mean).
another new discovery for me after all these years: There is a nice
context menu in the system spec dialog. I propose to give a hint in the
subtitle of the dialog which now says "please consult the help" and
could be extended with "... and right-click to paste common keywords" or
Hi, especially Jack,
I just noticed that Sourceforge seems to offer a project wiki. So
perhaps the existing wiki could be migrated (without the obsolete
content) to sourceforge. However, I don't know about the feature set,
whether something is missing that we would require. OTOH the current
wiki doesn't seem to be used much, so I guess not many features are needed.
I guess I could administrate that new wiki (if so desired), perhaps that
would also lead to me looking at the issue trackers more often.
Would that save you any work and/or make the wiki more useful?