allow more of the newly named functions to take vector arguments

[chriscoey]

So I would never know which of the functions like getvalue, setvalue, setlowerbound etc take single variables and which can take vectors. getvalue will take a vector, setlowerbound doesnt. setvalue, i actually forget, and the docs don't help.

So currently i'm writing things like

    @variable(mip_model, x_orig[j in 1:num_vars_orig])
    for j in inds_bint
        setcategory(x_orig[j], m.types_var_orig[j])
    end

And
map((ind -> setupperbound(x_orig[ind], 0.)), inds_cone)

That's not a big deal that I have to write extra, but what bothers me is that if some of these functions take vectors, why don't all of them?

[chriscoey]

Related to the first example I gave, and maybe a separate issue that I can file, it would be better if I could do this:

    @variable(mip_model, x_orig[j in 1:num_vars_orig], m.types_var_orig[j])

But as @mlubin has told me, this doesn't work. I guess the scope of the j index goes to lower and upper bounds, but not to variable type?

[mlubin]

if some of these functions take vectors, why don't all of them?

Because nobody was bothered enough to implement them. JuMP never claimed to be feature complete

[chriscoey]

it was a half-rhetoric question haha

[mlubin]

it would be better if I could do this

That's not how @variable works, see the discussion at #105

[chriscoey]

OK, yes @variable confuses me sometimes.

Is this related to #736 at all? Like I guess I assumed that it allows us to use the j index in kwargs? (There aren't examples yet so I don't know).

[mlubin]

You can use the index j in kwargs. Variable categories aren't kwargs though (they will be at some point in the future).

[chriscoey]

so should I submit a second issue for making variable categories kwargs? it's different from this issue about vector arguments

[mlubin]

Sure, it's on the roadmap though

[chriscoey]

is it a big change? given that we are changing names, functions a lot in the next version, maybe it should go in there? Better to change a lot of things at once and ask people to update their code once

[mlubin]

I'm not in favor of rushing to stuff the next release with features given the deadlines and everyone being busy. Right now all the updates we're asking people to do are find/replace changes, and there's a big mental hurdle to ask people to start changing syntax, so I'm not convinced of the benefit of doing it all at once anyway.

[chriscoey]

That makes sense. Find and replace is different to changing arguments.

[chriscoey]

hey @joehuchette @IainNZ , thoughts on this one? is it tough? can it make it into this new version?

[joehuchette]

Which vectorized methods would you like to see added, specifically? I'm alright adding something like setcategory(::Array{Variable},::Array{Symbol}).

[chriscoey]

So how about any of these variable get/set functions that aren't vectorized yet: setname, getname, setlowerbound, setupperbound, getlowerbound, getupperbound, getvalue, setvalue, getdual, setcategory, getcategory, getvariable?

[mlubin]

Go for it, except vectorized getvariable doesn't make sense. getvalue and setvalue are already implemented in JuMP.jl.

[IainNZ]

getvariable - probably not that one!

I definitely see the point. What happens with things indexed by 0:10 or random keys, e.g.

@variable(m, x[-5:5])
setvalue(x, ?)

[mlubin]

We could allow only a broadcasting version in that case, e.g., setvalue(x, -1), but I'm not sure that's the case that @chriscoey cares about.

[joehuchette]

Yes, I'm (much) less OK adding something like setvalue(::JuMPArray, ::Any).

[chriscoey]

the Julia dot syntax should work sometimes, but maybe not for JuMPContainers. so we should test that

[chriscoey]

@mlubin said we may drop 0.5 next week-ish. so this code could be moved to JuMP then