-
-
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
Redesign of triangular matrix types #9779
Conversation
a69be74
to
b3c1c82
Compare
I think I'd prefer |
Yes. That is probably better. |
That does sound better. |
…nal specification by parameters. This fixes #9191, type instability of \ for BlasFloat types when no promotion is necessary.
b3c1c82
to
e642034
Compare
Redesign of triangular matrix types
This will break a lot of packages. Would be very helpful to create an entry in |
Here are the ones that PackageEval found: |
Some rules can be bent. JuliaLang#9803 Others can be broken. JuliaLang#9779
Some rules can be bent. JuliaLang#9803 Others can be broken. JuliaLang#9779
Formatting error in doc change fixed in e98b817 |
Yep---I'd be all for support in Compat.jl for backward compatibility. |
@andreasnoack Would it make sense to export AbstractTriangular, this would make compatibility somewhat easier? I think I can resolve the references to Triangular in NamedArrays by replacing them by AbstractTriangular. Now I have my own if VERSION < v"0.4.0-dev"
typealias AbstractTriangular Triangular
else
import Base.LinAlg.AbstractTriangular
end |
Instead of using parameters to specify if a triangular matrix is upper, lower and/or has unit diagonal I have decided to write out the four possibilities as types as suggested some time ago by @StefanKarpinski. The four types are
UpperTriangular
,LowerTriangular
,UpperTriangularUnit
,LowerTriangularUnit
, and right now I have only exported the first two as the last two are probably less used.The main reason for this change is that the use of parameters makes it cumbersome to work with the types in a way the compiler understands because the type parameters aren't types (
:L
,:U
,true
,false
). The newVal
type would solve this, but I think it is ugly to writeTriangular(A, Val{:L})
compared to simplyLowerTriangular
and as we don't plan to extend the value beyond:L
,:U
,true
andfalse
, the type parameters give us nothing.The problems with writing the old
Triangular
types in a way the compiler understands caused\
to have inferred return typeAny
for the performance critical case where both left and right hand side has the sameBlasFloat
elements as reported in #9191. This PR fixes #9191 and supersedes #9196.cc: @jiahao