Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #43020 > unrolled thread

Splitting of string at an interval

Back to article view | Back to comp.lang.python

Contents

  Splitting of string at an interval subhabangalore@gmail.com - 2013-04-07 13:25 -0700
    Re: Splitting of string at an interval Dave Angel <davea@davea.name> - 2013-04-07 16:46 -0400
    Re: Splitting of string at an interval Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-07 21:48 +0000
      Re: Splitting of string at an interval Chris Angelico <rosuav@gmail.com> - 2013-04-08 13:01 +1000
        Re: Splitting of string at an interval Roy Smith <roy@panix.com> - 2013-04-08 09:21 -0400
          Re: Splitting of string at an interval Arnaud Delobelle <arnodel@gmail.com> - 2013-04-08 16:10 +0100
          Re: Splitting of string at an interval Roy Smith <roy@panix.com> - 2013-04-08 11:37 -0400
          Re: Splitting of string at an interval Chris Angelico <rosuav@gmail.com> - 2013-04-09 02:20 +1000
          Re: Splitting of string at an interval Arnaud Delobelle <arnodel@gmail.com> - 2013-04-08 17:30 +0100
            Re: Splitting of string at an interval Roy Smith <roy@panix.com> - 2013-04-08 21:09 -0400
              Re: Splitting of string at an interval Tim Chase <python.list@tim.thechases.com> - 2013-04-08 20:42 -0500
              Re: Splitting of string at an interval Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-09 02:38 +0000
                Re: Splitting of string at an interval Andrew Berg <bahamutzero8825@gmail.com> - 2013-04-08 21:57 -0500
                Re: Splitting of string at an interval Chris Angelico <rosuav@gmail.com> - 2013-04-09 14:22 +1000
                Re: Splitting of string at an interval Dave Angel <davea@davea.name> - 2013-04-09 02:28 -0400
          Re: Splitting of string at an interval Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-04-08 19:15 -0400

#43020 — Splitting of string at an interval

Dear Group,

I was looking to split a string in a particular interval, like,

If I have a string, 
string="The Sun rises in the east of  our earth"

I like to see it as, 
words=["The Sun","rises in","in the","east of","our earth"]

If any one of the learned members can kindly suggest.

Regards,
Subhabrata. 

[toc] | [next] | [standalone]

#43021

On 04/07/2013 04:25 PM, subhabangalore@gmail.com wrote:
> Dear Group,
>
> I was looking to split a string in a particular interval, like,
>
> If I have a string,
> string="The Sun rises in the east of  our earth"

Are you asserting that there is nothing but letters and whitespace in 
the string, and that any amount of consecutive whitespace may be 
considered a blank?

>
> I like to see it as,
> words=["The Sun","rises in","in the","east of","our earth"]

Those aren't words, they're phrases.  But more importantly, you're 
somehow doubling the word "in" before parsing.

>
> If any one of the learned members can kindly suggest.
>

split it into a list, use slices to divide that into even and odd 
numbered words.  Use zip to combine those two list together, and then 
combine the resultant tuples with a space between.


-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#43025

On Sun, 07 Apr 2013 13:25:57 -0700, subhabangalore wrote:

> Dear Group,
> 
> I was looking to split a string in a particular interval, like,
> 
> If I have a string,
> string="The Sun rises in the east of  our earth"
> 
> I like to see it as,
> words=["The Sun","rises in","in the","east of","our earth"]
> 
> If any one of the learned members can kindly suggest.


Like every programming problem, the solution is to break it apart into 
small, simple steps that even a computer can follow.


1) Split the string into words at whitespace.

words = string.split()


2) Search for the word "in", and if found, duplicate it.

tmp = []
for word in words:
    if word == 'in':
        tmp.append('in')
    tmp.append(word)

words = tmp


3) Take the words two at a time.

phrases = [words[i:i+2] for i in range(0, len(words), 2)]


4) Join the phrases into strings.

phrases = [' '.join(phrase) for phrase in phrases]



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#43034

On Mon, Apr 8, 2013 at 7:48 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Like every programming problem, the solution is to break it apart into
> small, simple steps that even a computer can follow.
> ...

5) Shortcut the whole thing, since the problem was underspecified, by
using a literal.

words = ["The Sun", "rises in", "in the", "east of", "our earth"]

*dive for cover against rotten tomatoes*

ChrisA

[toc] | [prev] | [next] | [standalone]

#43071

In article <mailman.263.1365390121.3114.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Mon, Apr 8, 2013 at 7:48 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
> > Like every programming problem, the solution is to break it apart into
> > small, simple steps that even a computer can follow.
> > ...
> 
> 5) Shortcut the whole thing, since the problem was underspecified, by
> using a literal.
> 
> words = ["The Sun", "rises in", "in the", "east of", "our earth"]
> 
> *dive for cover against rotten tomatoes*

