On 9/21/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> On Sep 21, 2007, at 5:40 AM, Jaap Spies wrote:
> > irange can take three arguments: start, stop and step.
> > The arguments are not restricted to integers.
>
> So can the other range functions we have.
>
> > See the examples I give. Moreover I think irange is more Pythonic!
>
> I think the fact that irange looks so much like range is actually a
> disadvantage because they act so different (I consider potentially
[...]
> start) % step.) I would be in favor of shortening srange(...,
> include_endpoint=True) to srange(endpoint=True).
That's a great idea.
> In trying out your examples, I realized a shortcoming with the new
> notation though. First, sometimes it's more convenient to give a step
> rather than a second item. What would people think about the notation
>
> [start .. end ; step]
That might be OK. I would like to wait at least a month and let
people get some sense of how [start .. end] feels in practice, i.e.,
let the dust settle, before consider the above for inclusion.
Feedback would be good though. This [start .. end] notation
is really just supposed to be a simple shorthand, not a be-all,
end all.
> Also, [10..1] now returns [10], it should probably return the empty
> list.
It should *definitely* return the empty list; that is what
Magma does:
sage: magma.eval('[10..1]')
'[]'
> What about [10,11,.,0]? Also the empty list? I think so. Thoughts?
No clue. That scares me.
> > As irange is based only on srange it will be fast now tick #701 is
> > closed.
> >
> > Arguments enough to reopen ticket #706, I think.
>
> I don't think so, especially after resolving the issues above, but
> the two of us are probably equally bias about or own pieces of code.
> The only other person to have spoken up is William, maybe we should
> consider re-opening it if others speak up.
I am biased against irange because there is already:
range, xrange, srange, and xsrange,
and the argumetn for irange is to *lesson* confusion.
Having irange will mean also having xirange, and that's
just too many ranges for my brain.
>
> Examples:
>
> >> sage: v = irange(0,5); v
> >> [0, 1, 2, 3, 4, 5]
>
> sage: v = [0..5]; v
> [0, 1, 2, 3, 4, 5]
>
> >> sage: v = irange(1,10); v
> >> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
>
> sage: v = [1..10]; v
> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
>
> >> sage: v = irange(10,-1,-1); v
> >> [10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0, -1]
>
> sage: v = [10,9,..,-1]; v
> [10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0, -1]
>
> >
> >> sage: v = irange(1,8, 1/2); v
> >> [1, 3/2, 2, 5/2, 3, 7/2, 4, 9/2, 5, 11/2, 6, 13/2, 7, 15/2, 8]
>
> sage: v = [1, 3/2, .., 8]; v
> [1, 3/2, 2, 5/2, 3, 7/2, 4, 9/2, 5, 11/2, 6, 13/2, 7, 15/2, 8]
>
> >> sage: v = irange(1,2, 0.4); v
> >> [1, 1.40000000000000, 1.80000000000000]
>
> sage: v = [1,1.4,..,2]; v
> [1.00000000000000, 1.40000000000000, 1.80000000000000]
>
> >> sage: v = irange(1, 2, 0.5); v
> >> [1, 1.50000000000000, 2]
>
> sage: v = [1,1.5,..,2]; v
> [1.00000000000000, 1.50000000000000, 2.00000000000000]
>
> >> sage: v = irange(1, 2, -0.5); v
> >> []
>
> sage: v = [1,.5,..,2]; v # this is different because it computes the
> range 0.5 to 2 (with step -0.5) after appending the first items to
> the list. Bug?
> [1.00000000000000, 0.500000000000000]
>
> >> sage: v = irange(2, -2, -0.5); v
> >> [2, 1.50000000000000, 1.00000000000000, 0.500000000000000,
> >> 0.000000000000000, -0.500000000000000, -1.00000000000000,
> >> -1.50000000000000, -2]
>
> sage: [2,1.5,..,-1.5]
> [2, 1.50000000000000, 1.00000000000000, 0.500000000000000,
> 0.000000000000000, -0.500000000000000, -1.00000000000000,
> -1.50000000000000, -2]
>
> >> sage: v = irange(10,1); v
> >> []
>
> sage: [10,..,1]
> [10]
>
> >> sage: v = irange(10,10); v
> >> [10]
> >> sage: v = irange(10); v
> >> Traceback (most recent call last):
> >> ...
> >> TypeError: irange() takes at least 2 arguments (1 given)
> >> sage: v = irange(0.5, 2.5, 0.5); v
> >> [0.500000000000000, 1.00000000000000, 1.50000000000000,
> >> 2.00000000000000, 2.50000000000000]
>
> sage: [0.5,1,..,2.5]
> [0.500000000000000, 1.00000000000000, 1.50000000000000,
> 2.00000000000000, 2.50000000000000]
>
> >> sage: [n^2 for n in irange(-1, 10)]
> >> [1, 0, 1, 4, 9, 16, 25, 36, 49, 64, 81, 100]
>
> sage: [n^2 for n in [-1..10]]
> [1, 0, 1, 4, 9, 16, 25, 36, 49, 64, 81, 100]
>
> sage: [n^2 for n in (-1..10)] # as a generator
> [1, 0, 1, 4, 9, 16, 25, 36, 49, 64, 81, 100]
>
> >> And this one from the calculus thread!
> >>> -- I think that the Python convention of not including the upper
> >>> bound
> >>>>> in a sum is a real problem.
> >>>>>
> >>>>> sage: sum(i for i in range(1,10))
> >>>>> 45
> >>>>>
> >>>>> I understand this is a fundamental convention in Python, and
> >>>>> that it is
> >>>>> very
> >>>>> natural for people used to malloc(), but I worry that this will
> >>>>> be a
> >>>>> constant
> >>>>> headache for students (and professors!).
> >>
> >>
> >> sage: sum(i for i in irange(1, 10))
> >> 55
>
> sage: sum(1..10)
> 55
>
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~---------~--~----~------------~-------~--~----~
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-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
