-
-
Notifications
You must be signed in to change notification settings - Fork 396
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
Fix #889 #891
Fix #889 #891
Conversation
Thanks for the PR! Should we be doing this though or should we move towards the built-in broadcast syntax? |
The issue with the broadcast syntax is that it does not preserve the sparsity
|
Is there an upstream discussion on this? |
The thing is that Do you think we should only support |
Yes, I'd say we shouldn't implement any magic for types that aren't directly created by JuMP. JuMP will never directly create a sparse matrix of variables. Mapping zero to zero is nonsensical in this case though, hope the broadcasting works when you have nonnumeric entries. |
If the JuliaLang pull request is merged as is, it will fail since it will do
|
Well that's an issue. Should we let them know? |
We could also define getvalue for AffineExpr |
IIRC that should already be defined. |
Oh I didn't write it correctly... What is going to be called is julia> getvalue(zero(Variable)) == zero(Variable)
false
julia> typeof(zero(Variable))
JuMP.GenericAffExpr{Float64,JuMP.Variable}
julia> typeof(getvalue(zero(Variable)))
Float64 The problem is that there is no method (==)(lhs::AffExpr,rhs) = (sum(abs(lhs.coeffs)) == 0) && (lhs.constant == rhs)
(==)(lhs,rhs::AffExpr) = rhs == lhs then we get julia> getvalue(zero(Variable)) == zero(Variable)
true |
Any reason not to merge this? |
I remove my objection. If you update the PR and get tests passing this is okay to merge. We'll revisit the use of broadcast syntax for everything in JuMP at a later point. |
Current coverage is 88.30% (diff: 72.00%)@@ master #891 diff @@
==========================================
Files 18 18
Lines 4403 4687 +284
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
+ Hits 3869 4139 +270
- Misses 534 548 +14
Partials 0 0
|
@@ -98,8 +98,8 @@ pushmeta!(x::JuMPContainer, sym::Symbol, val) = (x.meta[sym] = val) | |||
getmeta(x::JuMPContainer, sym::Symbol) = x.meta[sym] | |||
|
|||
# duck typing approach -- if eltype(innerArray) doesn't support accessor, will fail | |||
for accessor in (:getdual, :getlowerbound, :getupperbound) | |||
@eval $accessor(x::Union{JuMPContainer,Array}) = map($accessor,x) | |||
for accessor in (:getdual, :getlowerbound, :getupperbound, :getvalue) |
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.
Isn't getvalue(::JuMPContainer)
already explicitly defined somewhere else? There's a reason it's not on this list.
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.
That is an excellent question. I have updated the PR with a proposal to unify these accessors on JuMPContainer/AbstractArray
cd06733
to
89fe12f
Compare
Seems reasonable to me, but Travis has some pretty crazy-looking errors. |
Wouldn't it be more consistent with |
I would think so, yes.
On Wed, Dec 14, 2016 at 12:47 PM -0500, "Benoît Legat" <notifications@github.com> wrote:
Wouldn't it be more consistent with getvalue if getdual outputs a warning and a vector of NaN instead of throwing an error ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@blegat, if you tidy this up this week we can get it in for 0.15. |
@mlubin @joehuchette The PR is ready for review, the tests are passing for Julia v0.5 |
Thanks, @blegat! |
No description provided.