#12796: Allow more general evaluation of FDerivativeOperator
-------------------------------+--------------------------------------------
       Reporter:  nbruin       |         Owner:  burcin      
           Type:  enhancement  |        Status:  needs_review
       Priority:  major        |     Milestone:  sage-5.0    
      Component:  symbolics    |    Resolution:              
       Keywords:               |   Work issues:              
Report Upstream:  N/A          |     Reviewers:              
        Authors:  Nils Bruin   |     Merged in:              
   Dependencies:               |      Stopgaps:              
-------------------------------+--------------------------------------------

Comment (by nbruin):

 Replying to [comment:9 mjo]:
 > The approach looks correct to me, I've just added a bunch of doctests
 and fixed some small issues:
 >
 >  * A failing doctest due to an extra space.

 Thanks! that was a typo that crept in.

 >  * The p_arg parser couldn't handle val = [x]

 A nice idea, but have you tested what your solution does with "val = a =
 1" ? I think the result will be (val,(a,1)), which is probably not what is
 intended (it should be a syntax error).

 I did think about a `p_list_or_expr` which peeks to the next token and
 dispatches to p_list, p_expr etc. Note that we have to be careful with
 accepting tuples. Otherwise
 `f( (a,1) )` and `f( a=1 )` both get parsed to the same form.

 One way to avoid that is to let p_arg parse `a=1` to `{a:1}`. I don't
 think Parser ever generates dicts. However, by now we're solving non-
 existent problems. So perhaps simply not accepting tuples in p_arg (as it
 is now) is the simpler solution.

 >  * Logic duplicated in `max_at_to_sage()` and `calculus.at()`

 Don't import `sage.calculus` into `maxima_lib`, because the reverse import
 is already in effect. I don't think a bit of logic duplication here is so
 problematic, since the input the routines in maxima_lib have to deal with
 is much better controlled than the other ones. `maxima_lib` has the
 potential for much better optimizations. So perhaps leaving it as it was
 is simplest and acceptable?

 Thanks for your work.

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12796#comment:10>
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