[symfont] Autogenerating certain additional GreenPens dies

I’ve been using the MomentsPen printGreenPen() to generate some additional higher-order moments of interest. Although they’re never “pretty” to look at, I found at least one func that defeats either symfont or sympy when I try to solve it. I’m not sure if I’m doing something wrong, or it’s just undoable.

The tree with works-as-expected additions is here, if anybody cares to peruse: https://github.com/n8willis/fonttools/blob/moremoments/Lib/fontTools/pens/momentsPen.py , although it’s not particularly different. Basically, calling printGreenPen for some additional moment integrals, like

('momentXXXX', x**4),
('momentXXYY', x*x*y*y),
('momentPolar4', 2*x*x*y*y+x**4+y**4),

works fine, even if it takes a couple of minutes. But out of curiosity, I tried it on the 3rd-order-polar moment too; e.g.:

('momentPolar3', sp.sqrt(x**2+y**2)*(x**2+y**2)),

And it crashes the Jupyter kernel. Rewriting that func as ((x**2+y**2)**0.5)*(x**2+y**2)), Jupyter stays with us, but it eventually kills sympy with this:

PolynomialDivisionFailed: couldn't reduce degree in a polynomial division algorithm when dividing [-4.5035996273705e+15*p0[0]*p1[0]**36*p2[0]**27 + 1.35107988821115e+16*p0[0]*p1[0]**35*p2[0]**28 - 1.57625986957967e+16*p0[0]*p1[0]**34*p2[0]**29 + 1.57625986957967e+16*p0[0]*p1[0]**33*p2[0]**30 - 5.04403158265496e+17*p1[0]**37*p2[0]**27 + 1.77892185281135e+18*p1[0]**36*p2[0]**28 - 2.56705178760118e+18*p1[0]**35*p2[0]**29 + 2.72467777455915e+18*p1[0]**34*p2[0]**30 - 9.23237923610952e+17*p1[0]**33*p2[0]**31, -3.37769972052787e+15*p0[0]*p1[0]**37*p2[0]**26 + 9.00719925474099e+15*p0[0]*p1[0]**36*p2[0]**27 - 1.57625986957967e+16*p0[0]*p1[0]**35*p2[0]**28 - 1.97032483697459e+16*p0[0]*p1[0]**33*p2[0]**30 - 3.78302368699122e+17*p1[0]**38*p2[0]**26 + 1.20696470013529e+18*p1[0]**37*p2[0]**27 - 2.31034660884106e+18*p1[0]**36*p2[0]**28 + 9.11978924542525e+17*p1[0]**35*p2[0]**29 - 2.28557681089053e+18*p1[0]**34*p2[0]**30 + 1.16530640358212e+18*p1[0]**33*p2[0]**31, 1.57625986957967e+16*p0[0]*p1[0]**33*p2[0]**30 + 1.84422404740822e+18*p1[0]**34*p2[0]**30 - 9.39000522306748e+17*p1[0]**33*p2[0]**31, -7.88129934789837e+15*p0[0]*p1[0]**33*p2[0]**30 - 9.29993323052007e+17*p1[0]**34*p2[0]**30 + 4.71752060967059e+17*p1[0]**33*p2[0]**31, 2.25179981368525e+15*p0[0]*p1[0]**33*p2[0]**30 + 2.67964177828545e+17*p1[0]**34*p2[0]**30 - 1.35107988821115e+17*p1[0]**33*p2[0]**31, -281474976710656.0*p0[0]*p1[0]**33*p2[0]**30 - 3.37769972052787e+16*p1[0]**34*p2[0]**30 + 1.68884986026394e+16*p1[0]**33*p2[0]**31] by [0.0, 0.0, 0.0, 0.0, 0.0]. This can happen when it's not possible to detect zero in the coefficient domain. The domain of computation is RR[p0[0],p1[0],p2[0]]. Zero detection is guaranteed in this coefficient domain. This may indicate a bug in SymPy or the domain is user defined and doesn't implement zero detection properly.

I don’t need this moment; I wanted the 4th-polar one and tried the 3rd solely for the sake of comparison. But the error message from sympy suggests that it might be “zero detection” so I thought that might come back to symfont.

Maybe not a bug at all, though; my calculus brain isn’t quite in peak, pre-quarantine fighting shape, so I could be missing something. Gist is that this would be Green’s-Theoreming the double-integral of r^3(dA), with r = sqrt(x^2 + y^2) by Pythagoras… So int_int( (x^2+y^2)*sqrt(x^2+y^2) )(dA). Certainly nasty; maybe not even solvable under these conditions? I dunno…

[mghasemi]

sp.sqrt(x2+y2)*(x2+y2)

Okay so that itself is integratable:

In [6]: sp.integrate(sp.sqrt(x**2+y**2)*(x**2+y**2), (x, y))
Out[6]: 3*y**4*log(1 + sqrt(2))/8 + 7*sqrt(2)*y**4/8

but maybe not when plugged into Green Theorem.

@behdad The outcome is not exactly what you expect (see https://docs.sympy.org/latest/modules/integrals/integrals.html#sympy.integrals.integrals.integrate) The result should be a function in x and y. The proper way might be something like:

sp.integrate(sp.integrate(sp.sqrt(x**2+y**2)*(x**2+y**2), x), y)

The result is not an elementary function though (involves hypergeometric functions): https://www.wolframalpha.com/input/?i=integral+(y^2%2Bx^2)^(2%2F3)dxdy

Although the hypergeometric functions are well-studied and you might be able to work around their moments in a reasonable time.

@n8willis I think you are missing a few moments like the ones corresponding to x^2 y, x y^2 for moments of order 3 and the same for 4th order, e.g., x^2 y^2, x^3 y, etc.

[behdad]

Or just attach a stacktrace?