Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Arithmetic sequences in Python

Reply
Thread Tools

Arithmetic sequences in Python

 
 
Gregory Petrosyan
Guest
Posts: n/a
 
      01-16-2006
Please visit http://www.python.org/peps/pep-0204.html first.

As you can see, PEP 204 was rejected, mostly because of not-so-obvious
syntax. But IMO the idea behind this pep is very nice. So, maybe
there's a reason to adopt slightly modified Haskell's syntax? Something
like

[1,3..10] --> [1,3,5,7,9]
(1,3..10) --> same values as above, but return generator instead of
list
[1..10] --> [1,2,3,4,5,6,7,8,9,10]
(1 ..) --> 'infinite' generator that yield 1,2,3 and so on
(-3,-5 ..) --> 'infinite' generator that yield -3,-5,-7 and so on

So,
1) "[]" means list, "()" means generator
2) the "start" is required, "step" and "end" are optional.

Also, this can be nicely integrated with enumerations (if they will
appear in python). Haskell is also example of such integration.

 
Reply With Quote
 
 
 
 
Bas
Guest
Posts: n/a
 
      01-16-2006
I like the use of the colon as in the PEP better: it is consistant with
the slice notation and also with the colon operator in Matlab.

I like the general idea and I would probably use it a lot if available,
but the functionality is already there with range and irange.

Bas

 
Reply With Quote
 
 
 
 
Paul Rubin
Guest
Posts: n/a
 
      01-16-2006
"Gregory Petrosyan" <(E-Mail Removed)> writes:
> As you can see, PEP 204 was rejected, mostly because of not-so-obvious
> syntax. But IMO the idea behind this pep is very nice. So, maybe
> there's a reason to adopt slightly modified Haskell's syntax?


I like this with some issues: Python loops tend to be 0-based, so
while it's convenient to express the sequence [1..n], what you usually
want is [0..(n-1)] which is uglier.

If you want to count down from f(n) to zero, in Haskell you might say

[b, b-1 .. 0] where b=f(n)

There's no "where" in Python, so what do you do?

[f(n)-1, f(n)-2 .. 0]

evaluates f twice (and might not even get the same result both times),
while the traditional

xrange(f(n)-1, -1, -1)

only evaluates it once but is IMO repulsive.

Anyway I've never liked having to use range or xrange to control
Python loops. It's just kludgy and confusing. So I think your idea
has potential but there's issues that have to be worked out.
 
Reply With Quote
 
Gregory Petrosyan
Guest
Posts: n/a
 
      01-16-2006
_Consistentsy_ is what BDFL rejects, if I understand pep right. As for
me, it's not too god to have similar syntax for really different tasks.
And [1:10] is really not obvious, while [1..10] is.

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      01-16-2006
On Mon, 16 Jan 2006 01:01:39 -0800, Gregory Petrosyan wrote:

> Please visit http://www.python.org/peps/pep-0204.html first.
>
> As you can see, PEP 204 was rejected, mostly because of not-so-obvious
> syntax. But IMO the idea behind this pep is very nice. So, maybe
> there's a reason to adopt slightly modified Haskell's syntax? Something
> like
>
> [1,3..10] --> [1,3,5,7,9]


-1 on the introduction of new syntax. Any new syntax.

(I reserve the right to change my mind if somebody comes up with syntax
that I like, but in general, I'm *very* negative on adding to Python's
clean syntax.)

For finite sequences, your proposal adds nothing new to existing
solutions like range and xrange. The only added feature this proposal
introduces is infinite iterators, and they aren't particularly hard to
make:

def arithmetic_sequence(start, step=1):
yield start
while 1:
start += step
yield start

The equivalent generator for a geometric sequence is left as an exercise
for the reader.

If your proposal included support for ranges of characters, I'd be more
interested.



--
Steven.

 
Reply With Quote
 
Paul Rubin
Guest
Posts: n/a
 
      01-16-2006
Steven D'Aprano <(E-Mail Removed)> writes:
> For finite sequences, your proposal adds nothing new to existing
> solutions like range and xrange.


Oh come on, [5,4,..0] is much easier to read than range(5,-1,-1).

> The only added feature this proposal
> introduces is infinite iterators, and they aren't particularly hard to
> make:
>
> def arithmetic_sequence(start, step=1):
> yield start
> while 1:
> start += step
> yield start


