Thanks, Greg, for looking more at this. Apologies I've not been able to
focus on this too much recently.
Yes, the approach above works, however the solvers also require a change so
that they don't unexpectedly solve for a permuted matrix. Additionally, a
getRank() method can now be implemented
Oooops, the * below should read MATH-630.
Chris
On 7 August 2011 13:28, Chris Nix chris@gmail.com wrote:
Thanks, Greg, for looking more at this. Apologies I've not been able to
focus on this too much recently.
Yes, the approach above works, however the solvers also require a
Chris,
In regard to the pivoting, do you think that it would be useful to allow
subclasses to pivot using other strategies? The pivoting I have looks for
the next column with the largest norm. For most garden variety problems this
will be okay. However, you can (I am not sure how effective this
To avoid having the strategy method being overriden in the constructor, we
could instead implement a constructor that takes a column Comparator that
determines if two columns should be exchanged at each stage.
In the interest of maintaining a clean interface, I don't know if this
constructor
Your selection methodology might be more complicated than pairwise
comparison. So I think you would have to pass the entire set of remaining
columns. That is an implementation detail, however.
On the interface, yes the public face should not expose the constructor
which takes the
Hello All,
Not sure if this is stepping on toes, but here is what I thought of to deal
with pivoting. I would only need to modify the constructor of the
QRDecompImpl class:
public QRDecompositionPivotImpl(RealMatrix matrix) {
final int m = matrix.getRowDimension();
final int n
On 7/22/11 11:40 AM, Greg Sterijevski wrote:
Sorry,
public ConstrainedOLSMultipleRegression extends OLSMultipleRegression{}
should read:
public ConstrainedOLSMultipleRegression extends OLSMultipleRegression{
@Override
public void newSampleData(double[] data, double[][]
I agree about refactoring, was just experimenting to see what sorts of
changes would need to be made in order to support restrictions. In the next
week or so, I will introduce yet another regression algorithm, the so-called
sweep algorithm. Once we have that, we will cover both normal equation
Chris, you had an algorithm in mind? -Greg
On Sat, Jul 23, 2011 at 11:29 AM, Phil Steitz phil.ste...@gmail.com wrote:
On 7/22/11 11:40 AM, Greg Sterijevski wrote:
Sorry,
public ConstrainedOLSMultipleRegression extends OLSMultipleRegression{}
should read:
public
We can do this with the current Householder reflection implementation,
except instead of just obtaining reflections from columns in sequence across
the input matrix, we select the column with the greatest L2-norm at each
iteration. The resulting permutation matrix is thus built and can be
Also, if the QRDecomposition interface *is* extended with getP, it is the
work of a moment to change it to an abstract class instead of an interface
and provide a default method for getP that throws
UnsupportedOperationException. Since there are very unlikely to be any user
extensions of
On 7/23/11 1:37 PM, Ted Dunning wrote:
Also, if the QRDecomposition interface *is* extended with getP, it is the
work of a moment to change it to an abstract class instead of an interface
and provide a default method for getP that throws
UnsupportedOperationException. Since there are very
I second +1.
On Sat, Jul 23, 2011 at 4:06 PM, Phil Steitz phil.ste...@gmail.com wrote:
On 7/23/11 1:37 PM, Ted Dunning wrote:
Also, if the QRDecomposition interface *is* extended with getP, it is the
work of a moment to change it to an abstract class instead of an
interface
and provide a
On 7/21/11 6:56 PM, Greg Sterijevski wrote:
If a pivoting QR decomp was to be included, I see it as existing in addition
to the current nonpivoting version. I don't see this as an addition to the
current QRDecompositionImpl. We would not be exposing more of the inner
workings of the
On the need for pivoting:
Here is my first approach for changing OLSMultipleRegression to do
constrained estimation:
public double[] calculateBeta(double[][] coeff, double[] rhs) {
if (rhs.length != coeff.length) {
throw new IllegalArgumentException();
}
Sorry,
public ConstrainedOLSMultipleRegression extends OLSMultipleRegression{}
should read:
public ConstrainedOLSMultipleRegression extends OLSMultipleRegression{
@Override
public void newSampleData(double[] data, double[][] coeff, double[] rhs,
int nob, int nvars) {
Looking at the current implementation, there is no column pivoting and so
the pivot matrix is the identity.
I have just written a small patch that does QR Decomposition with column
pivoting and has a getP() method to get the resulting permutation matrix.
If this is useful, I can open a JIRA
This is upside down.
Opening the JIRA and putting the patch up is the best way to determine if
this is useful.
On Thu, Jul 21, 2011 at 3:17 AM, Chris Nix chris@gmail.com wrote:
I have just written a small patch that does QR Decomposition with column
pivoting and has a getP() method to get
On 7/21/11 8:07 AM, Ted Dunning wrote:
This is upside down.
Opening the JIRA and putting the patch up is the best way to determine if
this is useful.
On Thu, Jul 21, 2011 at 3:17 AM, Chris Nix chris@gmail.com wrote:
I have just written a small patch that does QR Decomposition with
Sorry, did not mean to touch off a debate. There are two ways (that I know
of) to project linear restrictions through the data when running a
regression using the QR decomposition. I need to review my notes, but I
distinctly remember needing to get the pivots so that I know which columns
are
Also, pivoting is a good thing in a general QR decomposition since it
extends the applicability of the code to nearly rank deficient inputs.
On Thu, Jul 21, 2011 at 3:17 PM, Greg Sterijevski gsterijev...@gmail.comwrote:
Sorry, did not mean to touch off a debate. There are two ways (that I know
If a pivoting QR decomp was to be included, I see it as existing in addition
to the current nonpivoting version. I don't see this as an addition to the
current QRDecompositionImpl. We would not be exposing more of the inner
workings of the QRDecomposition, just a different view?
-Greg
On Thu,
Hello,
In attempting to build constrained ols into the OLSMultipleLinearRegression
class, I rediscovered the fact that to keep the regression coefficients in
their canonical order, I need to know how the QR decomposition pivoted. In
other words, while I get the correct constrained parameters,
Sounds like you need a new method.
It also sounds like the Q and R components of the decomposition (if
accessible) will be rendered in permuted order. Is there such an accessor?
If so, is the doc up to snuff on this caveat?
On Wed, Jul 20, 2011 at 9:27 PM, Greg Sterijevski
On 7/20/11 9:27 PM, Greg Sterijevski wrote:
Hello,
In attempting to build constrained ols into the OLSMultipleLinearRegression
class, I rediscovered the fact that to keep the regression coefficients in
their canonical order, I need to know how the QR decomposition pivoted. In
other words,
25 matches
Mail list logo
