ab.news(a)laposte.net @ INTERNET skrev 2007-09-18 00:13:18 :
> Otherwise, there are two small bugs in the "Tools" menu.
> 1. On the "Test calculator" window, when you check the "Assume std
> dev ..." option and click Ok a pop-up appears saying "Bad PNG
> header: Got bytes e0 22 0" and it doesn't produce the distribution graph.
I got the same kind of error for the test statistic calculator for test of
2 proportions, but the pop-up says "Bad PNG header: Got bytes fc e0 22 0"
Also, no graph is produced.
BTW, if one by mistake inputs a number instead of a proportion, one gets
the following weird output:
Null hypothesis: the population proportions are equal
n = 450, proportion = 10
n = 520, proportion = 12
Test statistic: z = (10 - 12) / -1.#IND = -1.#IND
Two-tailed p-value = 1.#QO
(one-tailed = 1.#QO)
I guess -1.#IND and 1.#QO are supposed to mean NA.
This is the Windows snapshot of version 1.6.6pre1 build date 09/17/2007.
I've diagnosed a bit more a bug I briefly mentioned a while ago; here's
I have the following minimal example script:
outfile --write "@userdir/optionerrortest.py"
print " tracestats = -teff * log(1-evals).cumsum()"
I'm expecting a file optionerrortest.py with the contents:
tracestats = -teff * log(1-evals).cumsum()
but I effectively get the following contents:
? print " tracestats = -teff * log(1-evals).cumsum()"
Invalid option '-e'
Fehler bei SkriptausfÃ¼hrung: Stopp
> print " tracestats = -teff * log(1-evals).cumsum()"
It actually seems to be a newly introduced behavior, because the test
script 'py4gretl_test.inp' that you (Allin) had requested in May fails
for the same reason, where it ran fine back in May. (It clearly was a
good idea of you to ask for that test scenario.)
cottrell(a)wfu.edu @ INTERNET skrev 2007-09-09 21:04:29 :
> On Sat, 8 Sep 2007, Javier García wrote:
> > I have installed the current snapshot and the problem has
> > dissapeared!!!!!!!
> Thanks, Javier. I think we can infer, then, that there was some
> obscure and rarely-triggered problem with my build of the fftw DLL
> for Windows (which was in the gretl package from the 1.6.5
> release until a few days ago).
I think this is a reason to release a new stable version 1.6.6 with this
problem fixed. It is not good to have a last stable release (version 1.6.5)
with this problem.
There is something wrong with the calculation of Fisher's Exact Test in
For the data set greene22_2.gdt I get the following result:
Cross-tabulation of Z1 (rows) against Z4 (columns)
[ 0][ 1] TOT.
[ 0] 99 216 315
[ 1] 72 214 286
TOTAL 171 430 601
Pearson chi-square test = 2.87983 (1 df, p-value = 0.0896954)
Fisher's Exact Test:
Left: P-value = -1.#IND
Right: P-value = -1.#IND
2-Tail: P-value = -1.#IND
The P-values of -1.#IND are of course very strange.
With SPSS I get a two-sided P-value of 0.103 and a 1-sided P-value of 0.054
for this same data set.
It sounds like a good decision.
cottrell(a)wfu.edu @ INTERNET skrev 2007-09-13 16:37:42 :
> The consensus seems to be that allowing user-defined variables to
> have the same name as functions is in general a bad idea, and on
> reflection I tend to agree.
> On the other hand, I take Andreas's point that not being able to use
> "gamma" for a variable is a pain.
> Does the following sound too messy?
> * rename the gamma function to "gammafunc"
> * deprecate "gamma" as a function-name but retain it as an alias
> for the time being
> * allow "gamma" as a variable name
> As I said, using "gamma" in both roles shouldn't actually be a
> problem for gretl at present, but this way we're not opening the
> floodgates of confusion. The possible coexistence of gamma the
> function and gamma the variable is temporary, not explicitly
> advertised, and not a precedent.
> Any takers?
> Gretl-devel mailing list
r.lucchetti(a)univpm.it @ INTERNET skrev 2007-09-13 13:45:23 :
> The gamma function is not terribly useful, by itself. Its logarithm is.
> One possibility would be to remove the gamma() function altogether and
> have users use exp(lngamma(x)) if they need to.
I think it is a bad idea to remove the gamma() function. First, some have
use for it, and it would be much more cumbersome to use exp(lngamma(x))
instead. Secondly, gretl needs more features, not have features removed.
Why not just change the name of the gamma function from "gamma" to
"gammafunction" or "gammaf" or something like that?
svetosch(a)gmx.net @ INTERNET skrev 2007-09-13 11:14:33 :
> Allin Cottrell schrieb:
> > > IMO it's not very likely that we'd want to treat gretl functions
> > as variables, but any other thoughts?
> > Without having read the thread thoroughly, I can see no real advantage
> of allowing such name clashes. One can always use "gammavector" or
> "mygamma" or whatever. The disadvantage I see is potentially confusing
> and hard-to-debug script code, and possible new bugs at the gretl
> interpreter level.
I am building some scripts that use the gretl shell command, my PC is quite
fast and I have no problems with the scripts, but I have just tried to run
one of them in a not so fast computer, and I found that gretl is not waiting
for the commands in the shell ( ! blabla ... ) finish.
Allin, I hate to return on this subject, but could you please see if something
about this (that seemed to be resolved, see
http://lists.wfu.edu/pipermail/gretl-devel/2007-January/000186.html ) has
been changed by error in the source code?
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
The help file for Nonlinear Least Squares needs to be changed. In the
example it gives it says that one could use the following code in the NLS
genr alpha = 1
genr beta = 1
genr gamma = 1
C = alpha + beta * Y^gamma
deriv alpha = 1
deriv beta = Y^gamma
deriv gamma = beta * Y^gamma * log(Y)
However, this results in the following error message: 'gamma' refers to a
function and may not be used as a variable name
It is pedagogically bad to have an example that does not work.
r.lucchetti(a)univpm.it @ INTERNET skrev 2007-09-12 23:23:51 :
> "Gamma" is a rather special case. Of all Greek letters, it's the only one
> that's more likely to be used to indicate a function than a parameter (or
> at least 50/50).
Well, we also have the beta function. Although this is not yet available in
gretl, it may be introduced in the future (hopefully).
> The solution I have used for years is to use "gama" with
> 1 "m" for parameters --- which does look ugly, but saves you incidents
> like this. Or, we could possibly take advantage of gretl being case
> sensitive and use "Gamma" (capital g) in the example.
A great advantage of being able to use use "gamma" as a parameter name is
that greek letters as parameter names are written as e.g. $\alpha$ for
alpha when saving the output in LaTeX format, and thus written as the alpha
symbol after compiling the LaTeX file. Which looks very nice.