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

Error: stack overflow when solving linear system for different types #1418

Closed
andreasnoack opened this issue Oct 21, 2012 · 11 comments · Fixed by #1435
Closed

Error: stack overflow when solving linear system for different types #1418

andreasnoack opened this issue Oct 21, 2012 · 11 comments · Fixed by #1435
Labels
bug Indicates an unexpected problem or unintended behavior

Comments

@andreasnoack
Copy link
Member

I am puzzled by

randn(3,3)\complex(randn(3))
error: stack overflow

as I cannot understand why it is not returning a "no method" error.

@vtjnash
Copy link
Sponsor Member

vtjnash commented Oct 21, 2012

It looks like these two generic definitions are getting involved:

\(x,y) = y/x
(/)(A::StridedVecOrMat, B::StridedVecOrMat) = (B' \ A')'

(for your reference, found using which( \ , randn(3,3), complex(randn(3)) ) )

@andreasnoack
Copy link
Member Author

Thank you. In particular for pointing to which.

Is it right to have right division as the fall back behaviour for left division? I would think of it more as a special feature for numbers maybe. If it is right, I can fix the matrix devision to catch this issue.

@ViralBShah
Copy link
Member

Yes, we should really just implement this case by calling LAPACK, rather than depending on the fallback. It would also end up having better performance, due to avoiding the transpose.

While fixing this, it is also worthwhile to implement the various ldiv/rdiv transpose operators, by dispatching to LAPACK and avoiding the computation of the transposes.

A_ldiv_Bc
A_ldiv_Bt
Ac_ldiv_B
Ac_ldiv_Bc
At_ldiv_B
At_ldiv_Bt
A_rdiv_Bc
A_rdiv_Bt
Ac_rdiv_B
Ac_rdiv_Bc
At_rdiv_B
At_rdiv_Bt

@andreasnoack
Copy link
Member Author

I shall give it a try, but I would like to hear the argument for having (x::Any,y::Any)=x/y and not restricting it to (x::Number,y::Number)=x/y.

@vtjnash
Copy link
Sponsor Member

vtjnash commented Oct 22, 2012

Note that it is actually defined as x\y == y/x, which is true for all types by the definition of Julia's left division operator. (I made the same mistake when I first saw that definition and almost suggested the same thing)

@JeffBezanson
Copy link
Sponsor Member

The idea is that there is a set of "core operators" (sounds ilke something to document!) that are the minimal ones to implement, and other operators can be derived from those if necessary. / is a core operator, \ is not.

@andreasnoack
Copy link
Member Author

But is it necessary to have these core operators defined for Any? Maybe I do not get it, but I think that they are only core for number types. Could they be restricted to numbers?

@StefanKarpinski
Copy link
Sponsor Member

I think that is probably the right thing to do.

@ViralBShah
Copy link
Member

Yes, it does seem sensible to restrict to Number.

@johnmyleswhite
Copy link
Member

I think restricting this to Number is definitely the right way to go.

@andreasnoack
Copy link
Member Author

Pull request #1427 solves this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants