Strings not marked for translation
by Henrique Andrade
Dear Allin,
I found some strings that I think are not marked for translation:
1. "No such file or directory"
When open a non-existing file.
2. "Scale is at maximum"
In a Gnuplot graph:
Best regards,
Henrique Andrade*
*
12 years, 9 months
long varnames once again
by Allin Cottrell
Making a little progress in relation to some bad examples (i.e.
examples that gretl handled badly) that were posted a while back.
Here's a test that works "OK" with current CVS.
<hansl>
nulldata 100
string s1 = "absurdly_hyperextended_varname"
string s2 = "wantonly_elongated_identifier"
string s3 = "extra_specially_verbose_moniker"
series @s1 = normal()
series @s2 = normal()
series @s3 = normal()
var 3 @s1 @s2 @s3
coint2 3 @s1 @s2 @s3
vecm 3 2 @s1 @s2 @s3
</hansl>
Allin
12 years, 10 months
an Odd example with restrict -- NA as a standard error
by Lee Adkins
I've encountered the following "feature." restrict is putting NA into the
standard error rather than 0, making it impossible to retrieve the
estimated standard errors as a matrix (or anything else). Is this as
intended?
? matrix s = $stderr
The statistic you requested is not available
coefficient std. error t-ratio p-value
----------------------------------------------------------
const 11.7952 0.0159611 739.0 0.0000 ***
sqft 0.000000 NA NA NA
sq_sqft 0.000000 0.000000 NA NA
bedrooms 0.000000 0.000000 NA NA
sq_bedrooms 0.000000 0.000000 NA NA
baths 0.000000 0.000000 NA NA
age 0.000000 0.000000 NA NA
It happens with the attached dataset. Since it won't return anything there
is no way to use zeromiss or ok to make it usable.
<hansl>
open "br.gdt"
square sqft bedrooms
logs price
list xlist = const sqft sq_sqft bedrooms sq_bedrooms baths age
matrix Rmat = zeros(6,1)~I(6)
matrix r = { 0 ; 0 ; 0 ; 0; 0; 0 }
ols price xlist
restrict --full
R=Rmat
q=r
end restrict
matrix s = $stderr
</hansl>
--
Lee Adkins
Professor of Economics
lee.adkins(a)okstate.edu
learneconometrics.com
12 years, 11 months
another crash
by Sven Schreiber
Hi,
I think I triggered a crash by doing the following:
try to append data -- Excel -- <get dialog with cell options etc.> --
press escape --boom
This is an October cvs version, on Ubuntu 12.04.
thanks,
sven
12 years, 11 months
Working paper series
by Sven Schreiber
Hi,
whatever happened with the plan of a working paper series? Does it exist?
thanks,
sven
12 years, 11 months
changing the scale of plots
by Allin Cottrell
There's something experimental in current CVS and snapshots. In a
gretl plot window, you can enlarge or shrink the plot by pressing
the "+" and "-" keys respectively (on the regular keyboard, not the
number pad at present). For this to work you need gnuplot with the
pngcairo driver (present in the Windows and Mac packages, and also
should be present on modern Linux).
Right now there are 4 fixed scales: 0.8, 1.0, 1.1 and 1.2 (with 1.0
the default).
If this works in a reasonably wide range of circumstances we can
think about enhancing it, and giving a choice of the default scale
for plots.
Allin
12 years, 11 months
gretl 1.9.11: once more on isscalar etc.
by Allin Cottrell
For now, let me just take this to the practicalities of the
next release. If you have any interest in this, please give
me your views on these two points:
1) The isscalar() function. This was introduced about 4 years
ago but never documented. It has been broken (I think) for the
past 3 years or so, until I fixed it a few days back. Should
we drop this function? Keep it and document it? Or leave it in
undocumented limbo? (I don't like the last option myself.)
2) My recent modification to the inbundle() function, which
now returns an integer code for the type of the bundled data.
Keep this modification and document it? Or revert it? If we
keep it, I'm assuming we'd also want to keep and document the
new typestr() function, which turns the return code from
inbundle() into a comprehensible string such as "scalar".
Allin
12 years, 11 months
typeof? (was Re: [Gretl-users] isscalar)
by Allin Cottrell
I'm moving this to devel since it's probably a bit arcane for
regular users.
And although I'll reply to the substance of Sven's post at
http://lists.wfu.edu/pipermail/gretl-users/2012-November/008250.html
I'm basically going to take this from scratch.
So we're looking at the is*() functions for determining
whether a certain string is the name of a variable of a
certain type -- or with isnull(), whether the string is not
the name of any variable. And we're wondering if some of these
are redundant (such as the undocumented isscalar) -- and/or
whether we're in need of more such functions, or a single
function which does the same sort of thing with greater
generality.
Taking stock of the cases where functions of this sort may be
useful, I'd say there are basically two (with a marginal
third).
1) Somebody has written a function with one or more parameters
that take a pointer-type argument, or a string argument, and
that have a default value of null. So the writer must test
whether the user has passed something or not. The isnull()
function will do the job fine. Functions like isstring and
isscalar can do the job too (inverted) but are redundant in
this context since the function-writer certainly knows the
type of the argument, if it's in fact supplied; he just has to
check for nullity.
2) As Sven pointed out, if a function accepts a bundle
argument -- in a context where the content of the bundle is
not guaranteed to conform to a known schema -- the writer may
need to determine (a) whether a given bundle contains an item
corresponding to a certain key, and also (b) the type of the
item, if present.
OK, so rather than proliferating is*() functions for all types
I suggested a more general typeof() function, which provoked
suggestions and counter-suggestions from Jack and Sven. I'm
now not so keen on that idea. If I'm right that the only
serious use case for such testing is in unpacking bundles [see
footnote], I think the job can be done quite efficiently via a
slightly modified inbundle() function -- and the
implementation is nice and easy.
That is, instead of inbundle just returning binary 1/0 for
presence or absence of the key, it returns an integer code for
the type of the item under the key (0 for none). Now Sven has
said he doesn't like magic numbers, and I sympathize; but a
little auxiliary function, typestr() -- which takes the code
from inbundle and returns a string -- can be provided for more
legible, perspicuous output.
I've put this in CVS but not documented it -- and I'm ready to
replace it if we come up with something that's clearly better
-- but here's how it looks right now:
<hansl>
bundle b
b["str"] = "throgmorton"
eval inbundle(b, "str")
eval typestr(inbundle(b, "str"))
eval inbundle(b, "x")
eval typestr(inbundle(b, "x"))
</hansl>
which gives
<output>
? eval inbundle(b, "str")
4
? eval typestr(inbundle(b, "str"))
string
? eval inbundle(b, "x")
0
? eval typestr(inbundle(b, "x"))
Done
</output>
That last is an empty string; it could be "none" or "null" if
we'd prefer. Right now the coding is 1 = scalar, 2 = series, 3
= matrix, 4 = string, 5 = bundle and 6 = matrixref (i.e.
matrix-pointer).
[footnote: Jack identified a third case where testing of a
variable's type could be useful, namely in working around bugs
relating to the distinction between scalars and 1x1 matrices.
I see that point, but I don't see it as sufficient reason for
a fully general typeof() function if it's the only use case.
When I got to thinking about it, I realized that implementing
a general typeof() -- one that doesn't just accept a string
argument (a putative variable name) -- would actually be quite
tricky.]
Allin
12 years, 11 months
Gamma distribution and percentiles...
by Mariusz Doszyń
Dear Gretl Users,
Maybe you have any ideas how to implement gamma distribution and
percentiles in hansl? These features might be very useful, in my opinion.
Regards,
Mariusz
12 years, 11 months
backslash
by Sven Schreiber
Hi,
nothing new here, but I just recently fully realized that the backslash
char \ has a double meaning in hansl: matrix left-division as well as
line continuation character. Isn't that unfortunate from a syntactical
point of view, in the sense that I could fairly easily imagine cases
where the meanings clash?
thanks,
sven
12 years, 11 months
