I use srange quite a bit in practice in numerical settings. The sort
of construction I often use looks like:
step = .01
for x in srange(0,2+step/2, step):
...do whatever
I mention this because it is often does what I want, but of course
other people might want different things. There is clearly no
canonical choice that will make everyone happy.
I am happy to help review any patches for srange since it is something
important to me.
-M. Hampton
On Dec 9, 7:46 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> On Dec 9, 2008, at 5:19 PM, Tim Lahey wrote:
>
>
>
> > On Dec 9, 2008, at 7:55 PM, William Stein wrote:
>
> >>> I ran across this in some timestepping code I wrote for a ODE solver
> >>> for systems of second order ODEs. The general trick I used is to set
> >>> the first n-1 terms based upon the formula and set the final one to
> >>> the endpoint. It means that the final one may be shorter, but that
> >>> way
> >>> it always ends at the set endpoint.
>
> >> Any chance you could dive in and fixe srange? It's a pure Python
> >> function in
> >> sage/misc/misc.py
>
> > That's an awfully complicated function for what should be fairly
> > simple.
> > I'm not entirely sure what is being done is some of that code so I
> > don't
> > know if I want to touch it.
>
> Go for it, go off the docstring and examples rather than the code.
>
> > What about the other similar functions?
>
> They should probably be fixed too.
>
>
>
> > From my MATLAB code, the timestep loop looks like (using MATLAB
> > syntax):
>
> > % Iterate over timesteps
> > while (t<tfinal) & (t + h >t)
>
> > % Ensure we end at tfinal, this may shorten the last timestep
> > if t + h > tfinal, h = tfinal - t; end
> > t = t + h;
>
> > end
>
> > Note the trick is checking that that t+h > tfinal. That checks to
> > see if
> > we pass the endpoint. Also, with the loop, we're also checking to make
> > sure that the step increases t. This is to prevent looping through if
> > we're exactly at the endpoint. There is probably a better way of doing
> > this,
> > but with floats checking equality is problematic.
>
> Yeah. It's unclear exactly how "include endpoint" is supposed to
> behave in the inexact case. Sometimes step*k == (b-a) - epsilon, and
> sometimes step*k == (b-a) + epsilon.
>
> For example
>
> sage: RR(1/49) * 49 < 1
> True
>
> so should srange(0, 1, RR(1/49)) return the RR(1/49)*49 as the last
> value? Should srange(0, 1, RR(1/49), include_endpoint=True) return RR
> (1/49)*49 and then 1?
>
> This is all assuming that a+n*b == a + b + ... + b, which is often
> false (but it's almost certainly not worth the speed penalty to
> compute it via multiplication).
>
> - Robert
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
