-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
more efficient muladd for complex/real operations #15980
Conversation
Here's an oddity. If I do Clearly, the optimizer is doing the right thing at the end, as indicated by |
bacc7fe
to
413ffc7
Compare
muladd(z::Complex, x::Real, y::Real) = Complex(muladd(real(z),x,y), imag(z)*x) | ||
muladd(z::Complex, x::Real, w::Complex) = | ||
Complex(muladd(real(z),x,real(w)), muladd(imag(z),x,imag(w))) | ||
muladd(x::Real, y::Real, z::Complex) = Complex(muladd(x,y,real(z)), imag(z)) |
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.
This leaves out the case (Complex, Complex, Real)
. Is this intentional? If so, a comment might make sense.
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.
Yes, it was intentional. All of the benefit from the muladd(Complex, Complex, Real)
case could be gained by using muladd
in Complex*Complex
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.
Wouldn't this save one addition?
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.
Added a comment.
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.
@eschnett, no, because there is already an addition in both the real and imaginary parts of Complex*Complex
that could be fused with one of the multiplications.
Oh wait, you're right; you could save an extra addition.
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.
Okay, added the Complex*Complex
cases
413ffc7
to
0794ba7
Compare
0794ba7
to
c833e8e
Compare
@@ -904,6 +904,11 @@ end | |||
# issue #10926 | |||
@test typeof(π - 1im) == Complex{Float64} | |||
|
|||
# issue #15969: specialized muladd for complex types | |||
for x in (3, 3+13im), y in (2, 2+7im), z in (5, 5+11im) | |||
@test muladd(x,y,z) == x*y + z |
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.
should probably be ===
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.
They are Complex{Int}
values, so what does it matter?
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.
to test that the return type stays that way
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.
Ah, I see.
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.
Fixed in de6468b
Fixes #15969, and corrects some efficiency problems in
@evalpoly
introduced in #9881.