-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
separate LU economy mode #272
Comments
There are various forms of LU with various input combinations:
It would be inelegant to have differently named functions for each case. We certainly can ensure that the names are prefixes of each other, and that can be done in the case of existing lu also. |
It's not as bad as you make it look. 4 is not necessary since the P vector can be turned into a matrix in an extra step. 2 and 3 can be the same function. 5 would be a separate method anyway since it is for sparse. So that really still leaves you with two functions for the dense case. |
* 'master' of github.com:JuliaLang/julia: Working sparse \ small fix to suitesparse build. Build SuiteSparse. Still need to resolve LAPACK symbols. Use lu! for economy mode. No economy argument to lu any more. lu is implemented using lu! Close JuliaLang#272. Specialize the conversion for integer arrays as the real case led to stack overflow in the earlier commit. Promote all non-float arrays to float for lapack function calls (both real and complex cases) Fix bug in calling complex qr close JuliaLang#134 ode23 is quite decent. ode45 seems ok, but may need some code cleanup and performance testing. Both need a few more function signatures - but good enough to get started. Implement select(k) using quickselect Separate stats stuff into statistics.j Implement median using select Almost working quickselect that will pave the way for median and order statistics.
* fix some printing inconsistencies
* fix some printing inconsistencies
* Array shouldn't be parameterised on T and change from sample! to sample * Add simple tests for weighted sampling with a dimension
Currently we can't infer a simple type for the result of
lu
since it might return either (LU, P) or (L, U, P).I'm willing to give in on this in some cases, but this one doesn't seem necessary. Especially since
lu(A, true)
is not very easy to read. Yes, a keyword argument would be best but that still probably won't fix the type issue.We need something like
lu_compact
orlu_econ
.Similar concerns might apply to other linear algebra functions. But it's much better if the various possible returns are prefixes of each other, i.e.
(A,B)
,(A,B,C)
,(A,B,C,D)
etc. so we always know the types of values that are requested.The text was updated successfully, but these errors were encountered: