Indexed SR variables

[mforets]

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

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

CC: @nbruin @kcrisman @rwst

Component: symbolics

Keywords: symbolic ring

Author: Marcelo Forets

Branch/Commit: 29c9c2d

Reviewer: Travis Scrimshaw

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

[mforets]

Commit: 3093d25

[mforets]

comment:1

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

---

New commits:

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

[mforets]

Author: Marcelo Forets

[mforets]

Branch: u/mforets/22909

[tscrim]

comment:2

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).

[mforets]

comment:3

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.

[tscrim]

comment:4

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.

[sagetrac-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

[sagetrac-git]

Changed commit from 3093d25 to 751d7df

[tscrim]

comment:6

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

[kcrisman]

comment:7

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.

[tscrim]

comment:8

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

[mforets]

comment:9

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.

[nbruin]

comment:10

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

[sagetrac-git]

Changed commit from 751d7df to 3d508e4

[sagetrac-git]

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

3d508e4

specify exception type

[videlec]

comment:12

See also the related #18390

[mforets]

comment:13

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

[sagetrac-git]

Changed commit from 3d508e4 to 5676d25

[sagetrac-git]

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

5676d25

update docstring

[sagetrac-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

[sagetrac-git]

Changed commit from 5676d25 to f34ac33

[tscrim]

comment:17

Last little thing from me: this could be done

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

[sagetrac-git]

Changed commit from f34ac33 to 29c9c2d

[sagetrac-git]

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

29c9c2d

simplify formatted lated name line

[mforets]

comment:19

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.

[tscrim]

Reviewer: Travis Scrimshaw

[tscrim]

comment:20

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

[vbraun]

Changed branch from u/mforets/22909 to 29c9c2d