Re: [Gretl-devel] Octave support
Allin Cottrell schrieb:
On Wed, 24 Feb 2010, Sven Schreiber wrote:
> Allin Cottrell schrieb:
>>
>> Now we need a nice example of the use of Octave to illustrate the
>> yet-to-be-written entry for the User's Guide. Any suggestions?
> Well as Jack mentioned, maybe (cross-) spectral stuff would be a good
> area because of complex numbers. For example the "cohesion" measure by
> Croux/Forni/Reichlin?
Thanks for the suggestion. I was kinda hoping that somebody who
knows Octave better than I might actually contribute an example
for the manual. The only things that I know how to do in Octave
are boring stuff that you could do just as well in gretl.
The Matlab code is on www.economia.unimore.it/forni_mario/matlab.htm --
I could take a look next week whether that also works on octave and make
a "foreign" example. Actually to have the standard coherence available
in gretl via this wrapper would be nice. (cohesion would be nice, too,
of course, but coherence is standard spectral stuff.)
Forni doesn't mention any licensing or restrictions on his homepage (nor
in the .m files). Should we ask him for permission?
> And slightly OT: As a pythonista I would of course be interested in
> adding numerical Python (NumPy) to the list of supported foreign
> languages. I'm ready to help with the import/export functions. What
> exactly would be needed?
Basically, two functions in the target language, one to import
gretl matrices as written by mwrite(), and one to export matrices
in the format readable by mread(). Plus one auxiliary function to
return the gretl "dotdir". These get written out by gretl and
somehow (depending on the language) get "sourced" at startup
of "foreign" execution.
Ok that should be fairly easy. I may well have done something like that
already back when I cooked up "py4gretl". I'll also check that next week.
The idea of using GPUs for fast number-crunching sounds cool.
I should have added that the major speed boost currently only happens in
single precision due to GPU limitations. My feeling is that for
well-behaved data (after rescaling?) single precision should be okay in
econometrics, right?
cheers,
sven