I’m pleased to announce updates to two packages and a new third one for working in the complex plane:
ComplexValues (update), which defines polar and spherical representations of complex numbers;
ComplexRegions (update), which defines tools for working with curves, paths, and regions in the complex plane; and
ComplexPlots (new), which provides for plots on the Riemann sphere and using phase/amplitude coloring.
For example,
z = [complex(2cospi(t), 0.5sinpi(t)) for t in (0:400) / 200]
plot(Spherical.(z), l=3, label="ellipse")
plot!(Spherical(Line(0, 1im)), l=3, label="line")
The last of these quite accidentally overlaps with the recent beautiful DomainColoring package. The latter has a few more features, but ComplexPlots works with Plots.jl as well as with Makie,jl.
It looks like you use the complex number type to dispatch with plot. Wouldn’t it be nice to accept an ordinary Complex array and then simply have different plot functions (polarplot etc), or different keyword arguments? Why require users to convert their complex arrays to new types just to plot them differently?
Another point of view is that I just want to plot a thing in whatever way is most natural for the thing, rather than having to remember new commands or keywords. The real answer is that I was thinking about the types themselves before I thought about how to plot them, so this came about as a natural progression in Plots.
I would not object to having dedicated plot command names. For Makie that route is actually much easier to implement, since recipes don’t seem to allow manipulating the axes or figures. I guess then you offend the “only one way to do things” crowd, though.
Always nice to see other people are working on complex visualisations as well (author of DomainColoring here)!
The type first approach is interesting to see, and as it’s all Plots.jl/Makie (thanks to ComplexPlots for helping me figure out how to support both) in the background, our packages seem to interoperate quite nicely. Cool stuff
