Am 20.02.2018 um 17:11 schrieb Sven Schreiber: I have now tried the same thing with Julia, and the number with the binary transfer is essentially the same. The pure calculation seems a little bit faster, with Julia around 1.4 secs. The way I have implemented writing a binary matrix file for import into gretl was pretty straightforward, maybe that's something for gretl_io.jl, too: <julia> out = SB(x,b,n) # the JITted function (r,c) = size(out) indotdir = <hardwired dotdir> * "SBtransf.bin" f = open(indotdir, "w") write(f, "gretl_binary_matrix") # mandatory by gretl write(f, Int32(r)) write(f, Int32(c)) write(f, out) close(f) </julia> Even though I'm a big Python fan, I have to say that Julia is looking very attractive as a kind of backend for gretl to accelerate the bottleneck functions where hansl would be too slow. Some of the reasons are: 1) It uses base-1 indexing like hansl (contrary to Python/Numpy), so less confusion there when mixing codes. 2) JITting comes out of the box without additional tricks like Numba and decoration. 3) It doesn't have significant code formatting (indentation), which makes it easier to embed the code in hansl scripts with 'foreign' blocks. cheers, sven

Am 22.02.2018 um 12:55 schrieb Sven Schreiber: Thanks for sharing this nice example, Sven. Indeed a nice illustration of the fact that it might be worth to cooperate with other packages for specific tasks to gain speed. However, in my case extending SB() by calling Julia for specific tasks doesn't really make sense as for a typical length of a time series (let's be generous and set T=300) and even nboot=19999 iterations gretl still performs similar as Julia's computation time plus file transfer time. Nevertheless, I am pretty sure the gain could be substantial for instance for Threshold_Panel(), johansensmall(), pmbb() and SVAR(). Yes, I would support this! Best, Artur

On Sat, 24 Feb 2018, Sven Schreiber wrote: Yes, that's the feedback I got from Beppe Cavaliere and his co-authors too. ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti -------------------------------------------------------

On Wed, 21 Feb 2018, Sven Schreiber wrote: One more follow-up on this. We should probably aim to extend the binary matrix transfer facility for R too, and maybe octave. But I'm not going to hold the next release for that; and I should point out that it can be a little fiddly, for two reasons. 1) The gretl_matrix struct employs column-major order, and when we write or read matrices in binary mode we just dump out, or read in, all the values in that order. So when implementing a "foreign" transfer it's important to check the code via round-tripping. In the case of Julia, for example, when reading a binary matrix written by gretl we can't just read (rows * cols) doubles in directly, we have to place the values properly, as in for j=1:c for i=1:r M[i,j] = read(f, Float64) end end as opposed to "read(f, Float64, r*c)", which would scramble the matrix! 2) In gretl_binary_matrix files we standardized on little-endian format. Pretty much everything is little-endian these days, but all the same we should guard against getting total garbage in the case of mixing byte-orders. In the unlikely event that Python or Julia are running on a big-endian machine we need to convert to little-endian format on writing, and from little-endian format on reading. Both of these points are handled in the facilities for Python and Julia in current git. Allin