Well, that would be itertools.count(start, step) but in general a simple
expression is nicer than 5 lines of code.

> If your proposal included support for ranges of characters, I'd be more
> interested.


There's something to be said for that. Should ['a'..'z'] be a list or
a string?
 
Reply With Quote
 
Xavier Morel
Guest
Posts: n/a
 
      01-16-2006
Paul Rubin wrote:
> There's something to be said for that. Should ['a'..'z'] be a list or
> a string?

To me, the most obvious result would be either a range object as a
result, or always a list/generator of objects (to stay perfectly
consistent). If a range of numbers translate into a list of numbers,
then a range of characters should likewise translate to a list of
characters, and a join would be required to get a regular string. This
also adds more consistency between the two proposals of the initial post
(e.g. list-based range and generator-based range), for while the
list-based range could be expanded into a string a generator-based one
couldn't/shouldn't, and the abstraction breaks (because two constructs
that should be more or less equivalent become extremely different and
can't be swapped transparently).

This would also be consistent with other languages providing a native
"range" object such as Ruby or or Ada ranges.

The only thing that bothers me about the initial proposal is that there
would not, in fact, be any "range object", but merely a syntactic sugar
for list/generator creation. Not that I really mind it, but, well,
syntactic sugar for the purpose of syntactic sugar really doesn't bring
much to the table.

For those who'd need the (0..n-1) behavior, Ruby features something that
I find quite elegant (if not perfectly obvious at first), (first..last)
provides a range from first to last with both boundaries included, but
(first...last) (notice the 3 periods) excludes the end object of the
range definition ('a'..'z') is the range from 'a' to 'z' while
('a'...'z') only ranges from 'a' to 'y').
 
Reply With Quote
 
bearophileHUGS@lycos.com
Guest
Posts: n/a
 
      01-16-2006
Ranges of letters are quite useful, they are used a lot in Delphi/Ada
languages:
"a", "b", "c", "d", "e"...

I like the syntax [1..n], it looks natural enough to me, but I think
the Ruby syntax with ... isn't much natural.
To avoid bugs the following two lines must have the same meaning:
[1..n-1]
[1..(n-1)]

If you don't want to change the Python syntax then maybe the
range/xrange can be extended for chars too:

xrange("a", "z")
range("z", "a", -1)

But for char ranges I think people usually don't want to stop to "y"
(what if you want to go to "z" too? This is much more common than
wanting to stop to "y"), so another possibility is to create a new
function like xrange that generates the last element too:

interval("a", "c") equals to iter("abc")
interval(1, 3) equals to iter([1,2,3])
interval(2, 0, -1) equals to iter([2,1,0])

I have created such interval function, and I use it now and then.

Bye,
bearophile

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      01-16-2006
On Mon, 16 Jan 2006 12:51:58 +0100, Xavier Morel wrote:

> For those who'd need the (0..n-1) behavior, Ruby features something that
> I find quite elegant (if not perfectly obvious at first), (first..last)
> provides a range from first to last with both boundaries included, but
> (first...last) (notice the 3 periods)


No, no I didn't.

Sheesh, that just *screams* "Off By One Errors!!!". Python deliberately
uses a simple, consistent system of indexing from the start to one past
the end specifically to help prevent signpost errors, and now some folks
want to undermine that.

*shakes head in amazement*


--
Steven.

 
Reply With Quote
 
Alex Martelli
Guest
Posts: n/a
 
      01-16-2006
Paul Rubin <http://(E-Mail Removed)> wrote:
...
> while the traditional
>
> xrange(f(n)-1, -1, -1)
>
> only evaluates it once but is IMO repulsive.


Yep, reversed(range(f(n))) is MUCH better.


Alex
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
sum works in sequences (Python 3) Franck Ditter Python 10 09-19-2012 10:25 PM
Creating arithmetic sequences mmm Python 1 04-16-2008 11:18 PM
list(...) and list comprehensions (WAS: Arithmetic sequences in Python) Steven Bethard Python 7 01-20-2006 04:13 PM
Usual Arithmetic Conversions-arithmetic expressions joshc C Programming 5 03-31-2005 02:23 AM
RE: Nostalgic instruction sequences (Re: Python Productivity Gain?) Delaney, Timothy C (Timothy) Python 2 02-25-2004 12:05 PM



Advertisments