Julia performance test and Gretl
by oleg_komashko＠ukr.net
Dear all, At Julia site (http://julialang.org/) they placed the results of a battery of small performance tests. The test scripts are referenced in the citation below:
" we’ve written a small set of micro-benchmarks in a variety of languages: C , Fortran , Julia , Python , Matlab/Octave , R , JavaScript , Java , Lua , Go , and Mathematica .
" I began to translate R code into gretl to do the same battery of tests for Gretl. The script attached. The firs test is about recursion: compute Fibonacci numbers. Either, I wrote very inefficient code, or recursion in Gretl is very slow and needs amending. The attachment also contains non-recursive script for Fibonacci numbers. It works several thousands times faster ( 172092 times on my pc) . Oleh
8 years, 11 months
Warning: MPI support
by Artur T.
Dear Jack and Allin,
this morning I've got the following note when opening latest cvs gretl
on my ubuntu machine.
"gretl is built using OpenMP, but is linked against
OpenBLAS parallelized via pthreads. This combination
of threading mechanisms is not recommended. Ideally,
OpenBLAS should also use OpenMP."
Honestly, I am not sure what's the best to do now.
Best,
Artur
8 years, 11 months
xmax and xmin now redundant through undocumented max and min functionality
by Sven Schreiber
hi,
quite a while ago the max() and min() functions were extended (IIRC) to
also allow matrix arguments, to avoid having to write something like
maxc(maxr(...)). So "max(ones(3,1))" has worked for some time.
First of all, I've just noticed that this is not reflected in the
function reference / docs, where only series and list arguments are
mentioned.
Secondly, this extension of max() and min() means that "xmax(a,b)" can
easily be written as "max({a,b})". I therefore wonder whether we should
keep xmax() and xmin().
Furthermore, perhaps max() and min() could be extended even further to
allow two scalar arguments, such that "max(a,b)" would become an alias
of "max({a,b})", to ease the transition from xmax() and xmin().
There are of course obvious backwards-compatibility issues, so this
should perhaps also be discussed on the users' list. But still; I've
always found xmax() and xmin() a bit weird...
thanks,
sven
8 years, 11 months
file search locations for mread()
by Sven Schreiber
Hi,
it seems to me that mread("fname") is not looking for "fname" in the
directory of the containing script. Is this intended? I might add that
using "./fname" isn't working here on Windows, either.
(It is looking alright in the current working directory, so an obvious
solution is to re-set that. Also please no comments about using the
user's dotdir, that's not the point.)
thanks,
sven
8 years, 11 months
scalars and 1 x 1 matrices
by Allin Cottrell
In my reply to Sven at
http://lists.wfu.edu/pipermail/gretl-devel/2016-January/006469.html
I said that the general intent in current gretl is that "anywhere a
scalar is wanted a 1x1 matrix is also accepted, and vice versa", so
that the distinction between these types shouldn't matter.
In that claim I was thinking about such objects on the right-hand
side of a "genr" expression, and I think the claim is correct in
that context. However, there's a somewhat different issue with
regard to scalars versus matrices on the left-hand side. Dealing
with this has been on my agenda for a while, but in today's git I've
finally tried to resolve it.
Here's the simplest possible example:
<hansl-fragment>
matrix m = {1,2,3,4}
g = m[1:1]
g = m[1:2]
</hansl-fragment>
Internally, if an expression specifies a sub-matrix (e.g. "m[1:1]")
its result is treated as a matrix, even if it's 1x1. However, if a
1x1 result is assigned to a variable of unspecified type, as in the
first "g" line above, it is "cast" to a scalar. Up till now, that
has meant that the second "g" line would fail: g being a scalar at
that point, you can't assign to it a 2-vector.
You could, of course, "fix" this by saying
<hansl-fragment>
matrix m = {1,2,3,4}
matrix g = m[1:1]
g = m[1:2]
</hansl-fragment>
All the same, it seems bad/unintuitive that gretl is refusing to
mutate a somewhat arbitrary assignment of type not called for by the
user.
So in current git, the automatic typing of a 1x1 result as scalar is
treated as provisional and mutable. I give below a more extended
example, showing three contexts in which the issue can show up. I
should explain that LOOPSAVE is an internal flag, signifying that
gretl will save a "compiled" version of any loops encountered when
executing a user-defined function so that they can be re-run more
efficiently when the function is called again. LOOPSAVE has been
around for a while, but turned off because it broke some function
packages. I've now turned it on, because with the new scalar/matrix
code it doesn't break any packages (I think, but more testing needed
before release).
<hansl>
/* Before: error at j=1 on the second call to savetest(),
since the assigned status of v as a scalar is remembered
from one call to the next (but only if LOOPSAVE is on).
Now works even with LOOPSAVE on.
*/
function scalar savetest (matrix *m, scalar k)
printf "savetest: k=%d\n", k
loop j=1..3 -q
printf " j=%d\n", j
v = m[1:k]
endloop
return k
end function
matrix m = {1,2,3,4}
loop i=1..3 -q
x = savetest(&m, i)
endloop
/* Before: error at i=2 since the assigned status of v
as a scalar is remembered from the first iteration.
Now works OK.
*/
loop i=1..3 -q
printf "i=%d\n", i
v = m[1:i]
print v
endloop
/* Before: error on the second line since g gets assigned
scalar status on the first statement. Now works OK.
*/
g = m[1:1]
g = m[1:2]
</hansl>
I should point out that the new code doesn't really override hansl's
strict typing. That is, if you say
<hansl-fragment>
matrix m = {1,2,3,4}
scalar g = m[1:1]
g = m[1:2]
</hansl-fragment>
You will get an "incompatible types" error on the last line, since
you stated that g is supposed to be a scalar. Only the "imputed"
scalar type is taken as mutable, and to matrix only.
Allin
8 years, 11 months
array functions
by Allin Cottrell
Given the fixes we've accumulated, and given that the New Year is
upon us, I'm thinking we should do a new release soon. But before
doing that I'd like to resolve a couple of points about array
functions.
Sorry, this is a bit long, but I'd appreciate hearing comments from
anyone who's able to follow what I'm talking about!
First, we have at present the semi-documented array() function (it's
in the User's Guide, but not in the Function Reference), and also
the undocumented mkarray() function, which lets you define an array
by supplying one or more expressions which evaluate to the specified
type. See
http://lists.wfu.edu/pipermail/gretl-devel/2015-November/006236.html
In relation to mkarray(), I floated the idea of merging this with
array() in
http://lists.wfu.edu/pipermail/gretl-devel/2015-December/006373.html
and Jack responded enthusiastically in
http://lists.wfu.edu/pipermail/gretl-devel/2015-December/006374.html
However, I'm now thinking that the merger is not such a good idea,
on account of the ambiguity of something like the following:
<hansl>
matrix m = {1, 3, 5}
matrices M = array(m[2])
</hansl>
Do we read this as a request to create an array with 3 empty matrix
slots, or as a request to create an array with one member, namely
the second element of m, taken as a 1 x 1 matrix?
Note that if we did not merge the two functions, then
matrices M = array(m[2])
would unambiguously select the first of these alternates, while
matrices M = mkarray(m[2])
would unambiguously select the second.
We could just legislate that one of these interpretations is
favoured, in which the user wanting the other one would have to take
an extra step:
scalar n = m[2]
matrices M = array(n)
# OR
matrix m2 = m[2]
matrices M = array(m2)
But I think it may be cleaner to retain both functions (and of
course, document both).
Second issue: at present the "print" command as applied to an array
gives fairly minimal information. For example, the input
<hansl>
strings S = mkarray("happy", "new", "year")
print S
</hansl>
produces the output
? print S
Array of strings, length 3
But we also have the undocumented function putarray(), which gives a
basic printout of the array members, as in
? putarray(S)
happy
new
year
Here, I'd like to canvas the options (a) keep what we have right now
and document putarray(), or (b) make the "print" command do what
putarray() does, and scrap putarray(). (Bear in mind that the array
in question might contain huge matrices rather than short strings.)
Let me note that both of these array-printing options are probably
best considered as relevant to writers of function packages,
primarily as debugging tools. If you really want to "pretty print"
an array you would probably want to write your own function.
Allin
8 years, 11 months
script editor
by Allin Cottrell
I finally figured out how to get gtksourceview to switch syntax
highlighting mode inside "foreign" blocks. You should now (git and
snapshots) get appropriate highlighting for R, Octave, Python, Ox or
Stata within such blocks.
Allin
8 years, 11 months
problem with pointerized bundle member
by Sven Schreiber
Hi,
I run into problems (=error) when I try to pass a bundle element as a
function argument in pointerized form. Minimal script:
<hansl>
function void hey(matrix *hu)
print "hey"
end function
bundle bbb
bbb.in = ones(2,2)
hey(&bbb.in)
</hansl>
I also tried "&(bbb.in)" (with parentheses), with no luck. I can
actually understand why pointing to something inside a bundle would be
problematic, but OTOH since we want to do lots of stuff with bundles and
still avoid copying large chunks of data, I'm wondering what the
recommended solution would be.
thanks,
sven
8 years, 11 months
need for advise on a new package
by oleg_komashko＠ukr.net
Dear all,
I want to do further development to
existing series of mfx packages.
Namely, I am going to add the following functionality:
(ALL with standard errors)
computing 4 statistics: me's, (+2 semi) elasticities (where correct)
average marginal effects
functions of independent variables with minimizing of use of numerical derivatives
correct treatment of group dummies, corresponding to multi-level factor x's
correct treatment of dummy-continuous and dummy-dummy interactions
inclusion of "unmfx-ed" models, i.e. heckit
This is rather work-consuming.
So, I'd like to proceed as following:
submit a v.01 on probit only for testing:
there are some questions about interface, and some others.
I'd like to have wishes, suggestions, critic etc. before doing
the rest.
Currently I can compute AME, treat functions of continuous variables
and group dummies (without interactions)
I will appreciate your opinion.
Oleh
8 years, 11 months
