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.

Sign up for GitHub

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

Jump to bottom

Narrow convert methods to reduce invalidations #172

Merged
merged 1 commit into from
Aug 17, 2021
Merged

Narrow convert methods to reduce invalidations #172

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions src/conversion.jl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -60,9 +60,8 @@ function Base.convert(::Type{T}, p::AbstractPolynomial) where T <: AbstractTermL
end

MA.scaling(p::AbstractPolynomialLike{T}) where {T} = convert(T, p)
Base.convert(::Type{Any}, p::APL) = p
# Conversion polynomial -> scalar
function Base.convert(S::Type{<:Union{Number, T}}, p::APL{T}) where T
function scalarize(::Type{S}, p::APL) where S
s = zero(S)
for t in terms(p)
if !isconstant(t)
Expand All @@ -73,5 +72,6 @@ function Base.convert(S::Type{<:Union{Number, T}}, p::APL{T}) where T
end
s
end
Base.convert(::Type{T}, p::APL) where T<:Number = scalarize(T, p)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this still cause some invalidations ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing serious, if memory serves. The real problem is totally-unconstrained T.

When fixing invalidations, usually I don't like to suggest restrictions on what packages can do (better to fix the code being invalidated). But convert is one of those rare functions that's used in a ton of places with poor inference on the 2nd argument, and it's often used to make inference better. Consequently it's bad to specialize only on the 2nd argument, since so many callers don't know what type their 2nd argument is. It's generally fine if you specialize on the first argument.

You can add more convert methods than this, I just gave one that is needed to pass tests. But keep in mind that the call site could also just call scalarize directly, and that would be the cleanest solution of all (just deleting this method altogether).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, thanks for the detailed explanation. I try to keep the same behavior independently of whether the coefficient is a number or not as the coefficient is for instance sometimes a JuMP expressions which is not a number. Therefore I might remove this convert and see what's break. Meanwhile I'll merge this PR. Thanks!


Base.convert(::Type{PT}, p::PT) where {PT<:APL} = p