#7560: len(t_span) > 2 case creates len(t_span) -  1 solutions
-------------------------------------------------+--------------------------
       Reporter:  adavid                         |         Owner:  jkantor   
           Type:  defect                         |        Status:  needs_work
       Priority:  minor                          |     Milestone:  sage-5.6  
      Component:  numerical                      |    Resolution:            
       Keywords:  ode_solver, ode_solve, t_span  |   Work issues:            
Report Upstream:  N/A                            |     Reviewers:            
        Authors:  Jan Medlock                    |     Merged in:            
   Dependencies:                                 |      Stopgaps:            
-------------------------------------------------+--------------------------

Comment (by medlock):

 Replying to [comment:8 tkluck]:
 > This is a very clear explanation in the doctext, thanks.
 >
 > This part is not entirely right, though:
 > {{{
 >     * If ``t_span`` is a tuple with more than 2 values, then (...)
 >
 >     * If ``t_span`` is a tuple with just 2 time values, then (...) the
 user must also specify
 >       ``num_points``.
 > }}}
 >
 > In the code, the distinction is made based on whether `num_points` is
 specified, and not based on the length of `t_span`. That's a good thing.
 (remember how your matlab code always breaks when you pass 1x1 matrices to
 your generic code for NxN matrices.)

 I'm not sure I understand what you're saying.  I believe what I've written
 is exactly correct.  The code in question is:
 {{{
 if len(self.t_span)==2 and num_points!=False:
     # Solve at num_points time steps.

 elif len(self.t_span) > 2:
      # Solve using t_span as the times.
 }}}
 http://trac.sagemath.org/sage_trac/browser/sage/gsl/ode.pyx#L495
 &
 http://trac.sagemath.org/sage_trac/browser/sage/gsl/ode.pyx#L538

 I agree that it is not ideal: the second condition should be
 `len(self.t_span) >= 2` and there should be an `else` clause to catch mis-
 specified `self.t_span`.  As for what to do if `len(self.t_span) > 2` and
 `num_points` is defined, I think the best thing to do is to use the values
 in `self.t_span` and ignore `num_points`.  I will put together a patch
 with this addition.

 > I would also be tempted to change the name of the parameter `num_points`
 to `num_intervals`, raising a `DeprecationWarning` for `num_points`. How
 do you feel about that?

 I personally find points more natural than intervals in this setting.
 (You're obviously right that intervals doesn't have the +1 issue.)

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