Add \angle as a unary and binary operator

[tshort]

Add's \angle (∠) as a unary and binary operator. My main use is for nicer entry of complex numbers in polar coordinates. Prior art for this includes the TI 89 and the HP 48 calculators. Both have angle buttons to help with entry of complex numbers.

Here is an example use:

julia> ∠(mag, degrees) = mag * exp(1.0im * degrees * π / 180)
∠ (generic function with 1 method)

julia> ∠(degrees) = exp(1.0im * degrees * π / 180)
∠ (generic function with 2 methods)

julia> ∠30
0.8660254037844387 + 0.49999999999999994im

julia> 2∠30
1.7320508075688774 + 0.9999999999999999im

The main downside of this PR is removal of this character for use in variables. There are other angle characters available, though.

[stevengj]

This seems somewhat reasonable to me. r∠θ seems to be relatively common electrical-engineering notation for complex numbers in polar form. It seems like it should have ^ precedence, not *, though.

I can't find any existing Julia packages that use ∠ right now, so it's unlikely to be breaking.

I'm less convinced that we should define the r∠θ notation in Base... the notation is not that common; it seems mostly restricted to elementary-level EE textbooks (at the "what is a complex number" level).

[stevengj]

(On a related note, I've often thought that it would be nice to parse ° as a postfix operator, so that e.g. 30° would turn into deg2rad(30).)

[stevengj]

See https://en.wikipedia.org/wiki/Angle_notation

[StefanKarpinski]

e.g. 30° would turn into deg2rad(30).

Or a quantity with Degree as its unit such that trig function and such know how to operate on it correctly.

[stevengj]

Or just define ° to be an irrational constant equal to π/180. That seems by far the simplest option.

(I always forget about the possibility of multiplying by juxtaposition.)

[StefanKarpinski]

We should have the syntax and let packages define it as the want to.

[stevengj]

@StefanKarpinski, you're referring to ∠?

There is the question of precedence. The advantage of giving it * precedence is that things like r ∠ 30° will work as expected if ° is defined as some kind of constant.

[TotalVerb]

It seems that * precedence makes most sense, because the syntax x ∠ y is short for x * exp(im * y).

[simonbyrne]

It doesn't directly affect this PR, but you should probably use sind/cosd as they do nice things like sind(30) == 0.5 and sind(180) == 0 (which is also an argument against having ° call deg2rad).

[tshort]

I didn't mean to mark this as WIP. I agree with @stevengj that definition of ∠ can be left to packages.

[StefanKarpinski]

@stevengj: I was referring to adding both ∠ and ° as syntaxes calling those names as functions. I think the ^ precedence makes sense. The way the operator is defined doesn't have much implication for what its precedence should be – the way it's used should determine the appropriate precedence.

[stevengj]

(I tend not to like having ° as an operator; there are too many cases where it seems useful to have as part of a variable name, like °C and °F.)

[tshort]

Any objections to including this?

[stevengj]

lgtm

[StefanKarpinski]

Shall we pull the trigger and merge this then?

[simonbyrne]

Lets do it.

I guess the downside is that it could break existing code (e.g. ∠ = 0.1), but unicode does classify it as an operator and not a symbol.

[StefanKarpinski]

Some uses wouldn't even break since symbols are just normal identifiers with some special parsing rules:

julia> let + = 1.5
           (+)^2
       end
2.25

Note that you need the parens around the + sign.

[oscardssmith]

Works in 1.6