make variable category a kwarg

[chriscoey]

Referencing #740 and the discussion therein. I would like to be able to do the following:

@variable(m, x[j in 1:n], var_types[j])

Currently, I have to do:

@variable(m, x[j in 1:n])
for j in 1:n
    setcategory(x[j], var_types[j])
end

[mlubin]

This would look like:

@variable(m, x[j in 1:n], category = var_types[j])

[chriscoey]

Right, yes. That's what I meant.
💯

[joehuchette]

I can add this pretty easily in #736, I think

[mlubin]

@joehuchette if we do that we should add a deprecation for the old syntax as well

[joehuchette]

Why not allow both?

On Tue, Apr 26, 2016 at 2:13 PM, Miles Lubin notifications@github.com
wrote:

@joehuchette https://github.com/joehuchette if we do that we should add
a deprecation for the old syntax as well

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#741 (comment)

[mlubin]

Why allow both? :)

[mlubin]

When we rationalize all of the possible properties that you can set in @variable, it's not really consistent to use keyword arguments for everything except variable category, especially once we have a keyword argument for cone constraints.

[joehuchette]

Maybe not consistent, but it's still nice to be able to write @variable(m, 0 <= x <= 3, Int) like you can now.

[mlubin]

I don't know, I'd be okay with making that syntax go away in favor of consistency and less magic (e.g., leading people away from the natural assumption that you could do @variable(m, x[i=1:N], mycategory[i])).

[chriscoey]

Yeah like I did (oops).

We can't condense category to like cat can we? that would change setcategory to setcat too I guess.

🐱

[mlubin]

I think the abbreviation argument lost out with the macros. cat in particular isn't really self explanatory as an optimization term, it's JuMP terminology.

[joehuchette]

JuMP.set🐱(var, :Int)

[mlubin]

@variable(m, x, 🐱 = :Int)

[chriscoey]

yo let's write a new language that's all in emojis
📃(👋,🌎!)

[chkwon]

Can we just keep this format?

@variable(m, lb[i] <= x[i=1:N] <= ub[i], category[i]))

Why do we need category=? I guess, lower bound, upper bound, and category are the most important properties. If there is any other property is necessary for variable definition, it should come with other methods specific for those properties.

By the way, I'm a little bit skeptical about vectorized category input. How many times would we need it? In the world of MathProgBase as in linprog, we definitely need such vectorized input for x. But in AML like JuMP, usually same variable name goes with same variable category. If not, it is a bad choice of variable definition in the formulation stage after all, I believe. Any possible example?

[chkwon]

I have seen some changes in JuMP possibly related to this issue recently. I'm a little bit confused. In the future we won't be able to translate this math expression

x_ij >=0, Integers, i=1,..,n, j=1,..,m

to this julia expression?

@variable(m, x[i=1:n,j=1:m] >= 0, Int) 

Instead, will we need to make a vector input for both 0 and Int? I hope not.

[mlubin]

@chkwon, no, that's not changing. In the worst case we'll be changing Int to category=:Int, but not anytime soon and not without public discussion. For now we're focusing on extending the current syntax to make it easier to use in a programmatic way.

[chkwon]

@mlubin Thanks for the clarification! Peace of mind :)

[mlubin]

We need this as an optional syntax to support variable categories for anonymous variables.