Seems like the right solution to me.

For a while, I was rabidly(*) into TDD (Test Driven Development).  The 
cycle I was using was, "Write a specification of a behavior, write a 
(failing) test for that behavior, then write the least possible amount 
of code to make the test pass.  Lather, Rinse, Repeat, Ship"

The "least possible" part is important.  It makes sure the cycles stay 
short (ideally, just a few minutes), and that you don't write any code 
for which you don't have tests.  If you buy into that plan, then I see 
nothing wrong with your suggested solution.

(*) I still believe in TDD, but I don't practice it quite as 
enthusiastically as I used to.  Which probably means my code isn't as 
good as it used to be.

[toc] | [prev] | [next] | [standalone]

#43078

On 8 April 2013 14:21, Roy Smith <roy@panix.com> wrote:

> For a while, I was rabidly(*) into TDD (Test Driven Development).  The
> cycle I was using was, "Write a specification of a behavior, write a
> (failing) test for that behavior, then write the least possible amount
> of code to make the test pass.  Lather, Rinse, Repeat, Ship"
>
> The "least possible" part is important.  It makes sure the cycles stay
> short (ideally, just a few minutes), and that you don't write any code
> for which you don't have tests.

The least amount of code is often also not the best in terms of time
or space complexity.  Does this mean you have to write tests for time
and space complexity as well?  That's interesting, but I don't know of
tools to help do that (time complexity seems easy enough, but space
complexity seems tougher to me).

-- 
Arnaud

[toc] | [prev] | [next] | [standalone]

#43081

On Apr 8, 2013, at 11:10 AM, Arnaud Delobelle wrote:

> On 8 April 2013 14:21, Roy Smith <roy@panix.com> wrote:
> 
>> For a while, I was rabidly(*) into TDD (Test Driven Development).  The
>> cycle I was using was, "Write a specification of a behavior, write a
>> (failing) test for that behavior, then write the least possible amount
>> of code to make the test pass.  Lather, Rinse, Repeat, Ship"
>> 
>> The "least possible" part is important.  It makes sure the cycles stay
>> short (ideally, just a few minutes), and that you don't write any code
>> for which you don't have tests.
> 
> The least amount of code is often also not the best in terms of time
> or space complexity.  Does this mean you have to write tests for time
> and space complexity as well?  That's interesting, but I don't know of
> tools to help do that (time complexity seems easy enough, but space
> complexity seems tougher to me).


If space and time complexity are important, then you need to write a test for those things.  If you have no test for them, then it's not important and you shouldn't worry about it.  At least according to the TDD catechism :-)

From a somewhat less radical point of view, the first thing you want to do is get the code to produce correct results.  Once you've got that (and a fully comprehensive test suite to prove it), then you can move on to making it more efficient, and your test suite serves as protection against behavior regressions.

And, yes, I agree that testing for time and space complexity are not trivial, because making accurate, repeatable, and isolated measurements of those things is often surprisingly complicated.  I can't help point out, however, that if your initial implementation is to have your code return a constant, it's pretty likely to be an optimum solution in both time and space :-)

---
Roy Smith
roy@panix.com

[toc] | [prev] | [next] | [standalone]

#43082

On Tue, Apr 9, 2013 at 1:37 AM, Roy Smith <roy@panix.com> wrote:
> I can't help point out, however, that if your initial implementation is to have your code return a constant, it's pretty likely to be an optimum solution in both time and space :-)

Likely, but not certain.

# 1
def fifty_stars():
  return "**************************************************"

# 2
fifty_stars=lambda "*"*50

Okay, that's just getting 2AM stupid now. :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#43083

On 8 April 2013 17:20, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Apr 9, 2013 at 1:37 AM, Roy Smith <roy@panix.com> wrote:
>> I can't help point out, however, that if your initial implementation is to have your code return a constant, it's pretty likely to be an optimum solution in both time and space :-)
>
> Likely, but not certain.
>
> # 1
> def fifty_stars():
>   return "**************************************************"
>
> # 2
> fifty_stars=lambda "*"*50

There's a whole competition about writing the smallest program which
outputs the song "99 bottles of beer":

http://codegolf.com/99-bottles-of-beer

Cheers,

-- 
Arnaud

[toc] | [prev] | [next] | [standalone]

#43102

In article <mailman.295.1365438635.3114.python-list@python.org>,
 Arnaud Delobelle <arnodel@gmail.com> wrote:

> On 8 April 2013 17:20, Chris Angelico <rosuav@gmail.com> wrote:
> > On Tue, Apr 9, 2013 at 1:37 AM, Roy Smith <roy@panix.com> wrote:
> >> I can't help point out, however, that if your initial implementation is to 
> >> have your code return a constant, it's pretty likely to be an optimum 
> >> solution in both time and space :-)
> >
> > Likely, but not certain.
> >
> > # 1
> > def fifty_stars():
> >   return "**************************************************"
> >
> > # 2
> > fifty_stars=lambda "*"*50
> 
> There's a whole competition about writing the smallest program which
> outputs the song "99 bottles of beer":
> 
> http://codegolf.com/99-bottles-of-beer

