Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(feature?) More flexible inner products #170

Closed
ghost opened this issue Apr 26, 2017 · 2 comments
Closed

(feature?) More flexible inner products #170

ghost opened this issue Apr 26, 2017 · 2 comments

Comments

@ghost
Copy link

ghost commented Apr 26, 2017

Consider the following equation, where uppercase boldface letters are matrices and lowercase boldface letters are vectors, and everything else is a scalar:

bilinear form

The equation is written using the usual vector calculus convention of column-major vectors, so, reading from left to right, in pseudocode:

  1. Inner product (from left) of matrix and vector, yielding a vector
  2. Bilinear form in parentheses: one vector/matrix multiplication yielding a vector, followed by inner product with another vector, yielding a scalar to be inverted
  3. Multiplication of vector and scalar

Is this possible in rulinalg right now? I tried switching the order of vector/matrix products since it is row-major, but it doesn't look like Mul is implemented for all of the permutations of vector and matrix.

@Andlon
Copy link
Collaborator

Andlon commented Apr 26, 2017

What about the following? Bear in mind I haven't actually tried it, but I believe it should work, barring any details I haven't considered.

let xTPx = x.dot(&(P * &x));
let g = P * x / (lambda + xTPx);

This is not completely optimal, because to compute P * &x, rulinalg effectively clones the vector x. It is possible to compute the quadratic form by directly computing the scalar quantity, without needing to store an additional vector. However, unless this extra allocation is demonstratively a problem in your application you probably don't need to care.

Note also that P * x will be computed in-place (I think? It should, at least), but then of course you wouldn't be able to use x in subsequent computations, which is why we must compute P * &x instead. EDIT: Didn't think this one through. It cannot be computed in-place, so a vector will always be allocated.

Hope this helps! Let me know if it's not what you're looking for :-)

@Andlon
Copy link
Collaborator

Andlon commented May 8, 2017

@bright-star: I'm closing this issue because I don't see anything more we should do here. Please let me know if I misunderstand and that there is more that we should do with respect to this issue!

@Andlon Andlon closed this as completed May 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant