-
-
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
matmul: don't assume the existence of type-conversions #14293
Conversation
(*)(x::RootInt, y::RootInt) = x.i*y.i | ||
promote_op(::Base.MulFun, ::Type{RootInt}, ::Type{RootInt}) = Int | ||
|
||
a = [RootInt(3)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
put these in a let
or give them issue-number-specific names
nevermind guess it isn't necessary here, the same file is already using these names above
matmul: don't assume the existence of type-conversions
A_mul_Bt!(C, a, a) | ||
@test C[1] == 9 | ||
a = [RootInt(2),RootInt(10)] | ||
@test a*a' == [4 20; 20 100] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder how this passed without defining zero(::Type{RootInt})
?
oh right this also depends on #13803
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to backport this, we could add that method (for use by the test).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
without the promote_op
changes I don't think this will work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been playing around with number types whose product is a real number but for which I cannot define a conversion to Reals. This fixes a bug in our algorithm for matrix multiplication.