octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #52685] redundant sentence in meansq docstring


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #52685] redundant sentence in meansq docstring
Date: Fri, 22 Dec 2017 23:33:11 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #17, bug #52685 (project octave):

No.  I made changes to the ols.m documentation, then turned to the gls.m
documentation.  But an example I tried--for which I aimed to follow the input
matrix size rules--results in an error:


octave:1> s = [0.5 1.0 1.5];
octave:2> B = [0.5 0 0.5; 0 0.5 0.5; 0 0 0.5];
octave:3> X = randn(1000,3) * [1 0 0; 0 2 0; 0 0 3];
octave:4> O = kron(eye(size(X,1)), diag(s)*diag(s));
octave:5> E = randn(size(X)) * diag(s);
octave:6> Y = X*B + E;
octave:7> % Doesn't work
octave:7> [BETA, SIGMA, R] = gls(Y,X,O);
error: gls: operator /: nonconformant arguments (op1 is 1x1, op2 is 1000x3)
error: called from
    gls at line 120 column 9
octave:7> % But this does
octave:7> [BETA] = gls(Y,X,O);
octave:8> BETA
BETA =

   0.4720146   0.0944968   0.5226161
  -0.0010677   0.5086855   0.4918207
   0.0047753   0.0108673   0.5057019


So I set this aside for a day or two.  If there's a bug, I will file a
separate bug report to keep bugs and fixes out of the voluminous documentation
changes.  However, I want to understand what the issue is first.  Another
question I have is why the O matrix is so big.  I understand it is accounting
for the correlation amongst error variables and across sample "time", i.e.,
heteroscedasticity, but the external literature on generalized least squares
typically considers the random variables having homoscedasticity.

Seeing the gls.m description makes me understand why the original author
wrote


## $\bar{e} = 0$, and cov(vec($e$)) = kron ($s, I$)


The kron(s,I) is like the big matrix O, but of course it is degenerate in the
sense it is homoscedastic and reduces to a simplified form, i.e., p-by-p.

The terminology is a bit confusing and I'm still trying to make some sense out
of the gls.m routine.  I suspect that gls.m might not get used much; ols.m
could get used though.  In summary, another changeset will be posted soon.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52685>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]