mod(::Complex{<:Integer}, ::Integer) and div etc.

[stevengj]

As discussed on discourse, this seems like the only sensible definition:

mod(z::Complex{<:Integer}, n::Integer) = Complex(mod(real(z), n), mod(imag(z), n))

and similarly for div, rem (and probably divrem).

Should be easy to create a patch (much simpler than #35374): just add the 1-line definitions analogous to the one above, docs, news, and a test.

[chakravala]

I disagree, I think it should be

mod(z::Complex, n) = Complex(mod(real(z), n), mod(imag(z), n))

Since this defines mod recursively, you can just let mod of a Real coefficient to handle the dispatch

[stevengj]

Yes, that's a reasonable further generalization, although I would be more conservative and restrict it to

mod(z::Complex, n::Real) = ...

If n is not real, then splitting the computation into real and imaginary parts makes less sense (especially since Complex(a,b) expects real arguments).

[chakravala]

Edit: sorry I was mistaken in my last post.

I don't quite see the argument for restricting the dispatch though, if it errors, then it errors, why restrict the dispatch?

And why is Complex(1+im,1-im) not allowed? Nested complex numbers are quite reasonable.

[stevengj]

The problem with dispatching to something that is unlikely to ever be implemented is that the error message is needlessly confusing, both to users and to future implementors — if we want to support mod(::Complex, ::Complex), we will add that method (ala #35374), opposed to implementing mod(::Real, ::Complex).

As for generalizing the Complex constructor, that's a better subject for a separate issue.

[stevengj]

Also, if n is not real, the return value is not necessarily Complex. For example, if n is a quaternion then the return value would not be Complex.

[prithvitewatia]

Hello @stevengj @chakravala. I would like to work on this issue. Can you please guide me? I have been using Julia for quite some time but this is the first time I decided to contribute.

[stevengj]

@prithvitewatia, welcome!

Basically you just need to add a 1-line definition similar to the one discussed above, e.g. mod(z::Complex, n::Real) = Complex(mod(real(z), n), mod(imag(z), n)), to base/complex.jl, and also add a test and update NEWS.md, and then submit a PR.

See also https://github.com/JuliaLang/julia/blob/master/CONTRIBUTING.md

[mcabbott]

Is this the obvious definition? I would have guessed that it was this:

mod(z::Complex, n::Real) = Complex(mod(real(z), n), imag(z))

That is, perform one identification on the complex plane, equating z and z+n. Performing two identifications, the second of which rotates n to lie in the imaginary direction, z ~ z + im * n, seems a strange choice to me. What's the logic?

For example, I would expect mod(z, 2pi*im) to leave the real part alone, and identify only in the imaginary direction. This maps you to the fundamental domain of exp. A similar rotation to identify also z ~ z + 2pi in the real direction would be surprising.

[prithvitewatia]

@mcabbott I am sorry but I am not able to understand your point. Could you please provide some more examples?

[mcabbott]

Sure, I can try.

Ordinary trig functions are periodic on the real line, e.g. tand(5) == tand(5 + 180) == tand(5 + 2*180), and this fact is captured by mod(5, 180) == mod(5 + 180, 180): the function x -> mod(x, 180) standardises the argument, making the function one-to-one.

This periodicity still exists in the complex plane: tand(5+7im) ≈ tand(5+7im + 180). The step here is still in the real direction. There is no extra periodicity in the imaginary direction, there is nothing special at all about tand(5+7im + 180im). If mod is still going to capture this behaviour, then mod(x, 180) needs to act only on the real part.

Other functions can have periods in other directions, e.g. f(x) = tand((1+im) * x) obeys f(17) ≈ f(17 + 90*(1-im)). And other functions can be periodic in both real and imaginary directions (e.g. Jacobi trig). But even then, there's little reason to think the period would be the same in the real and imaginary directions (rather than independent parameters).

Now maybe there are other uses of complex mod which I haven't thought of. But the linked discourse thread doesn't mention any.

[prithvitewatia]

@mcabbott Thanks for the explanation, now I get your point. But now I am confused about which implementation we should have.
This is because WolframAlpha uses mod(z::complex,n::Real)=Complex(mod(real(z),n),mod(imag(z),n)) whereas languages such as Python and Octave do not support complex types for modulo operator or function.

[mcabbott]

I didn't think to look, but here's what Mathematica does:

Mod[5+I,10]
Mod[6+I,10] (* real output in -5 to 5, although Mod[6, 10] == 6 *)
Mod[15+I,10]
Mod[16+I,10]

Out[175]= 5+I
Out[176]= -4+I
Out[177]= -5+I
Out[178]= -4+I

Mod[3+8I,10]
Mod[3+18I,10]
Mod[3+25I,10] (* imaginary output in -5 to 5 *)

Out[182]= 3-2 I
Out[183]= 3-2 I
Out[184]= 3+5 I

I think they are getting this from the equivalent of div, help says this:

Mod[m,n] is equivalent to m-n Quotient[m,n]. 
Mod works with complex numbers, using its definition in terms of Quotient.
Quotient[m,n] is equivalent to Floor[m/n] for integers m and n. 

but doesn't seem to say much about non-integer m,n. The behaviour is:

Quotient[5, 10]
Quotient[25, 10]

Out[143]= 0
Out[144]= 2

Quotient[14+2I, 10]
Quotient[14+22I, 10]
Quotient[14+22I, 10I]

Out[154]= 1
Out[155]= 1+2 I
Out[156]= 2-I

Floor[3/2 + 5I/2]
Floor[-3/2 - 5I/2]  (* rounds down *)

Out[188]= 1+2 I
Out[189]= -2-3 I

Quotient[14+22I, 1+2I]  (* rounds to nearest? *)
(14+22I)/( 1+2I) // N
Floor[11.6` -1.2` I]

Out[173]= 12-I
Out[174]= 11.6 -1.2 I
Out[175]= 11-2 I

Note that in Julia, floor(1+im) and div(1+im,2) are errors.