-
-
Notifications
You must be signed in to change notification settings - Fork 391
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
disallow colons in variable index sets #782
Conversation
Current coverage is 86.65%@@ master #782 diff @@
==========================================
Files 18 18
Lines 4047 4052 +5
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
+ Hits 3506 3511 +5
Misses 541 541
Partials 0 0
|
Why make this a generated function? |
This way the check gets lifted to compile time in most cases. |
Only in the case with well-typed index sets, where the compiler should be On Thu, Jun 2, 2016 at 2:35 AM, Miles Lubin notifications@github.com
|
What are you proposing instead, and why would it be faster than generated functions? |
Pathological case: using JuMP
type Foo{T} end
N = 100
I = [Foo{T} for T in 1:N]
m = Model()
@time @variable(m, x[I,I;true]) First run (i.e. compile time) takes 16 seconds on this branch and 0.5 seconds on master (this is on v0.5; v0.4 is much slower for both). Just make it a runtime check: function coloncheck(args...)
if any(t -> isa(t,Colon), args)
return error("Colons not allowed as keys in JuMP containers.")
else
return nothing
end
end This gives roughly the same performance as current master. |
How about this version? |
LGTM |
Did you check for regressions? |
No regressions on my example case. |
I feel like there's a mental block on the indexing with colon issue, hopefully this pushes us forward. Letting people index with colons as keys just seems like a terrible idea in any case, given the syntax confusion.
We can even merge and let it hang around for a release before we implement slicing.
Ref #643