Variables versus variable indices

videlec commented 1 year ago

Is there an existing issue for this?

[X] I have searched the existing issues for a bug report that matches the one I want to file, without success.

Problem Description

The variables in a polynomial ring are conveniently indexed by 0, 1, ..., n-1 and one would like to use these indices rather than variables (or variable names) in algorithms. However getting access to this indexing is currently cumbersome and inefficient

sage: R.<x, y, z> = QQ[]
sage: R.gens().index(y)
1

Proposed Solution

We propose to implement two new methods on elements of a category with an (indexed) basis

Object.is_gen(): return whether the Object is a generator. This method is already available on univariate polynomials. We propose to additionally deprecate MultivariatePolynomial.is_generator() in favor of is_gen.
Object.gen_index(): return the index of the generator if Object is a generator and raises a ValueError otherwise.

We additionally propose to implement a method on all (multivariate) polynomials

Polynomial.variable_indices() : list of indices of variables occurring in the polynomial (similar to Polynomial.variables())

One should check for consistency on objects that already have their own conventions (such as symmetric functions, infinite polynomial ring, polynomials, multivariate polynomials, ...)

Alternatives Considered

None

Additional Information

This came out from a discussion relative to PolynomialSequence in #35518

mkoeppe commented 1 year ago

+1, and while at it, should also fix this inconsistency between Polynomial and MPolynomial:

sage: R.<x> = QQ[]
sage: x.is_gen()
True
sage: x.is_generator()
AttributeError: 'sage.rings.polynomial.polynomial_rational_flint.Polynomial_rational_flint' object has no attribute 'is_generator'

sage: R.<y,z> = QQ[]
sage: y.is_gen()
AttributeError: 'sage.rings.polynomial.multi_polynomial_libsingular.MPolynomial_libsingular' object has no attribute 'is_gen'
sage: y.is_generator()
True

mkoeppe commented 1 year ago

What should these methods do for elements of InfinitePolynomialRing?

mkoeppe commented 1 year ago

gen_index and is_gen[_erator] could probably be defined more generally in CategoryObject, where stuff like gens_dict is defined

videlec commented 1 year ago

+1, and while at it, should also fix this inconsistency between Polynomial and MPolynomial:

sage: R.<x> = QQ[]
sage: x.is_gen()
True
sage: x.is_generator()
AttributeError: 'sage.rings.polynomial.polynomial_rational_flint.Polynomial_rational_flint' object has no attribute 'is_generator'

sage: R.<y,z> = QQ[]
sage: y.is_gen()
AttributeError: 'sage.rings.polynomial.multi_polynomial_libsingular.MPolynomial_libsingular' object has no attribute 'is_gen'
sage: y.is_generator()
True

Good idea! Do you have a preference between deprecated one in favor of the other? keeping both?

videlec commented 1 year ago

What should these methods do for elements of InfinitePolynomialRing?

What would be a problem with InfinitePolynomialRing? Its elements are finite sums of monomials.

mkoeppe commented 1 year ago

From a quick git grep, I think is_gen should be preferred as it matches ngens etc. The full spelling seems to be mostly used when an extra qualifier is present, such as ring_generators, module_generators, algebra_generators.

mkoeppe commented 1 year ago

What would be a problem with InfinitePolynomialRing? Its elements are finite sums of monomials.

Yes, but:

sage: R.<x,y> = InfinitePolynomialRing(QQ)
sage: R.gens()
(x_*, y_*)
sage: R.ngens()
2

mantepse commented 10 months ago

I use InfinitePolynomialRing quite a bit now in the lazy power series code, and it seems to me that it is a bad idea that it abuses gens. See, for example, #36576.

I'd be in favour of removing this inconsistency, see https://groups.google.com/g/sage-devel/c/-CVdz6H7dTc/m/_x1px4bHAgAJ and #34120

sagemath / sage