Add fmpq_mpoly.zpoly and fmpq_mpoly.zcontent (fixes #419)

[magv]

This fixes issue #419.

[magv]

Sorry for the force-push, I've added docstring tests to both functions.

[oscarbenjamin]

I guess zcontent isn't a good name for this if it is fmpq.

[oscarbenjamin]

Can you add your name and initial to the release note section I just added?

[oscarbenjamin]

Actually the PR number should be 421...

[oscarbenjamin]

Maybe it would be better to add content and primitive methods like with fmpz_mpoly. The difference would just be the sign when the zcontent is negative since content for fmpz_poly/fmpz_mpoly is nonnegative gcd. That would sometimes require negating the zpoly but presumably that is not much more expensive than making a copy anyway.

Compare to fmpz_mpoly the difference would also be that the primitive part is of a different type (fmpq_mpoly -> fmpz_mpoly) but maybe that is just to be expected here...

[magv]

What about content and zprimitive then? :)

[oscarbenjamin]

This version of content is not equivalent because of the sign:

In [13]: from flint import *

In [14]: Rz = fmpz_mpoly_ctx.get(['x', 'y'])

In [15]: Rq = fmpq_mpoly_ctx.get(['x', 'y'])

In [16]: xz, yz = Rz.gens()

In [17]: xq, yq = Rq.gens()

In [18]: (-xz).content()
Out[18]: 1

In [19]: (-xq).content()
Out[19]: -1

I think it would be good to have primitive and content with them being consistent with the same methods for fmpz_mpoly. Then primitive should actually return (fmpq, fmpq_mpoly) to stay in the ring.

So maybe it still makes sense to have separate methods for this kind of content that just gets the internal representation. Maybe zcontent and zpoly are fine. At least the names show that they go together.

[magv]

I've renamed it. The naming inconsistency really comes from the underlying FLINT API. As long as python-flint stays a relatively thin wrapper, it will show up one way or another.

[oscarbenjamin]

FLINT has these two functions:

  fmpq_mpoly_content_ref
  fmpq_mpoly_content

The first is for accessing the struct member and the second is for computing the mathematical content. They can differ by a minus sign. I agree that is a confusing naming convention but that's why it is important to consider names of things in the first place.

I think that zcontent and zprimitive are fine as long as the names are clearly distinct from .content() and .primitive() as used elsewhere.

[oscarbenjamin]

I've renamed it from zprimitive back to zpoly. I think that zpoly matches the struct method name so someone familiar with the FLINT struct can find it. Maybe zcontent is misleading but the two method names match so it is clear that they go together. I think that's the best we can do here.

[oscarbenjamin]

Okay, looks good. Thanks