On Sat, Jan 14, 2023 at 1:48 PM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
Am 14.01.2023 um 19:37 schrieb Cottrell, Allin:
On Sat, Jan 14, 2023 at 12:48 PM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
...
I just tried the Jan 1 and Jan 10 Windows snapshots, in both English
and German, and saw no such error. I can't really believe in this
error without seeing a screenshot where the relevant commands are
prefaced by "clear".
OK, I explicitly uninstalled gretl and re-installed the same snapshot, and indeed the
error is gone. Perhaps there was some confusion across the scripts and the console. One
less thing to worry about!
Glad to hear it.
Right, OK. So what's actually recommended in those and similar
cases, using the mols() function or the "/" or "\" operators?
(Provided the residuals aren't wanted afterwards, which are only provided by mols.)
Is a recommendation really called for here? I mean, do as you please:
the results will be the same to machine precision.
I meant if some speed difference is to be expected, or if it's calling into the same
underlying BLAS routines anyway.
OK, I see. "/" calls QR decomposition, while mols() calls Cholesky
with a fallback to QR in case of near-perfect collinearity. So mols()
will be a bit faster unless the fallback is required.
<hansl>
A = ones(4,3)
B = {1, 0.2, 5}
set stopwatch
loop 10000
x = A / B
endloop
t1 = $stopwatch
Y = A'
X = B'
set stopwatch
loop 10000
b = mols(Y, X)
endloop
t2 = $stopwatch
printf "right-division %.3fs, mols %.3fs\n", t1, t2
</hansl>
Here I get: right-division 0.021s, mols 0.014s
Allin