Pass number of variables to var

[mforets]

Extend the functionality of var by allowing to specify the number of variables:

sage: var('x', 4)
(x0, x1, x2, x3)

This ticket is a follow-up of #22809. It is related to #11576.

CC: @nbruin @kcrisman @tscrim

Component: symbolics

Keywords: symbolic, vector

Reviewer: Travis Scrimshaw

Issue created by migration from https://trac.sagemath.org/ticket/22813

[mforets]

comment:1

Replying to nbruin : var(*args) already means the same thing as for a in args: var(a), so the signature is not available for different interpretation.

if we parse the arg by the length we get the desired behavior:

    if len(args)==1:
        name = args[0]
    elif len(args)==2:
        name = args[0]
        num_vars = args[1]
        if num_vars > 1:
            name = [name + str(i) for i in range(num_vars)]
    else:
        name = args

does it have some other undesired effects?

with the current set of tests in var.pyx, it seems to pass.

[nbruin]

comment:2

Problem: var("x","y"), as long as "y">1(which is true at the moment). Problem in python: duck typing. The second argument could be "stringy" or "integery" or both. In the "both" case, there's no way to choose.

[tscrim]

comment:3

IIRC 'y' > 1 will fail in Python3. However, you could do isinstance(args[1], str) to get around the ducktyping. It's not like any of this code needs to be super fast/lightweight.

[mforets]

Branch: u/mforets/pass_number_of_variables_to_var

[mforets]

comment:5

Added the numeric 2nd argument, following @tscrim's recommendation.

Let me suggest to add functionality for handling more than one variable. Note that the behavior below is a replica of SymPy's symbols constructor, check from sympy import symbols.

It is possible to handle several variables if we pass a list of names as first argument::

    sage: var(['x', 'y'], 2)
    ((x0, x1), (y0, y1))

and

The input variable name(s) is taken as initial subindex::

sage: var(['x1', 'y2'], 2)
((x1, x2), (y2, y3))

What are your thoughts?

---

New commits:

b41d282	add optional number of vars
34441b7	add example to ticket's use case

[mforets]

Commit: 34441b7

[kcrisman]

comment:6

There is, of course, the danger that this could overwrite someone's already-defined variables - say, if

x3=end_of_computation_of_last_twin_prime_pair # Fields Medal in hand!
var('x',5) # oops

though of course that can happen anyway, this is just more silent about it. Perhaps a check to see whether any of the variables about to be produced is already defined? Though we don't currently do that and the same danger exists... this is just more implicit, which isn't very Pythonic.

None of this should be construed as not supporting the goal of this ticket, I'm just raising questions.

[tscrim]

comment:7

I would expect var('y1', 2) to give me y10, y11, so having that be the initial value would be very surprising. So -1 on parsing out the number of the variable to be the start index.

[mforets]

comment:8

fair enough about naming conventions or handy constructions. as far as i'm concerned, this ticket is ready for peer-review!

[nbruin]

comment:9

Replying to @kcrisman:

There is, of course, the danger that this could overwrite someone's already-defined variables

I think that's one of the reasons why this doesn't belong in the top-level var. I could see why people would want to have a shorthand for

lambda x,n: tuple(SR.symbol("%s%s"%(x,i)) for in range(n))

or perhaps even

lambda x,n,m: tuple(tuple(SR.symbol("%s%s_%s"%(x,i,j)) for j in range(m)) for i in range(n))

but you'd probably want to bind the result to a single symbol, say X, so that you can spell variables programmatically via X[i] or X[i][j].
This is also the approach taken in

sage: R.<X>=InfinitePolynomialRing(QQ)

where you need to use X[0],X[1] etc.

In other words, generating indexed symbolic variables is probably not suitable for injection at all.