10:59 a.m.
Hi, there is a disconnect here somehow:
<console>
? m = ones(4,3)
? div = {1, 0.2, 5}
? X = m / div
Ungültiges Argument # = invalid arg
? eval m/ div
0,23810
0,23810
0,23810
0,23810
</console>
Given that as per the doc X should solve X*div = m, and div has dim 1x3,
m has dim 4x3, X having dim 4x1 seems OK. But obviously the result is
wrong and it's clear that in linear algebra terms there is no solution.
So what is eval doing there?
thanks
sven
2:44 p.m.
On Sat, Jan 14, 2023 at 5:59 AM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
Hi, there is a disconnect here somehow:
<console>
? m = ones(4,3)
? div = {1, 0.2, 5}
? X = m / div
Ungültiges Argument # = invalid arg
What version of gretl is giving you that error? I'm not seeing any error there.
? eval m/ div
0,23810
0,23810
0,23810
0,23810
</console>
But obviously the result is wrong and it's clear that in linear algebra terms there
is no solution. So what is eval doing there?
It's doing just what Matlab's mrdivide() does, namely, computing a
least squares solution in the non-square case. This point is not
documented in the matrix chapter of the Gretl User's Guide, something
that should be fixed.
Allin
5:47 p.m.
Am 14.01.2023 um 15:44 schrieb Cottrell, Allin:
On Sat, Jan 14, 2023 at 5:59 AM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
> <console>
>
> ? m = ones(4,3)
> ? div = {1, 0.2, 5}
> ? X = m / div
> Ungültiges Argument # = invalid arg
What version of gretl is giving you that error? I'm not seeing any error there.
Well, it's the recent snapshot on Windows from Jan 7th. (Calling itself
still 2022d-git, but that's a different and cosmetic matter.)
But obviously the result is wrong and it's clear that in linear
algebra terms there is no solution. So what is eval doing there?
It's doing just what Matlab's mrdivide() does, namely, computing a
least squares solution in the non-square case. This point is not
documented in the matrix chapter of the Gretl User's Guide, something
that should be fixed.
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.)
thanks
sven
6:37 p.m.
On Sat, Jan 14, 2023 at 12:48 PM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
Am 14.01.2023 um 15:44 schrieb Cottrell, Allin:
On Sat, Jan 14, 2023 at 5:59 AM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
<console>
? m = ones(4,3)
? div = {1, 0.2, 5}
? X = m / div
Ungültiges Argument # = invalid arg
What version of gretl is giving you that error? I'm not seeing any error there.
Well, it's the recent snapshot on Windows from Jan 7th.
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".
But obviously the result is wrong and it's clear that in linear
algebra terms there is no solution. So what is eval doing there?
It's doing just what Matlab's mrdivide() does, namely, computing a
least squares solution in the non-square case. This point is not
documented in the matrix chapter of the Gretl User's Guide, something
that should be fixed.
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.
One might say that enabling the least-squares solution via "/" is
redundant given the existence of mols(), but if it were not enabled
our right-division wouldn't work like other software such as Matlab,
and cross-compatibility is nice to have if it's not too hard to
arrange.
BTW the matrix chapter of the Guide (in git) now gives a fuller
account of right-division.
Allin
6:48 p.m.
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!
> 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.
One might say that enabling the least-squares solution via
"/" is
redundant given the existence of mols(), but if it were not enabled
our right-division wouldn't work like other software such as Matlab,
and cross-compatibility is nice to have if it's not too hard to
arrange.
I absolutely agree.
BTW the matrix chapter of the Guide (in git) now gives a fuller
account of right-division.
Much appreciated!
thanks
sven
7:07 p.m.
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
715
days inactive
715
days old
5 comments
2 participants
participants (2)
-
Cottrell, Allin -
Sven Schreiber