Indexed SR variables

[Marcelo Forets]

Provide a keyword argument to construct a tuple of symbolic variables:

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

[Marcelo Forets]

Related to: #22813, #22809, and #11576.

---

New commits:

​7b8eb5f	add index keyword in SR.var
​3093d25	add multiple indexing error

[Travis Scrimshaw]

This change is backwards incompatible with var('x','y'), where the second argument is treated as the latex name. We should also handle the latex name too.

The argument name of index is misleading. Perhaps n, index_set, indicies, or number?

Little thing, but the error messages should start with a lowercase letter (at least all new messages).

[Marcelo Forets]

Replying to tscrim:

as usual, thanks for your prompt feedback!!

This change is backwards incompatible with var('x','y'), where the second argument is treated as the latex name. We should also handle the latex name too.

yes. with the current commit one has:

sage: SR.var('x', 'y')
...
AttributeError: 'str' object has no attribute 'is_integer'

instead of:

sage: SR.var('x', latex_name='y')
x
sage: latex(x)
{y}

should i do this with some type checking to handle (integer/string), or just ordering the arguments in a different way and expect user to always type index=...?

IMO, it is better if SR.var('x', 4) is understood by the program.

The argument name of index is misleading. Perhaps n, index_set, indicies, or number?

i used index because one speaks of "indexed variables". for those you suggest let me upvote (in order of preference): n and indices. in addition to those, let me add as options: len, length or size. what do others think?

Little thing, but the error messages should start with a lowercase letter (at least all new messages).

ok, and full stop yes or no?

the question is if an exception should be a complete sentence or not.

[Travis Scrimshaw]

Replying to mforets:

Replying to tscrim: This change is backwards incompatible with var('x','y'), where the second argument is treated as the latex name. We should also handle the latex name too.

yes. with the current commit one has:

sage: SR.var('x', 'y')
...
AttributeError: 'str' object has no attribute 'is_integer'

instead of:

sage: SR.var('x', latex_name='y')
x
sage: latex(x)
{y}

should i do this with some type checking to handle (integer/string), or just ordering the arguments in a different way and expect user to always type index=...?

As you surmised, you can do one of two things. The first is to put the n (index) as a later argument (I feel that domain is less used except as a keyword argument, so I'm more willing to let that be backwards incompatible). The second, and more preferable, is to check the input type and redirect as necessary. (This is one of the biggest shortcomings of weakly type languages.)

IMO, it is better if SR.var('x', 4) is understood by the program.

I agree. It just means some more complicated code to parse the inputs, but it has better useability.

The argument name of index is misleading. Perhaps n, index_set, indicies, or number?

i used index because one speaks of "indexed variables". for those you suggest let me upvote (in order of preference): n and indices. in addition to those, let me add as options: len, length or size. what do others think?

I think n is generic but clear enough for something like this. I don't have too much of a preference (but not index).

Little thing, but the error messages should start with a lowercase letter (at least all new messages).

ok, and full stop yes or no?

the question is if an exception should be a complete sentence or not.

They are generally not, at least by Python's standard. So no full stop nor uppercase letter.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​8ad4a06	fix keyword name and exception formatting
​751d7df	check input types and redirect as necessary

[Travis Scrimshaw]

I'm cc-ing Nils, Karl-Dieter, and Ralf to see if they have any comments before setting this to a positive review.

[Karl-Dieter Crisman]

I'm unsure if I have a preference, but keep in mind the injection issue discussed elsewhere - I don't know whether these should be injected automatically into the global namespace or not. Not that I have a preference on that either :-) but just be sure to see, I didn't follow that discussion carefully.

[Travis Scrimshaw]

FYI, this does not inject any variables. It does add it to SR.symbols however, but I think that is less of an issue.

[Marcelo Forets]

also as you can see there is no "INPUT" block in this function. if you want that can be added, together with a list of possible domains that one could use.

[Nils Bruin]

Don't use a bare except. Put as narrow an exception class there as possible. Unintentionally catching exceptions makes debugging a lot harder.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​3d508e4

specify exception type

[Vincent Delecroix]

See also the related #18390

[Marcelo Forets]

(i'd like to add a proper docstring to this function) ​reference page of SR

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​5676d25

update docstring

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​ac9d797	Merge branch 'develop' into t/mforets/pass_number_of_variables_to_SRvar
​f34ac33	SR.var docstring update

[Travis Scrimshaw]

Last little thing from me: this could be done

-'{{{0}}}'.format(latex_name) + '_{{{0}}}'.format(str(i))
+'{{{}}}_{{{}}}'.format(latex_name, str(i))

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​29c9c2d

simplify formatted lated name line

[Marcelo Forets]

Replying to tscrim:

Last little thing from me: this could be done

-'{{{0}}}'.format(latex_name) + '_{{{0}}}'.format(str(i))
+'{{{}}}_{{{}}}'.format(latex_name, str(i))

done.

[Travis Scrimshaw]

If there are any objections, then set this back from positive review.