Add Hermitian tag in variable macro

[blegat]

Requires #3292 to be merged first.

Another option is to reexport the symbol of LinearAlgebra.Hermitian and LinearAlgebra.Symmetric and to overload build_variable. I always felt it a bit annoying to ask to user to load LinearAlgebra intself to use the Symmetric symbol which is part of the JuMP syntax.
The issue is that it won't work if the user import JuMP because then Symmetric won't be in the scope so it would be breaking.

Closes #3291

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (fd1b2dc) 98.12% compared to head (27654e3) 98.12%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3293   +/-   ##
=======================================
  Coverage   98.12%   98.12%           
=======================================
  Files          34       34           
  Lines        4738     4750   +12     
=======================================
+ Hits         4649     4661   +12     
  Misses         89       89           

Impacted Files	Coverage Δ
src/macros.jl	98.60% <100.00%> (-0.01%)	⬇️

... and 3 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[odow]

Just merge this into one PR? Doesn't need to be separate.

[blegat]

Yes, but I was worried this one not reach consensus directly

[odow]

I think it should be possible to support the Hermitian tag, and also support LinearAlgebra.Hermitian as a positional argument?

[odow]

Thinking on this more, I understand arguments both for and against adding this. You could ask why Hermitian but not HermitianPSD or SkewSymmetric. Also H[1:2, 1:2] in HermitianMatrixSpace() isn't that much more complicated than H[1:2, 1:2], Hermitian, especially if people would try H[1:2, 1:2], LinearAlgebraHermitian.

You're right about the breaking stuff though. In JuMP 2.0, I'd make it Bool, Integer, LinearAlgebra.Symmetric, etc. Use the Julia types, don't detect symbols in the macro.

[blegat]

Yes, Especially SkewSymmetric. If the argument is that this is types that exists in Julia then the fact that we use the symbols makes it inconsistent. So if we add this, we would detect it by the symbol for consistency but the rule is still that we only detect symbols that correspond to actual types because in JuMP v2 we will not detect them as symbols anymore and

import JuMP
model = Model()
@variable(model, x[1:2, 1:2], Hermitian)

won't work anymore, but

using JuMP
model = Model()
h = Hermitian
@variable(model, x[1:2, 1:2], h)

will work in JuMP v2. We would make it work in JuMP v1 but in a separate PR that does it for all of them

[odow]

Agree. I'm ambivalent on adding this. How common are hermitians matrices? Not very? If so, asking for in HermitianMatrixSpace() isn't that much of an ask.

[araujoms]

Besides introducing an inconsistency in the syntax, the problem with HermitianMatrixSpace() is not that it's long, is that it's non-standard. Both Symmetric and Hermitian are not only the obvious thing to write, but also what the user already knows from LinearAlgebra. HermitianMatrixSpace() forces the uses to learn JuMP-only syntax, and it's not particularly easy to remember.

For comparison, YALMIP's syntax is x = sdpvar(d,d,'hermitian','complex') and CVX's is variable x(d,d) hermitian.

[odow]

Monthly call says go for this.

[odow]

@blegat how's this?

[blegat]

Looks good to me, we can merge