Why does the python svgpathtools library use complex numbers for points?

May 27, 2024 9:46 AM

The python SVG path tools library inputs and outputs points in the form x + yj [also known as complex(x,y)], which is to say a complex number with x as the real part and y as the imaginary. I've never seen any library do this. The only (far-fetched) explanation I can come up with is that they want to facilitate using complex number numpy arrays. Can someone lend me a clue?

(in a non-python environment the form would be x+yi.)

posted by Tell Me No Lies to Computers & Internet (7 answers total)

Total hat-talking from forgotten techniques, but… arbitrary images, Fourier transforms, amplitude&phase, complex numbers?
posted by clew at 10:11 AM on May 27

Using complex numbers means lots of things work nicer, eg rotation is a fiddly matrix transformation in R^2 but it's just multiplication in the field of complex numbers. See eg here for some examples. Scaling and translation, glide reflection etc are all formally more clear and concise in the complex plane. (This is basically why Hamilton really wanted to use his quaternions for all physics but it didn't work out as well as he hoped).
posted by SaltySalticid at 10:23 AM on May 27 [9 favorites]

You can see in the source that this is convenient sometimes for the implementation, in the way SaltSalticid mentions. Some people might also consider using complex numbers a more ergonomic interface once you're used to it, compared to a tuple representation which might be fiddly and easy to confuse with other uses of tuples in one's code, including function argument signatures.

in a non-python environment the form would be x+yi

It's not just Python where j is used to represent the square root of -1. Electrical engineers do it to avoid any confusion with i meaning current.
posted by grouse at 10:55 AM on May 27 [2 favorites]

all it's doing is SVG paths & Bezier curves; Runge's phenomenon may not be considered?
posted by HearHere at 10:59 AM on May 27

The main reason seems to be this:

Much of the core of this module was taken from the svg.path (v2.0) module. Interested svg.path users should see the compatibility notes at bottom of this readme.

svg.path's earliest code (from 2013) coerces CVG coordinates into Python Complex types. svgpathtools appeared three years later, but doesn't seem to be a formal fork of svg.path

While the notation looks weird at first, it's pretty compact and has many built-in routines that are useful instead of using endless bloody tuples.
posted by scruss at 4:24 PM on May 27

Response by poster: Thank you everyone for your suggestions. This definitely sheds light on the the topic.

Along the way I realized I had a more basic question of “Where did the idea of converting (X, Y) to X + Yj even come from?” and someone pointed out that when graphing complex numbers the real part is on the horizontal axis and the imaginary part is on the vertical axis.
posted by Tell Me No Lies at 7:41 AM on May 31

I still find it so weird that we conventionally put the (asymmetric) real axis on the horizontal and the (symmetric) imaginary axis on the vertical, when basically everything else our civilization designs prioritizes horizontal symmetry.
posted by Phssthpok at 10:42 AM on May 31