FiniteField.__call__ returns different types depending on whether flint is installed or not about sympy

[oscarbenjamin]

I think it's suboptimal if the underlying backend used by sympy "leaks" out into the public sympy API, no?

This is already the case for other domains like ZZ:

In [1]: type(ZZ(1))
Out[1]: mpz

In [1]: type(ZZ(1))
Out[1]: flint.types.fmpz.fmpz

In [1]: type(ZZ(1))
Out[1]: int

Ultimately if we use types from gmpy2 and python-flint directly as domain elements then this is inevitable.

What should matter is that they are functionally equivalent.

I think this return call should wrap the result in a sympy type:

If you mean that this should dynamically create a class then I disagree. In fact I think that it is already a problem that dynamically created classes are used i.e. this should be changed:

sympy/sympy/polys/domains/modularinteger.py

Lines 226 to 228 in 8c94201

	class cls(ModularInteger):
	mod, dom, sym = _mod, _dom, _sym
	_parent = parent

The way that python-flint does it is better i.e. you have a type that has a modulus attribute and it has a two argument constructor.

[bjodah]

Yes, I agree that the dynamic class design is... weird (I never understood it). But whatever is returned (flint.types.nmod.nmod or something else), it would be nice if there is a well defined set of methods/attributes that can be used on the return value (otherwise consuming code will have to handle API-differences of the returned object in if isinstance(...) blocks).

[oscarbenjamin]

Domain elements should only be used in a context where you have the domain object and it is that domain object that provides a consistent interface:

In [2]: K = GF(2)

In [3]: K.of_type(K(1))
Out[3]: True

In [4]: K.to_sympy(K(1))
Out[4]: 1

In [5]: ZZ.convert_from(K(1), K)
Out[5]: 1

If you have the domain element but not the domain then you are not using the domains in the intended way. Code that is intended to operate on generic domain elements should not presume any interface of them beyond ring operations:

sympy/sympy/polys/matrices/_typing.py

Lines 7 to 16 in 8c94201

	class RingElement(Protocol):
	"""A ring element.
	Must support ``+``, ``-``, ``*``, ``**`` and ``-``.
	"""
	def __add__(self: T, other: T, /) -> T: ...
	def __sub__(self: T, other: T, /) -> T: ...
	def __mul__(self: T, other: T, /) -> T: ...
	def __pow__(self: T, other: int, /) -> T: ...
	def __neg__(self: T, /) -> T: ...

[oscarbenjamin]

Yes, I agree that the dynamic class design is... weird (I never understood it).

I think it is a micro-optimisation for arithmetic operations so that you can do:

def __add__(self, other):
    if type(self) == type(other):
        return self.new(self.val + other.val)

Otherwise it would be:

def __add__(self, other):
    if isinstance(other, ModularInteger) and self.modulus == other.modulus:
        return self.new(self.val + other.val, self.modulus)

I presume that at some point someone benchmarked this and found that the dynamically generated classes were slightly faster.

The same design ended up being used for GF, RR, CC, PolyElement, etc. It is also used in mpmath for mpfs with different contexts.

[bjodah]

Alright, I see, thank you for explaining this. Then perhaps there isn't a simple fix here. We could close this issue from my point of view.

[oscarbenjamin]

Okay, let's close this.