#807: construction of function fields
------------------------------------+---------------------------------------
Reporter: nbruin | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: sage-5.8
Component: basic arithmetic | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: | Merged in:
Dependencies: | Stopgaps:
------------------------------------+---------------------------------------
Comment (by nbruin):
Replying to [comment:11 tscrim]:
> > This would be avoided by disallowing polygen()'s name parameter being
omitted (it defaults to "x"). After all we are not allowed to construct
number fields, or non-prime finite fields, without naming a generator, and
this is worse since we usually think that we have named a generator...
Isn't the whole point of `polygen` that people get tired of supplying
names? Otherwise you can just spell it `QQ['a'].0`, which is shorter
anyway (or `QQ['a'].gen(0)` if you don't want to rely on the preparser and
is still shorter than `polygen(QQ,'a')` and requires the same number of
"shift" characters on a US keyboard)
>
> Yes I do not like that as well. However, even making name a mandatory
argument, it still does not prevent things such as:
> {{{
> sage: y = polygen(QQ, 'a')
> sage: y
> a
> }}}
> From looking at the function, I'd want to deprecate it if we decide to
forbid `R.<x> = QQ['t']` (which could be done in the preparse).
Deciding ''if'' the `names=` implied by `R.<x>` is necessary is already
flaky. Deciding if the implied `names=` is consistent with what is on the
RHS is going to be very complicated within the limited view of the
preparser. I don't think we want to grow a new attribute
`preparser_generated_names` just to accommodate this.
We can document what it does:
- bind generators to the python identifiers supplied
- if the RHS requires print names for the generators and doesn't supply
them, derive them from the python names.
Of course it's good style to let python names and print names bear
resemblance, but ultimately users will have to know that they are not the
same thing.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/807#comment:13>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.