The current macOS (1.015, Catalina) has additional security checks.
The installer gives a warning for the current gretl-2019d-quartz.pkg distribution.
Apple warns that the program cannot be run. There is however a button to open the file so it can be opened (at your own risk).
But it is not safe to assume that this will continue to be the case.
See this page: https://support.apple.com/en-gb/guide/security/welcome/1/web
As of February 2020 Apple will require that apps distributed outside of the Mac store will have to be notarized.
which most likely means that the current gretl package can't be opened and that gretl cannot be run on macOS Catalina.
Another remark: I do not know how the macOS package is created but the contents cannot be inspected by Pacifist (an app used to view the contents of a ,pkg distribution; see https://charlessoft.com). Very useful app.
I'm observing an unexpectedly drastic slowdown of mols() when switching
to SVD (with 'set svd on').
My toy benchmark is to regress a 200x10 LHS matrix on a 200x80 RHS
matrix 5000 times. The matrices are not redrawn in order to measure just
the mols speed, not the RNG. On an oldish machine I get:
~ 3 sec without svd
~ 60 sec with svd
For comparison, Python/Numpy's linalg.lstsq takes ~ 8 sec and is said to
use SVD always.
There are at least two possible differences between gretl/svd and numpy:
1) numpy might be using Intel's Math Kernel Library (MKL) in the
background instead of standard Lapack (coming from the conda/Anaconda
2) The web says that numpy uses Lapack's DGELSD
whereas judging from lib/src/gretl_matrix.c in the function
gretl_matrix_SVD_ols (and maybe gretl_matrix_multi_SVD_ols? - don't know
what that is for) it seems that gretl uses DGELSS.
On the Netlib Lapack page it says
(https://www.netlib.org/lapack/lug/node27.html) that "The subroutine
xGELSD is significantly faster than its older counterpart xGELSS", and
it labels DGELSD with "solve LLS using divide-and-conquer SVD".
So, any negative side effects blocking the switch to DGELSD, or is it
something like a free lunch?
it just took me a while to realize that (inside mpi) I cannot write the
string aggrop = "sum"
but instead I need to go with string substitution:
I think the doc on p. 4 of the MPI guide is misleading there when it
says string argument (for mpireduce, mpiallred, mpiscatter). It's rather
a keyword apparently. I'm guessing that a string literal would work, but
Slightly related about string representations: Consider a string inside
b = defbundle("a", "ohoh")
print b # gives: a = ohoh
The meaning is pretty clear of course, but both the single equal sign
(instead of ":" or perhaps "==") and the non-quotation of this string
literal looks strange to me given the gretl rules.
this is on the Dec 14th snapshot, haven't tested on newer release, sorry.
string s2 = sprintf("\"hey\"")
string snull = 1 ? s2 : "null"
print snull # "hey", as expected
# short form with anonymous sprintf
string snull = 1 ? sprintf("\"hey\"") : "null" # error
Please, I need ssome help.
I am trying to obtain the parameters of the Bass model (p, q , m are
coefficient of innovation, coefficient of imitation and market potential,
respectively) . The message I got was that after 800 iterations convergence
was not reached.
The initial parameters were obtained with Excel's Solver. I had the same
issue before and I used the program NELREG which gave me same error but I
used a script and was able to find convergence. I am sure the same will
happen with greatl provided I use proper script.
I thank you in advance for help.
Some of you will have heard that the 2019d release was planned for
last week. Sorry, but the marking of exams and econometrics projects
has taken its toll. I can guarantee, however, that there will be a
release in time for Christmas! With lots of bug-fixes and quite a
few new features.
here is an extremely unimportant observation, not sure if it is even
supposed to be used in hansl. The same input gives different output in
printf and sprintf:
eval printf("%5s", "a") # gives a5
eval sprintf("%5s", "a") # gives a
(sorry for cross-posting Sven, Jack and Allin -- but I think this got
missed some days ago)
using latest git, I am bite puzzled why the returned series is not
string-values any more.
set verbose off
function series foo (const string s)
strings S = defarray(s)
series ret = 1
print ret -o # series is string-valued
series ser = foo("A")
print ser -o # series includes numerical obs.
I'm observing this unexpected behavior:
string test = sprintf("Hey \n ho \n ?")
eval strsplit(test) # 3-elem array, as expected
eval strsplit(test, sprintf("\n")) # only 2 elems!?
This is on the latest snapshot.