I see the top 10 entries are all written in Perl.  I suppose this says 
something.

[toc] | [prev] | [next] | [standalone]

#43103

On 2013-04-08 21:09, Roy Smith wrote:
>> http://codegolf.com/99-bottles-of-beer
> 
> I see the top 10 entries are all written in Perl.  I suppose this
> says something.

About the capabilities of Perl for writing such code, or about the
drinking habits of Perl programmers? :-)

Or-about-how-perl-drives-you-to-drink'ly yours,

-tkc

[toc] | [prev] | [next] | [standalone]

#43105

On Mon, 08 Apr 2013 21:09:08 -0400, Roy Smith wrote:

>> There's a whole competition about writing the smallest program which
>> outputs the song "99 bottles of beer":
>> 
>> http://codegolf.com/99-bottles-of-beer
> 
> I see the top 10 entries are all written in Perl.  I suppose this says
> something.


When I write my own programming language, it will include a one-character 
built-in command to perform 99 bottles of beer, just so my language will 
always be the winner.

In fact, I may make it a bare . so that not only will it be the shortest 
program, but also the smallest program in terms of number of non-white 
pixels.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#43108

On 2013.04.08 21:38, Steven D'Aprano wrote:
> In fact, I may make it a bare . so that not only will it be the shortest 
> program, but also the smallest program in terms of number of non-white 
> pixels.
Until someone implements it in Whitespace.
-- 
CPython 3.3.0 | Windows NT 6.2.9200 / FreeBSD 9.1

[toc] | [prev] | [next] | [standalone]

#43112

On Tue, Apr 9, 2013 at 12:38 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Mon, 08 Apr 2013 21:09:08 -0400, Roy Smith wrote:
>
>>> There's a whole competition about writing the smallest program which
>>> outputs the song "99 bottles of beer":
>>>
>>> http://codegolf.com/99-bottles-of-beer
>>
>> I see the top 10 entries are all written in Perl.  I suppose this says
>> something.
>
>
> When I write my own programming language, it will include a one-character
> built-in command to perform 99 bottles of beer, just so my language will
> always be the winner.
>
> In fact, I may make it a bare . so that not only will it be the shortest
> program, but also the smallest program in terms of number of non-white
> pixels.

Don't be too specific, Steven. Also include a one-character built-in
to emit the program's own source, and another to echo "hello, world"
to standard output. And one to increment the accumulator, just for
completeness.

Who knows, it might already exist!

http://esolangs.org/wiki/Cliff_L._Biffle

ChrisA

[toc] | [prev] | [next] | [standalone]

#43122

On 04/08/2013 10:38 PM, Steven D'Aprano wrote:
> On Mon, 08 Apr 2013 21:09:08 -0400, Roy Smith wrote:
>
>>> There's a whole competition about writing the smallest program which
>>> outputs the song "99 bottles of beer":
>>>
>>> http://codegolf.com/99-bottles-of-beer
>>
>> I see the top 10 entries are all written in Perl.  I suppose this says
>> something.
>
>
> When I write my own programming language, it will include a one-character
> built-in command to perform 99 bottles of beer, just so my language will
> always be the winner.
>
> In fact, I may make it a bare . so that not only will it be the shortest
> program, but also the smallest program in terms of number of non-white
> pixels.
>

But do we need a shebang line?  If so, then make sure the interpreter 
name is also one character long.

I expect there's a character with fewer pixels than the period, but the 
utf-8 version of it would be more than one byte long.  But you could 
define your language with a default encoding that happens to map said 
character to a single byte.

The Wang word processor (proprietary hardware and OS) used a single 
pixel for \x20, and the no pixels for the \xff.  This way spaces were 
"visible" with a faint dot, more or less in the middle of the cell 
block.  It defined other symbols for other control characters like tab 
and newline.  I'm still looking for a similar feature for emacs (on 
Ubuntu), but so far I've been disappointed by the results.

Libreoffice has a similar feature, enabled by 
View->NonPrintingCharacters, but the dotted space is way too bold, 
basically a period that's higher in its cell.

-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#43098

On Mon, 8 Apr 2013 17:30:26 +0100, Arnaud Delobelle <arnodel@gmail.com>
declaimed the following in gmane.comp.python.general:


> There's a whole competition about writing the smallest program which
> outputs the song "99 bottles of beer":
> 
> http://codegolf.com/99-bottles-of-beer
>

	Bah, Humbug! How about comparative languages:
http://www.99-bottles-of-beer.net/abc.html
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web