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 PivotStrategyComp
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 shoul
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 wi
Oooops, the * below should read MATH-630.
Chris
On 7 August 2011 13:28, Chris Nix 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 change so
> that t
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 m
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 =
I second +1.
On Sat, Jul 23, 2011 at 4:06 PM, Phil Steitz 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 default metho
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
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 QRDecompo
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
returned
Chris, you had an algorithm in mind? -Greg
On Sat, Jul 23, 2011 at 11:29 AM, Phil Steitz wrote:
> On 7/22/11 11:40 AM, Greg Sterijevski wrote:
> > Sorry,
> >
> > public ConstrainedOLSMultipleRegression extends OLSMultipleRegression{}
> >
> > should read:
> >
> > public ConstrainedOLSMultipleRegr
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
ba
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
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) {
adjus
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("");
}
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 QRDecom
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, Jul
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 wrote:
> Sorry, did not mean to touch off a debate. There are two ways (that I know
> of) to project linea
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 'conta
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 wrote:
>
>> I have just written a small patch that does QR Decomposition with column
>> pivot
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 wrote:
> I have just written a small patch that does QR Decomposition with column
> pivoting and has a getP() method to get the resulting per
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 issue
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 word
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 wrote:
> Is there an
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, thei
25 matches
Mail list logo
