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


Reply via email to