Feature Request: Unicode comparison support.

[MichaelHatherly]

Recently JuliaLang/julia#6582 got merged adding support for the ≤ and ≥ operators. Would it be possible to add support for these in the JuMP macros? Currently I get the following results:

@defVar(m, 0 ≤ x ≤ 3) # Results in a "var not defined" error.
@addConstraint(m, x + 5y ≤ 3) # Works fine. Returns "x + 5 y <= 3".

So it's partially supported already it would seem – perhaps unintentionally though. Obviously this isn't urgent, but might be a nice feature some people would use. If it doesn't require massive changes to JuMP's internals then I'd be happy to try and add it myself.

PS Using JuMP is really intuitive and is a great example of what Julia can do. Thanks for all the work you guys have put into it.

[mlubin]

Yes, this should be pretty easy to properly support and will look pretty cool in the end.

[mlubin]

We can hopefully say that JuMP 0.5 is the last branch to support Julia 0.2. We might hold off on implementing this until we officially drop support for 0.2 in master, though.

[joehuchette]

Not sure why my comment seems to have been deleted, but I think it might actually be pretty straightforward to make it backwards compatible. We just need to add checks for the :≤ symbols and such:

julia> a = :(0 ≤ x)
:((0 ≤ x))

julia> a.head
:comparison

julia> a.args
3-element Array{Any,1}:
 0  
  :≤
  :x

julia> b = :(0 <= x)
:(0 <= x)

julia> b.head
:comparison

julia> b.args
3-element Array{Any,1}:
 0   
  :<=
  :x 

[mlubin]

We can reference the :≤ symbol in 0.2, but it can't actually be parsed as an operator:

julia> a = :(0 ≤ x)
ERROR: syntax: missing separator in tuple

[mlubin]

So the implementation itself will be compatible with 0.2, but any tests/examples we have won't work.

[joehuchette]

I'm fine with that since this will most likely be undocumented anyway.

[mlubin]

I think we should actually show off this syntax when we can.

[joehuchette]

Undocumented for now, at least. I have this done and will push assuming we can hold off on the evangelizing until 0.3 lands :)

[mlubin]

PR?

[mlubin]

If it doesn't require git magic.

[MichaelHatherly]

Oh cool. That was quick. Thanks @joehuchette, @mlubin. That PR looks about the same as what I was trying out :)

Not to be too demanding, but what are your thoughts on ≡ for == and Σ for sum?

[joehuchette]

I'm not crazy about ≡ because that seems to imply equality modulo something. I really like Σ and ∏ for sum and prod, though, and that should be pretty trivial to implement.

[MichaelHatherly]

Yeah, wasn't too sure about ≡. Just mentioned that one since it's equivalent to == in base now I think. Σ and ∏ would be great to have though.

[joehuchette]

It looks like it's an alias for ===, actually, which I think is a bit stronger than ==. It would be nice if there was a length-one (unicode?) character for equality, but I think that x+y = 1 is a little too perverse.

[mlubin]

I like Σ and ∏. Those will require some changes to ReverseDiffSparse. The length-one character for equality is = :). ≡ doesn't seem right.

[MichaelHatherly]

There's double hyphen [1] ＝. But that's probably an even worse idea than just using =.

[1] https://en.wikipedia.org/wiki/Double_hyphen

[joehuchette]

Yeah that'll just cause more confusion (I wonder if Julia canonizes it into = anyway).

Btw thanks for using JuMP and your feedback!

[MichaelHatherly]

Really great to have such an open development process. Thanks again.

[mlubin]

Fixed by #172/#174

[mlubin]

This will be in the 0.6 release of JuMP. To try it out, you can use the master branch with Pkg.checkout("JuMP").

[MichaelHatherly]

Works great. Might be worth mentioning in 0.6's release notes which sigma is used. I was using Σ (GREEK CAPITAL LETTER SIGMA) not ∑ (N-ARY SUMMATION). They look really similar in some fonts I tested. Obviously the summation symbol is the correct one to be using, but the difference might trip some people up at first.

[mlubin]

Oh, that's an annoying. Let's reopen the issue until we decide what to do about that (and also update the docs and examples)

[joehuchette]

We could just check for both, although I'm not sure if that's ideal.

[MichaelHatherly]

I'd have realized what was happening much quicker if the error message

error("Expected sum outside curly braces")

had suggested which symbol could be used. Something like:

error("Expected sum (or ∑) outside curly braces")

might be sufficient. Perhaps the hex value \u2211 as well.

[mlubin]

Unfortunately we have to be careful with printing unicode values from JuMP because they break the windows terminal.

[joehuchette]

We could use

error("Expected sum (or \u2211) outside curly braces")

but that's kind of ugly

[tkelman]

Can/should you canonicalize similar-looking unicode identifiers?

[mlubin]

I don't see the harm in allowing both Σ and ∑. Unless there are a number of other similar characters, it's probably easier to just explicitly check for these two than to deal with unicode normalization.

[MichaelHatherly]

That sounds like the nicest solution. There are a couple of bold and italic variants, but I doubt anyone will be trying to use those in practise.

[MichaelHatherly]

It looks like JuliaLang/julia@82e34b6 may have disallowed using ∑. I'm getting the following error now

julia> using JuMP
ERROR: syntax: invalid character "∑"
 in include at boot.jl:244 (repeats 2 times)
 in reload_path at loading.jl:152
 in _require at loading.jl:67
 in require at loading.jl:51
while loading /home/mike/.julia/v0.3/JuMP/src/macros.jl, in expression starting on line 40
while loading /home/mike/.julia/v0.3/JuMP/src/JuMP.jl, in expression starting on line 539

[IainNZ]

So the letter = bad, mathematical symbol = good?

[joehuchette]

But ∑ is classified as a Mathematical Operator by Unicode. If it was parsable as an operator in Julia, you could do :∑, and if it was classified as a valid identifier you could also do :∑. Right now I think it's living in some purgatory between the two.

[IainNZ]

Oh man I'm confused. Funny enough, PackageEvaluator detected this breaking another package last night: JuliaQuant/MarketTechnicals.jl#32

[joehuchette]

PackageEvaluator is going to be great in catching these subtle little changes in the language that end up breaking things.

[MichaelHatherly]

Oops, my description is a bit confusing reading it again now. Just to clarify Σ (GREEK CAPITAL LETTER SIGMA) works and ∑ (N-ARY SUMMATION) doesn't.

[joehuchette]

This should be fixed on master.

[mlubin]

Confirmed passing on travis now.

[mlubin]

Just updated NEWS, I think we can close this.