Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash in nmod_poly #124

Open
GiacomoPope opened this issue Feb 13, 2024 · 5 comments · May be fixed by #179
Open

Crash in nmod_poly #124

GiacomoPope opened this issue Feb 13, 2024 · 5 comments · May be fixed by #179

Comments

@GiacomoPope
Copy link
Contributor

For fmpz_mod_poly we get an error when we cannot compute an inverse when performing operations

>>> from flint import fmpz_mod_poly_ctx, fmpz_mod_poly
>>> R = fmpz_mod_poly_ctx(10)
>>> f = R([1,2,3])
>>> f
3*x^2 + 2*x + 1
>>> f % f
0
>>> g = R([3,1,2])
>>> g
2*x^2 + x + 3
>>> g % g
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "src/flint/types/fmpz_mod_poly.pyx", line 659, in flint.types.fmpz_mod_poly.fmpz_mod_poly.__mod__
  File "src/flint/types/fmpz_mod_poly.pyx", line 652, in flint.types.fmpz_mod_poly.fmpz_mod_poly._mod_
ValueError: Cannot compute remainder of 2*x^2 + x + 3 modulo 2*x^2 + x + 3

But for nmod_poly we get a crash:

Python 3.11.4 (main, Jul 25 2023, 17:07:07) [Clang 14.0.3 (clang-1403.0.22.14.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from flint import *
>>> f = nmod_poly([2,1,3], 10)
>>> f
3*x^2 + x + 2
>>> f % f
0
>>> f = nmod_poly([3, 1, 2], 10)
>>> f % f
Flint exception (Impossible inverse):
    Cannot invert modulo 2*5
zsh: abort      python3
@oscarbenjamin
Copy link
Collaborator

I think what is needed is to have contexts for nmod so that there is somewhere to store whether or not the modulus is prime. Then operations that are not well defined for composite moduli could be rejected.

@GiacomoPope
Copy link
Contributor Author

Yeah I agree. I think this would also help users simply because then different polynomial objects would be used in the same way.

@oscarbenjamin
Copy link
Collaborator

I can see potentially two different kinds of contexts. The low-level version is sort of what fmpz_mod_poly_ctx is except that it would be good to make it so that all objects have such a context and can quickly compare them in methods like __add__ or can quickly check for prime modulus.

A higher level version could be a user interface like:

R = Zmod(10)
n = R(5)
p = R.poly([1, 2, 1])
M = R.matrix([[1, 2], [3, 4]])
s = R.series(...)

Here the user does not need to create an fmpz_mod_poly_ctx explicitly. Perhaps Zmod should choose automatically between nmod and fmpz_mod.

I'm not sure if it would be better to have polynomial rings with distinct symbol names like

R.poly_ring('y')
R['y']
R['x']

Something like this would likely be needed for mpoly.

@GiacomoPope
Copy link
Contributor Author

Yeah, this would be really nice but reminds me more of the "level above" when you were talking about the goals and different ideas.

Here Zmod is more like a python (rather than cython?) interface which allows you to select and construct everything you want smartly from what python flint gives.

Whether we do:

K = Zmod(10)
f = K.poly([1,2,3])

or

K = Zmod(10)
R = PolynomialRing(K, 'x') # more like sage

Is another question I suppose.

@oscarbenjamin
Copy link
Collaborator

Yeah, this would be really nice but reminds me more of the "level above"

Yeah, I'm getting sidetracked.

We can just add an nmod_ctx type. I just mentioned the other things because I think that more broadly it would be better to have consistent handling of contexts for each of the types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants