Re: [Gretl-devel] simulation speed (Allin Cottrell)
by Gordon Hughes
The revised version of the BigCrush test suite has now completed on
my Linux system. It reports no failures and CPU time of 32 hours
13.5 mins. This is a little under 9% longer than the execution time
for the Voss 24-bit version of the ziggurat.
Gordon
> A word of warning about running the BigCrush test. Looking through
> > the results of the first run I noticed that some of the tests
> > generate test statistics that would reject the relevant hypothesis at
> > the 1% confidence level, even though all of the tests were reported
> > as having passed (since the criterion is p in the range
> > [0.001,0.999]). Since we are dealing with a random number generator
> > it is possible that one run may lead to no failures but another may
> > generate a number of failures.
>
>If all is well, one expects to see p-values randomly distributed
>on (0, 1): if you didn't get some values < .01 on a large set of
>tests that would itself be suspicious.
>
>It would require a modified test program, but in case one gets
>p-values that look "too small" on some tests, it's possible to
>rerun those tests in particular rather than redoing the whole
>thing.
>
> > Hence I ran the same test a second time. The execution times were
> > very similar (29h 40m vs 29h 41m). The second run reported a single
> > failure - Test 89 PeriodsInStrings , r = 20 with a p-value of
> > 6.4e-4.
>
>Personally I wouldn't be too worried about that -- it looks
>within the bounds of what you might expect. P-values of less
>than, say, 10^{-6} would be problematic. The failures that
>Doornik talks about are values < 10^{-300} and I've seen nothing
>like that with our code.
>
> > Sven reported that the updated version of the ziggurat executes
> > substantially faster than the earlier version. The early tests
> > in the BigCrush suite give a different picture - the execution
> > times are all slightly longer using the new gretl_one_snormal
> > than using the previous ran_normal_ziggurat.
>
>As Sven said later, this is expected. The new code is
>substantially faster than what we had before we started down the
>Ziggurat road; but it's necessarily a little slower than the Voss
>code, which uses 24-bit values.
>
>Allin.
15 years
Q-Q plot, again
by Allin Cottrell
I'm starting to implement the normal Q-Q plot as a built-in
command. Question: should we standardize the series to be plotted
against the normal?
I notice that R does not standardize, but neither does it draw a
45-degree line. If you don't standardize but do draw the
45-degree line, then you get quite odd-looking results for a
series that has a substantially non-zero mean and/or a variance
that differs substantially from 1.
Allin.
15 years
libgretl commands help
by Hélio Guilherme
Hi,
I am restarting the translation of the commands (and functions) help.
I used the validate command to check for changes to my old xml file.
Found some commands still working but not documented. Here is a
report:
---
Findings from doc/commands/validate (old gretl_commands_pt.xml)
* ref command 'hccm' is not in libgretl
* ref command 'lmtest' is not in libgretl
* ref command 'rhodiff' is not in libgretl
* ref command 'testuhat' is not in libgretl
Findings from doc/commands/validate (current gretl_commands.xml)
* ref command 'addobs' is not in libgretl
(It is an alias)
The following commands are still working, but not documented (help
commands/functions):
hccm
lmtest
testuhat
---
Allin, please advise me on what to do about the help.
--
Also there are some "--quiet" documented but not implemented. I would
like to know if this option is to omit ALL output from the command.
I really like the Matlab and Octave solution for using a ";" at the
end of the commands to omit output. This would coexist with the global
"set messages off". What do you think?
--
I have compiled the PT help and PDF files, but the PT help files are
not shown in gretl (still the english version). The Italian version
works OK, and the files are correctly installed
(/usr/local/share/gretl). Maybe the problem is at menu calling point.
--
About the PDF choice in Preferences, can we have a CVS-sensible option
there for the Portuguese version?
--
(Consider my requests very low priority :)
Thanks,
Hélio
15 years
'null' list args in function package call
by Sven Schreiber
I'm just packaging the Gonzalo-Granger and Stock-Watson
permanent-transitory decomposition functions as requested recently on
the list, and I encountered what looks to me like a regression with
respect to earlier (maybe much earlier) gretl versions:
In my package two list arguments of the public function are optional,
i.e. the default value in the package is 'null'. This shows up fine in
the GUI function call window, at least at first. But after defining a
new list for *another* argument, this newly created list is entered into
*all* list argument fields, and the 'null' keyword also disappears from
the respective drop-down menus. (I can manually write the word 'null' in
the field ok, though.)
It would be nice if 'null' were unaffected and preserved in this case.
thanks,
sven
15 years
crash with func def
by Sven Schreiber
Hi,
executing a script file with the following functon definition crashes gretl:
function void check(
int myparam,
int nextparam)
print "do nothing"
end function
Of course I'm not saying that this syntax should work (it's ok for me if
it doesn't) but gretl shouldn't crash.
thanks,
sven
15 years
'end' and spaces
by Sven Schreiber
Happy new year,
'end if' with space is deprecated. Don't know about 'end loop', but it
seems to work although the help says 'endloop'. What about the other
'end' things? Personally I find it difficult to memorize the differences
of the space usage in 'endif' compared to 'end function', for example. I
don't have a preference for or against spaces, but when spaces are
abolished, couldn't it be done for all such keywords?
thanks,
sven
15 years
