Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > RE: A goto-like usage of a function

Reply
Thread Tools

RE: A goto-like usage of a function

 
 
Tim Golden
Guest
Posts: n/a
 
      07-29-2004
[Bart Nessux]

| > Here's the function... if the user wants to re-enter the
| path name...
| > I'm simply calling the function again... is this wrong???

[... snip function ...]

| Sorry... namespace pollution. Both the function
| and a var within it were named "path_name"... I'm
| an idiot... I need more coffee.

Yes. That was the most immediate problem. But the other
one is (only slightly) more subtle: you're going round
again by having the function call itself. Now, while this
will in fact work (it's called recursion, in case you've
not come across the concept) it's not the best way to do
this. All you need is a loop of this sort:

<code>

while 1:
chosen_path = raw_input ("What is the path?")
is_this_correct = \
raw_input ("You chose: %s. Is this correct?" % chosen_path)

if is_this_correct == 'Y':
break
elif is_this_correct == 'X':
sys.exit ()
elif is_this_correct == 'N':
continue
else:
print "I'm sorry; I don't understand"

</code>

Obviously, there are all sorts of variations on
this theme, but this will normally be a more
natural fit for this kind of operation.

TJG


__________________________________________________ ______________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
__________________________________________________ ______________________
 
Reply With Quote
 
 
 
 
Bart Nessux
Guest
Posts: n/a
 
      07-29-2004
Tim Golden wrote:
> [Bart Nessux]
>
> | > Here's the function... if the user wants to re-enter the
> | path name...
> | > I'm simply calling the function again... is this wrong???
>
> [... snip function ...]
>
> | Sorry... namespace pollution. Both the function
> | and a var within it were named "path_name"... I'm
> | an idiot... I need more coffee.
>
> Yes. That was the most immediate problem. But the other
> one is (only slightly) more subtle: you're going round
> again by having the function call itself. Now, while this
> will in fact work (it's called recursion, in case you've
> not come across the concept) it's not the best way to do
> this. All you need is a loop of this sort:
>
> <code>
>
> while 1:
> chosen_path = raw_input ("What is the path?")
> is_this_correct = \
> raw_input ("You chose: %s. Is this correct?" % chosen_path)
>
> if is_this_correct == 'Y':
> break
> elif is_this_correct == 'X':
> sys.exit ()
> elif is_this_correct == 'N':
> continue
> else:
> print "I'm sorry; I don't understand"
>
> </code>
>
> Obviously, there are all sorts of variations on
> this theme, but this will normally be a more
> natural fit for this kind of operation.
>
> TJG


I understand recursion to be a loop or a loop to
be recursion... however you prefer to look at it.
Whether it's a function calling itself until the
user gets the input right or a while statement w/i
a function waiting for correct input... IMO, it's
the same thing. With that said, there may be
performance issues that I'm unaware of that make
your approach better or worse than mine...
outside that, I think either approach is worthwhile.
 
Reply With Quote
 
 
 
 
Bart Nessux
Guest
Posts: n/a
 
      07-29-2004
Tim Golden wrote:
> [Bart Nessux]
>
> | > Here's the function... if the user wants to re-enter the
> | path name...
> | > I'm simply calling the function again... is this wrong???
>
> [... snip function ...]
>
> | Sorry... namespace pollution. Both the function
> | and a var within it were named "path_name"... I'm
> | an idiot... I need more coffee.
>
> Yes. That was the most immediate problem. But the other
> one is (only slightly) more subtle: you're going round
> again by having the function call itself. Now, while this
> will in fact work (it's called recursion, in case you've
> not come across the concept) it's not the best way to do
> this. All you need is a loop of this sort:
>
> <code>
>
> while 1:
> chosen_path = raw_input ("What is the path?")
> is_this_correct = \
> raw_input ("You chose: %s. Is this correct?" % chosen_path)
>
> if is_this_correct == 'Y':
> break
> elif is_this_correct == 'X':
> sys.exit ()
> elif is_this_correct == 'N':
> continue
> else:
> print "I'm sorry; I don't understand"
>
> </code>
>
> Obviously, there are all sorts of variations on
> this theme, but this will normally be a more
> natural fit for this kind of operation.
>
> TJG


I understand recursion to be a loop or a loop to
be recursion... however you prefer to look at it.
Whether it's a function calling itself until the
user gets the input right or a while statement w/i
a function waiting for correct input... IMO, it's
the same thing. With that said, there may be
performance issues that I'm unaware of that make
your approach better or worse than mine...
outside that, I think either approach is worthwhile.

 
Reply With Quote
 
