#9964: Document _pari_ and _pari_init_
-----------------------------+----------------------------------------------
   Reporter:  jdemeyer       |       Owner:  mvngu   
       Type:  defect         |      Status:  new     
   Priority:  blocker        |   Milestone:  sage-4.6
  Component:  documentation  |    Keywords:          
     Author:                 |    Upstream:  N/A     
   Reviewer:                 |      Merged:          
Work_issues:                 |  
-----------------------------+----------------------------------------------
Changes (by jdemeyer):

 * cc: mhansen, SimonKing (added)


Comment:

 Replying to [comment:3 mhansen]:
 > The idea behind all of the _XXX_ and _XXX_init_ methods is that _XXX_
 > returns the actual object whereas _XXX_init_ returns something which
 > is fed into the parent's __call__ method.
 >
 > The reason why the PARI situation is a bit more complicated is that
 > anything string you return from _gp_init_ should be valid as a
 > _pari_init_ function.  We should really name the name="pari" in the gp
 > Expect object so that we can remove the special case code.  We should
 > then also just have the default implementation of _gp_init_ call
 > _pari_init_ so that if you just define that, it will work for both gp
 > and pari.
 > }}}

 I think I understand what you're saying, I just don't understand why
 things are implemented like this.  If what you say is correct, then in
 almost no case it makes sense to have a {{{_pari_init_}}} function, since
 constructing an object through a string is almost certainly slower than
 using the PARI library. So we really should use {{{_pari_}}} instead of
 {{{_pari_init_}}}.

 Then we should rename {{{_pari_init_}}} to {{{_gp_init_}}} because we
 still need the strings for the Gp interface (and specifying
 {{{name="gp"}}} instead of {{{name="pari"}}} in Gp and removing all the
 special case code).

 What do you think?

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9964#comment:4>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sage-trac?hl=en.

Reply via email to