Pass number of variables to polygens

[mforets]

The number of generators of a polynomial can be specified as a number:

sage: PolynomialRing(QQ, 'x', 4).gens()
(x0, x1, x2, x3)

This ticket should allow doing:

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

Currently it returns TypeError: polygens() takes at most 2 arguments (3 given).

CC: @nbruin @tscrim @videlec

Component: commutative algebra

Keywords: polynomial vector

Author: Marcelo Forets

Branch/Commit: 5f1a4da

Reviewer: Simon King

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

[mforets]

Branch: u/mforets/pass_number_of_variables_to_polygens

[mforets]

Commit: df2e39f

[mforets]

comment:2

apart from that, i'm tempted to propose making this possible too:

sage: polygens(QQ, 'x', 4, start_at=1)
(x1, x2, x3, x4)

---

New commits:

df2e39f

add optional argrs to polygens

[kcrisman]

comment:3

Hmm, I wasn't aware of this other functionality. I have no opinion about it per se, but if you do it, I wonder if you could experiment with what might happen if one did

L = polygens(QQ, 'x', 4)
for l in L:
    SR(l).inject_variable()

or whatever the right commands would be for that. Or even

polygens(SR, 'x', 4)

though I assume that wouldn't work right. See #11576 for motivation. (Or forget this comment and just be aware of #11576, which had a flurry of activity four years ago but hasn't been looked at since.)

[sagetrac-git]

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

6d2082c

allow inject_variables and start_at options

[sagetrac-git]

Changed commit from df2e39f to 6d2082c

[mforets]

comment:5

Replying to @kcrisman:

Hmm, I wasn't aware of this other functionality. I have no opinion about it per se, but if you do it, I wonder if you could experiment with what might happen if one did

L = polygens(QQ, 'x', 4)
for l in L:
    SR(l).inject_variable()

or whatever the right commands would be for that. Or even

polygens(SR, 'x', 4)

though I assume that wouldn't work right.

great idea! it is very useful that these variables 'exist' in the calling method.
as you can see in revised patch i used get_main_globals to get around the issue.

how does it look? does someone suggest other examples?

See #11576 for motivation. (Or forget this comment and just be aware of #11576, which had a flurry of activity four years ago but hasn't been looked at since.)

ok, thanks for pointing that out! although it seems to me that #11576 is an advanced version of the simpler (but yet lacking) uses var('x', 4) and var('x', 4, 4) for vectors and matrices respectively. or i'm missing some basic reason why they don't exist already?

[nbruin]

comment:6

Don't both return a result and inject bindings (and certainly don't go grabbing the global scope!). It's pretty clear that the behaviour of var to both inject and return variables is a mistake once you see the confusion it causes.

Injection of polynomial variables is quite efficiently done with PolynomialRing(R,'x',4).inject_variables(), which prints a message and returns None on purpose.

polygen(*args) is just a short form of PolynomialRing(*args).gens() which helps people who know what a polynomial variable is but not what a polynomial ring is. I think it's a bad design decision to muddle this with other features.

I'm also against providing options to modify the numbering. There's a good reason why RX=PolynomialRing(R,'x',n) is allowed: it's clearly desirable to make "a polynomial ring in n variables" in various settings. Sage requires names for these variables, but specifying n names is bothersome if you don't care about the names. Hence the indexing. which agrees with what RX.gen(i) does. If you do care what your variable names are called, it's easy to specify a list of names. All kinds of possibilities exist: ["x_%s"%s for i in range(n)], ["x^(%s)"%s for i in range(1,n+1)] etc. It's much better to teach people how to get full customizibility than to give them one more option to discover, which will probably not meet their needs if they develop further.

[mforets]

comment:7

@nbruin : thanks for the prompt feedback :) but are you ok with df2e39f or not? notice that *args was missing there on the first place.

Don't both return a result and inject bindings (and certainly don't go grabbing the global scope!).

is there an alternative to global_scope()? i tried with just R.inject_variables() and it didn't work. i suppose it works via return R.injected_variables(), but then you don't have access to your vector of variables, right? for multiplication and so on, it is useful to have it.

It's pretty clear that the behaviour of var to both inject and return variables is a mistake once you see the confusion it causes.

could you point me to some threads on this issue, so that i can catch up? for me there are no surprises with var. moreover, i find it practical that the function returns you the variables and/or allows you to use them in the console.

Injection of polynomial variables is quite efficiently done with PolynomialRing(R,'x',4).inject_variables(), which prints a message and returns None on purpose.

ok, but let's agree it is a rather long construction for people with bad memory (i'm in that group).

polygen(*args) is just a short form of PolynomialRing(*args).gens() which helps people who know what a polynomial variable is but not what a polynomial ring is. I think it's a bad design decision to muddle this with other features.

yes (essentially i'm on that group, too). that's arguable: why should a feature bother at all? so long as it is consistent with the rest & well documented.. (more on this below)

If you do care what your variable names are called, it's easy to specify a list of names. All kinds of possibilities exist: ["x_%s"%s for i in range(n)], ["x^(%s)"%s for i in range(1,n+1)] etc.

that's definitely not easy.

It's much better to teach people how to get full customizibility than to give them one more option to discover, which will probably not meet their needs if they develop further.

i get the point about "teaching a man to fish", 100%. at the same time, i'm with the lazy people here: if someone thought the solution and shows you a little example in command help, then i prefer using it rather than working it out myself (saves time, and is less error-prone).

for the point on features: what about LaTeX? in general people are happy with lots and lots of customizations ready to be discovered.

[nbruin]

comment:8

Replying to @mforets:

@nbruin : thanks for the prompt feedback :) but are you ok with df2e39f or not? notice that *args was missing there on the first place.

Yes, that looks pretty straightforward. It might be that passing *args on wholesale is problematic (it causes erroneous parameters to be reported with a deeper traceback), but I don't see a big problem immediately. That's also something that is easy to fix later.

Concerning your other queries:

• in python it is usual that routines that are called because of their side-effects don't return anything. Compare L.sort() versus sorted(L)
• just google or search the documentation for the number of examples of y=var('y') etc.
• I don't think you will find many people who would give LaTeX as an example of a well-designed interface.
• implementing extra features adds bloat and other maintenance burden, and makes it more confusing for new people, because now they will be confronted with multiple ways of doing things. See "The zen of python". Not all of it applies to math software, but generally the ideas there have worked well to keep python a pleasant and easy to learn language.

That said, nothing prevents you from making your own convenience library functions and maintaining them in your own installation. Once they have been sitting around for a year or two and you're finding that you use them often, you'll have a nice body of code to demonstrate in exactly what way they are more convenient. Practice learns that what seems convenient when you're writing/designing something is often not used much in actual use.

Sage is getting large and mature enough that if there is a reasonable way of doing something, we should be hesitant about adding alternative constructions.

[kcrisman]

comment:9

ok, thanks for pointing that out! although it seems to me that #11576 is an advanced version of the simpler (but yet lacking) uses var('x', 4) and var('x', 4, 4) for vectors and matrices respectively. or i'm missing some basic reason why they don't exist already?

Because nobody has both implemented and reviewed them. Lots of bikeshedding around exactly what the defaults and syntax should be.