Christopher T King
Guest
Posts: n/a
 
      07-29-2004
On Thu, 29 Jul 2004, Bart Nessux wrote:

> I understand recursion to be a loop or a loop to
> be recursion... however you prefer to look at it.
> Whether it's a function calling itself until the
> user gets the input right or a while statement w/i
> a function waiting for correct input... IMO, it's
> the same thing. With that said, there may be
> performance issues that I'm unaware of that make
> your approach better or worse than mine...
> outside that, I think either approach is worthwhile.


The 'performance issue' at stake is that the stack is being slowly but
surely eaten up using the recusive call... it's possible for a user to
crash your program by repeatedly providing incorrect input.

This programming style is enabled, however, by tail recursion elimination,
as seen in Scheme, where such recursion would be the natural way to write
your code. Not so in Python though -- a while loop is the one true way to
go (as recently prounounced by Guido ).

 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      07-29-2004
On 2004-07-29, Bart Nessux <(E-Mail Removed)> wrote:

> I understand recursion to be a loop or a loop to
> be recursion... however you prefer to look at it.


A loop uses a finite amount of memory no matter how many times
it loops. Recursion uses an unbounded amount of memory unless
it's tail recursion and the compiler transforms it into a loop
[the Python compiler does not].

> Whether it's a function calling itself until the user gets the
> input right or a while statement w/i a function waiting for
> correct input... IMO, it's the same thing. With that said,
> there may be performance issues that I'm unaware of that make
> your approach better or worse than mine... outside that, I
> think either approach is worthwhile.


Just make sure you place bounds on the depth of the recurstion
so you don't run out of stack space.

--
Grant Edwards grante Yow! Vote for ME
at -- I'm well-tapered,
visi.com half-cocked, ill-conceived
and TAX-DEFERRED!
 
Reply With Quote
 
Peter Hansen
Guest
Posts: n/a
 
      07-29-2004
Bart Nessux wrote:

> I understand recursion to be a loop or a loop to be recursion... however
> you prefer to look at it.


Absolutely not. Recursion is more like a spiral, rapidly closing
in on itself until you're trapped in the middle, or maybe a
swirling whirlpool that will sink your program over time...

Just because you can use recursion to implement something that
appears to loop doesn't mean it's a good idea. Much better
to get out of that frame of mind... Recursion does _not_ get
you back to where you were, as a real loop would.

The key is to understand that each time you call a function,
more data is put on the "stack", which has a finite size.
Basically the context of the calling function is preserved
when you call a subroutine, including all the local variables,
plus the "return address" so the interpreter knows where to
go back to.

Whether you do it through recursion or some other means,
if you get too deeply nested you will crash, and even if you
don't you still have the overhead of "unwinding" all those
stack frames when you finally return. It may look like
it falls off the end of the function, but in fact it is
actually returning to the previous stack frame, in the place
just after where the function call was, then it returns from
there to the previous stack frame, then returns to the previous
one, each time popping a frame off the stack, all the way up
to the top of the stack.

While it might be okay for a trivial script that is just asking
for user input, it is terribly bad style and you would do well
to learn to do it differently.

All IMHO, and theoretical discussions of tail recursion
notwithstanding.

-Peter
 
Reply With Quote
 
Bart Nessux
Guest
Posts: n/a
 
      07-29-2004
Peter Hansen wrote:
> Bart Nessux wrote:
>
>> I understand recursion to be a loop or a loop to be recursion...
>> however you prefer to look at it.

>
>
> Absolutely not. Recursion is more like a spiral, rapidly closing
> in on itself until you're trapped in the middle, or maybe a
> swirling whirlpool that will sink your program over time...
>
> Just because you can use recursion to implement something that
> appears to loop doesn't mean it's a good idea. Much better
> to get out of that frame of mind... Recursion does _not_ get
> you back to where you were, as a real loop would.
>
> The key is to understand that each time you call a function,
> more data is put on the "stack", which has a finite size.
> Basically the context of the calling function is preserved
> when you call a subroutine, including all the local variables,
> plus the "return address" so the interpreter knows where to
> go back to.
>
> Whether you do it through recursion or some other means,
> if you get too deeply nested you will crash, and even if you
> don't you still have the overhead of "unwinding" all those
> stack frames when you finally return. It may look like
> it falls off the end of the function, but in fact it is
> actually returning to the previous stack frame, in the place
> just after where the function call was, then it returns from
> there to the previous stack frame, then returns to the previous
> one, each time popping a frame off the stack, all the way up
> to the top of the stack.
>
> While it might be okay for a trivial script that is just asking
> for user input, it is terribly bad style and you would do well
> to learn to do it differently.
>
> All IMHO, and theoretical discussions of tail recursion
> notwithstanding.
>
> -Peter


