#19552: images and preimages for projective subscheme
-------------------------------------+-------------------------------------
       Reporter:  bhutz              |        Owner:  bhutz
           Type:  enhancement        |       Status:  needs_info
       Priority:  minor              |    Milestone:  sage-6.10
      Component:  algebraic          |   Resolution:
  geometry                           |    Merged in:
       Keywords:  subscheme          |    Reviewers:  Vincent Delecroix
  iteration                          |  Work issues:
        Authors:  Ben Hutz           |       Commit:
Report Upstream:  N/A                |  5635becc9dd31f1e81c10f5422b37607e3ecdaa3
         Branch:                     |     Stopgaps:
  u/bhutz/ticket/19552               |
   Dependencies:                     |
-------------------------------------+-------------------------------------

Comment (by vdelecroix):

 Replying to [comment:7 bhutz]:
 > 2) hmm..I was matching the inputs that are used for the orbit function
 for affine and projective points. I was not aware of the python
 conventions covering such a situation. If we follow them here, then the
 other functions should be changed to match. This is fine by me, but I'll
 make the other function changes in a separate ticket.

 I see. Then for the sake of this ticket I guess it is better to follow the
 convention of the other dynamical functions. The advantage of the Python
 way is that it is faster to parse the argument (less type checking and
 avoid tuple constructions) and you have the property that
 {{{
 orbit(n1,n2) + orbit(n2,n3) == orbit(n1,n3)
 }}}
 Please let it for a later ticket (if you have time).

 > 3) `orbit` returns a list of points and ...

 The only draw back I see is the multiplication of methods! I do not claim
 that any of them is useless.

 > `forward_image` is used by call and I debated making it private or not.
 I think with `nth_iterate` existing, I can make this private.

 On the other hand, `nth_iterate` is very hard to found with tab-
 completion. If I would choose one name, I would go for `forward_image`
 (with an optional argument `order`). For word morphism (maps of the free
 monoid) there is an optional argument in `__call__`
 {{{
 sage: s = WordMorphism('a->ab,b->ba')
 sage: s('a')
 word: ab
 sage: s('a', 5)
 word: abbabaabbaababbabaababbaabbabaab
 }}}
 But of course you can not found `__call__` with tab completion. But as it
 is a word morphism is a function it is natural to use the `my_map(x)`
 syntax instead of `x.forward_image(my_map)`. And actually, there is also
 {{{
 sage: w = Word('ab')
 sage: w.apply_morphism(s)
 word: abba
 }}}
 I guess it would be good to unify the terminology here...

 > using `orbit` for preimages is a little shaky in my opinion. The forward
 images are single points(or varieties) but the preimages are collections
 of points (or varieties).

 You are right, I was thiking of bijective maps for which bi-sided orbits
 make sense.

 > Allowing something like `x.orbit(-2,2)` would return quite a strange
 object. So, I see this functionality as different. In the special case of
 automorphisms, using `orbit` for both would make sense, but I don't think
 it does in general.

 This should be definitely disallowed in general!

--
Ticket URL: <http://trac.sagemath.org/ticket/19552#comment:8>
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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to