[sage-devel] Re: Fwd: Calculus
William Stein wrote:
-- Forwarded message --
From: Peter Doyle (a Professor at Dartmouth)
Date: Sep 18, 2007 10:32 AM
Subject: Re: Calculus
To: William Stein [EMAIL PROTECTED]
Hi William,
There was a long thread on sage-devel about this:
http://groups.google.com/group/sage-devel/browse_thread/thread/674e7d0da278
Thanks for pointing out this thread. Regarding range(), I was struck
by how the discussion turned to the question of basing ranges at 0
rather than 1. Having the default lower bound 0 actually doesn't
bother me at all. The real problem as I see it is that in range(1,10)
the upper bound isn't included. This can be justified in the case of
range(10) by viewing 10 as telling not the upper bound, but the length
of the list. But in range(1,10), 10 tells neither the length of the
list nor the upper bound. Or rather, it's the upper bound for a
half-open interval of integers, which is not the kind of convention
that is going to be natural for mathematicians or calculus students.
Mathematicians *could* have defined $\sum_{i=1}^{10}$ not to include
the upper limit in the sum. Only that's just not how we do it.
Why not define a new function srange (short for sagerange),
or redefine the existing srange function:
def srange(a,b=None,step=1, include_endpoint=True):
or something like that.
See sage: srange??
Alternative: reuse xrange
this function will be removed from Python in Python3000.
This is not to say that I think you necessarily have to make this
addition to the preparser. I think using Python was an inspired
decision, and is responsible for the fact that SAGE is so great. I
can see why you would not want to deviate from it without a compelling
reason. Not yet, anyway: Maybe after all the hackers have moved on
to Ruby (and then Topaz, and then Tourmaline...), leaving Python
(i.e., SAGE) to the mathematicians.
Diamonds are forever!
Jaap
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: Calculus
Robert Bradshaw wrote: Why not define a new function srange (short for sagerange), or redefine the existing srange function: def srange(a,b=None,step=1, include_endpoint=True): or something like that. See sage: srange?? Alternative: reuse xrange this function will be removed from Python in Python3000. One disadvantage of this is that include_endpoint=True takes much more time to write than +1, and requires the same amount of knowledge. Perhaps one could have a function full_range that includes the endpoint. Sorry, I meant this to be the default action. Jaap --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: Calculus
How about providing a sum function that would behave like, say, the integrate function. It could detect the argument types so if you passed it a list, it'd behave the same as the builtin sum function. sage: integrate(x, x, 0, 10) 50 sage: sum(x, x, 0, 10) 55 sage: sum(range(10)) 45 I'm having trouble thinking of other instances where range() not including the upper bound would cause (major) problems. --Mike On 9/18/07, Jaap Spies [EMAIL PROTECTED] wrote: Robert Bradshaw wrote: Why not define a new function srange (short for sagerange), or redefine the existing srange function: def srange(a,b=None,step=1, include_endpoint=True): or something like that. See sage: srange?? Alternative: reuse xrange this function will be removed from Python in Python3000. One disadvantage of this is that include_endpoint=True takes much more time to write than +1, and requires the same amount of knowledge. Perhaps one could have a function full_range that includes the endpoint. Sorry, I meant this to be the default action. Jaap --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: Calculus
On Sep 18, 2007, at 11:22 AM, Jaap Spies wrote:
William Stein wrote:
-- Forwarded message --
From: Peter Doyle (a Professor at Dartmouth)
Date: Sep 18, 2007 10:32 AM
Subject: Re: Calculus
To: William Stein [EMAIL PROTECTED]
Hi William,
There was a long thread on sage-devel about this:
http://groups.google.com/group/sage-devel/browse_thread/thread/
674e7d0da278
Thanks for pointing out this thread. Regarding range(), I was struck
by how the discussion turned to the question of basing ranges at 0
rather than 1. Having the default lower bound 0 actually doesn't
bother me at all. The real problem as I see it is that in range
(1,10)
the upper bound isn't included. This can be justified in the case of
range(10) by viewing 10 as telling not the upper bound, but the
length
of the list. But in range(1,10), 10 tells neither the length of the
list nor the upper bound. Or rather, it's the upper bound for a
half-open interval of integers, which is not the kind of convention
that is going to be natural for mathematicians or calculus students.
Mathematicians *could* have defined $\sum_{i=1}^{10}$ not to include
the upper limit in the sum. Only that's just not how we do it.
Why not define a new function srange (short for sagerange),
or redefine the existing srange function:
def srange(a,b=None,step=1, include_endpoint=True):
or something like that.
See sage: srange??
Alternative: reuse xrange
this function will be removed from Python in Python3000.
One disadvantage of this is that include_endpoint=True takes much
more time to write than +1, and requires the same amount of
knowledge. Perhaps one could have a function full_range that
includes the endpoint. I still like the [a..b] notation that makes
things totally obvious, and I am as surprised as Peter Doyle at the
shift of topic of whether or not indices should be 0-based (which we
don't have a choice about while sticking with Python).
This is not to say that I think you necessarily have to make this
addition to the preparser. I think using Python was an inspired
decision, and is responsible for the fact that SAGE is so great. I
can see why you would not want to deviate from it without a
compelling
reason. Not yet, anyway: Maybe after all the hackers have moved on
to Ruby (and then Topaz, and then Tourmaline...), leaving Python
(i.e., SAGE) to the mathematicians.
Diamonds are forever!
Jaap
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: Calculus
On Tuesday 18 September 2007 14:34, Robert Bradshaw wrote: I still like the [a..b] notation that makes things totally obvious, and I am as surprised as Peter Doyle at the shift of topic of whether or not indices should be 0-based (which we don't have a choice about while sticking with Python). Well, I'll respond as to why I think they are exactly the same issue (in spirit) since I'm the one who brought up 0-based vs. 1-based. To me, it is very very intuitive that range(10) has 10 elements. The only serious point of contention is where those 10 elements start. That's why I think that these are the same issues. I'll also say that I didn't mean to open this can of worms. It was just on my mind at the time and I don't really expect us to preparse or change python to work around this. However, I could fully understand why anyone would think it a royal pain in the neck. When trying to compute something that you read on paper, it is a continual conversion and a very confusing conversion. After all, one of the classic source of programming errors is off-by-one. -- Joel --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: Calculus
BTW, matlab has 1-based indexing too. Maple has both: there is an array object that can be 0,1,2,... based and a List object that is 1-based. I think it would be nice to have an iterator object similar to (1:n) in matlab (but not a list object). didier 2007/9/18, Joel B. Mohler [EMAIL PROTECTED]: On Tuesday 18 September 2007 14:34, Robert Bradshaw wrote: I still like the [a..b] notation that makes things totally obvious, and I am as surprised as Peter Doyle at the shift of topic of whether or not indices should be 0-based (which we don't have a choice about while sticking with Python). Well, I'll respond as to why I think they are exactly the same issue (in spirit) since I'm the one who brought up 0-based vs. 1-based. To me, it is very very intuitive that range(10) has 10 elements. The only serious point of contention is where those 10 elements start. That's why I think that these are the same issues. I'll also say that I didn't mean to open this can of worms. It was just on my mind at the time and I don't really expect us to preparse or change python to work around this. However, I could fully understand why anyone would think it a royal pain in the neck. When trying to compute something that you read on paper, it is a continual conversion and a very confusing conversion. After all, one of the classic source of programming errors is off-by-one. -- Joel --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: Calculus
On Sep 18, 2:10 pm, Mike Hansen [EMAIL PROTECTED] wrote: How about providing a sum function that would behave like, say, the integrate function. It could detect the argument types so if you passed it a list, it'd behave the same as the builtin sum function. sage: integrate(x, x, 0, 10) 50 sage: sum(x, x, 0, 10) 55 sage: sum(range(10)) 45 I'm having trouble thinking of other instances where range() not including the upper bound would cause (major) problems. --Mike ^^^ bump --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