Thanks to all for detailing how loops and
recursion differ. I'm going with Tim's loop
suggestion now that I realize why I shouldn't use
recursion for this type of thing.
 
Reply With Quote
 
Bengt Richter
Guest
Posts: n/a
 
      07-29-2004
On Thu, 29 Jul 2004 13:17:34 -0400, Bart Nessux <(E-Mail Removed)> wrote:

>Peter Hansen wrote:
>> Bart Nessux wrote:

[...]
>>
>> While it might be okay for a trivial script that is just asking
>> for user input, it is terribly bad style and you would do well
>> to learn to do it differently.
>>
>> All IMHO, and theoretical discussions of tail recursion
>> notwithstanding.
>>
>> -Peter

>
>Thanks to all for detailing how loops and
>recursion differ. I'm going with Tim's loop
>suggestion now that I realize why I shouldn't use
>recursion for this type of thing.


OTOH, the default recursion depth limit is 1000, so you could
have gotten 1000 tries before bumping into that.

But there was still an error in your function besides the name collision
that made the recursive call try to call the returned string of raw_input.

The recursive call did not provide for returning a successful result, the
way an immediate successful return did. I.e., the recursive call line
should have been
return path_name()
not just
path_name()

BTW, some languages (e.g. scheme) mandate proper tail recursion, so it
can be fine to implement looping via recursion, as Peter is alluding to
(I think while providing advice for python style which I agree with.

Regards,
Bengt Richter
 
Reply With Quote
 
Peter Hansen
Guest
Posts: n/a
 
      07-29-2004
Bengt Richter wrote:

> BTW, some languages (e.g. scheme) mandate proper tail recursion, so it
> can be fine to implement looping via recursion, as Peter is alluding to
> (I think while providing advice for python style which I agree with.


Never having used tail-recursive languages, I won't pretend to
be any kind of expert on proper style there...

I'm curious though. Is it considered perfectly acceptable style
to implement a "pure loop" in the form of recursion in a tail-
recursive language, or is that feature really intended just to
allow truly recursive algorithms to be implemented without
fear of stack overflow or performance problems?

The acceptance test would probably be: if a mature programmer
in the language in question encountered a loop-done-as-recursion
in code from, say, a junior programmer, would she refactor it to
use a more conventional control structure (e.g. while, or for)
or would she not give it a second thought?

-Peter
 
Reply With Quote
 
Donn Cave
Guest
Posts: n/a
 
      07-29-2004
In article <(E-Mail Removed)>,
Peter Hansen <(E-Mail Removed)> wrote:

> Never having used tail-recursive languages, I won't pretend to
> be any kind of expert on proper style there...
>
> I'm curious though. Is it considered perfectly acceptable style
> to implement a "pure loop" in the form of recursion in a tail-
> recursive language, or is that feature really intended just to
> allow truly recursive algorithms to be implemented without
> fear of stack overflow or performance problems?
>
> The acceptance test would probably be: if a mature programmer
> in the language in question encountered a loop-done-as-recursion
> in code from, say, a junior programmer, would she refactor it to
> use a more conventional control structure (e.g. while, or for)
> or would she not give it a second thought?


Depends of course on the language, but there sure exist
languages where "while" and "for" don't even exist (and
hence are not conventional control structures.) Haskell
is the one I know.

That isn't an accident, they aren't omitted just because
no one had time to implement them. Loops are an "imperative"
construct that doesn't make sense in a pure functional
language like Haskell. So I suppose that even where there's
more support for imperative constructs, as I think there is
in Scheme for example, a mature programmer of a Functional
Programming persuasion might well on the contrary recode
a loop to a recursive algorithm.

Donn Cave, http://www.velocityreviews.com/forums/(E-Mail Removed)
 
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
What is the difference between Memory Usage and Heap Usage in my JVMMetrics ? Krist Java 8 02-10-2010 12:44 AM
retrieving CPU Usage and Memory Usage information in JAVA hvt Java 0 03-13-2007 01:09 PM
retrieving CPU Usage and Memory Usage information in JAVA hvt Java 0 03-13-2007 01:07 PM
Webchecker Usage - a problem with local usage Colin J. Williams Python 1 02-26-2004 12:28 AM
Need help on memory usage VS PF usage metfan Java 2 10-21-2003 01:58 PM



Advertisments