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

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

Re: Fibonacci series recursion error

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Fibonacci series recursion error Paul Rudin <paul.nospam@rudin.co.uk> - 2011-04-30 15:40 +0100
    Re: Fibonacci series recursion error Hans Georg Schaathun <hg@schaathun.net> - 2011-05-01 09:18 +0100
      Re: Fibonacci series recursion error Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-01 09:04 +0000
        Re: Fibonacci series recursion error Hans Georg Schaathun <hg@schaathun.net> - 2011-05-01 10:27 +0100
          Re: Fibonacci series recursion error Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-01 11:56 +0000
            Re: Fibonacci series recursion error Hans Georg Schaathun <hg@schaathun.net> - 2011-05-01 14:15 +0100
              Re: Fibonacci series recursion error Chris Angelico <rosuav@gmail.com> - 2011-05-02 06:49 +1000
                Re: Fibonacci series recursion error Hans Georg Schaathun <hg@schaathun.net> - 2011-05-02 06:36 +0100
                  Re: Fibonacci series recursion error Chris Angelico <rosuav@gmail.com> - 2011-05-02 16:28 +1000
                  Re: Fibonacci series recursion error Chris Angelico <rosuav@gmail.com> - 2011-05-02 16:30 +1000
                  Re: Fibonacci series recursion error (slightly OT) Dave Angel <davea@ieee.org> - 2011-05-02 08:50 -0400
              Re: Fibonacci series recursion error Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-02 01:09 +0000
                Re: Fibonacci series recursion error Hans Georg Schaathun <hg@schaathun.net> - 2011-05-02 10:41 +0100
          Re: Fibonacci series recursion error Terry Reedy <tjreedy@udel.edu> - 2011-05-01 18:24 -0400
            Re: Fibonacci series recursion error Hans Georg Schaathun <hg@schaathun.net> - 2011-05-02 14:14 +0100
              Re: Fibonacci series recursion error Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-02 16:41 +0000
                Re: Fibonacci series recursion error Hans Georg Schaathun <hg@schaathun.net> - 2011-05-02 21:02 +0100
                  Re: Fibonacci series recursion error Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-03 00:21 +0000
                    Re: Fibonacci series recursion error rusi <rustompmody@gmail.com> - 2011-05-02 20:42 -0700
                    Re: Fibonacci series recursion error Hans Georg Schaathun <hg@schaathun.net> - 2011-05-03 06:13 +0100
                    Re: Fibonacci series recursion error Robert Brown <robert.brown@gmail.com> - 2011-05-08 01:44 -0400
                      Re: Fibonacci series recursion error Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-08 12:59 +0000
                        Development time vs. runtime performance (was: Fibonacci series recursion error) Teemu Likonen <tlikonen@iki.fi> - 2011-05-08 19:34 +0300
                          Re: Development time vs. runtime performance (was: Fibonacci series recursion error) Chris Angelico <rosuav@gmail.com> - 2011-05-09 12:49 +1000
                          Re: Development time vs. runtime performance (was: Fibonacci series recursion error) Robert Brown <robert.brown@gmail.com> - 2011-05-08 23:01 -0400
              Re: Fibonacci series recursion error Terry Reedy <tjreedy@udel.edu> - 2011-05-02 14:56 -0400
              Re: Fibonacci series recursion error Chris Angelico <rosuav@gmail.com> - 2011-05-03 07:56 +1000
                Re: Fibonacci series recursion error Hans Georg Schaathun <hg@schaathun.net> - 2011-05-03 08:01 +0100

Page 2 of 2 — ← Prev page 1 [2]

#4940

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
> If you value runtime efficiency over development time, sure. There are
> plenty of languages which have made that decision: Pascal, C, Java,
> Lisp, Forth, and many more.

I don't understand why you place Lisp and Forth in the same category as
Pascal, C, and Java.  Lisp and Forth generally have highly interactive
development environments, while the other languages generally require an
edit, compile, run it again debugging cycle.  Lisp in particular does a
better job than Python in optimizing developer time.  I can change class
definitions interactively without restarting my program.  I can add type
declarations to a single function and recompile it without restarting my
program.  Python requires me to rewrite the slow bits of my program in C
to get good performance.  Why is that an efficient use of developer
time?

bob

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

#4955

On Sun, 08 May 2011 01:44:13 -0400, Robert Brown wrote:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>> If you value runtime efficiency over development time, sure. There are
>> plenty of languages which have made that decision: Pascal, C, Java,
>> Lisp, Forth, and many more.
> 
> I don't understand why you place Lisp and Forth in the same category as
> Pascal, C, and Java.  Lisp and Forth generally have highly interactive
> development environments, while the other languages generally require an
> edit, compile, run it again debugging cycle.

Good point. Perhaps I need to rethink where Lisp and Forth sit in the 
development vs runtime trade-off continuum.


> Python requires me to rewrite the slow bits of my program in C
> to get good performance.

Python doesn't require you to re-write anything in C. If you want to make 
a different trade-off (faster runtime, slower development time) then you 
use a language that has made the appropriate trade-off. This applies 
whether you are talking about the entire program, or just one subroutine.


> Why is that an efficient use of developer time?

Because for any non-trivial program, it is faster and more developer 
friendly to just write one or three performance-critical routines in C, 
and the rest in Python, than it is to write everything in C.



-- 
Steven

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

#4961 — Development time vs. runtime performance (was: Fibonacci series recursion error)

* 2011-05-08T12:59:02Z * Steven D'Aprano wrote:

> On Sun, 08 May 2011 01:44:13 -0400, Robert Brown wrote:
>> I don't understand why you place Lisp and Forth in the same category
>> as Pascal, C, and Java. Lisp and Forth generally have highly
>> interactive development environments, while the other languages
>> generally require an edit, compile, run it again debugging cycle.
>
> Good point. Perhaps I need to rethink where Lisp and Forth sit in the
> development vs runtime trade-off continuum.
>
>> Python requires me to rewrite the slow bits of my program in C to get
>> good performance.
>
> Python doesn't require you to re-write anything in C. If you want to
> make a different trade-off (faster runtime, slower development time)
> then you use a language that has made the appropriate trade-off.

I believe that Robert Brown wanted to imply that Common Lisp is quite
optimal on both sides. It supports dynamic interactive development and
yet it has implementations with very efficient compilers. The trade-off
is not necessarily between the two.

But of course "development time" is a nicely vague concept. Depending on
the argument it can include just the features of language and
implementation. Other times it could include all the available resources
such as documentation, library archives and community mailing lists. All
these can reduce development time.

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

#4968 — Re: Development time vs. runtime performance (was: Fibonacci series recursion error)

On Mon, May 9, 2011 at 2:34 AM, Teemu Likonen <tlikonen@iki.fi> wrote:
> But of course "development time" is a nicely vague concept. Depending on
> the argument it can include just the features of language and
> implementation. Other times it could include all the available resources
> such as documentation, library archives and community mailing lists. All
> these can reduce development time.
>

And it also includes a developer's personal experience level. A good
programmer will have a mental "algorithmic library" if you like;
effectively, it's a gigantic hash table of "if I need to do this, I
can do it this way". A mediocre programmer will both take longer and
produce less efficient code than an awesome programmer. This is
primarily not a language feature, but a language that usually has one
obvious way to do things will likely be easier to grok than a language
that has myriad "gotchas" to work around.

Chris Angelico

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

#4969 — Re: Development time vs. runtime performance (was: Fibonacci series recursion error)

Teemu Likonen <tlikonen@iki.fi> writes:
> * 2011-05-08T12:59:02Z * Steven D'Aprano wrote:
>
>> On Sun, 08 May 2011 01:44:13 -0400, Robert Brown wrote:
>>> Python requires me to rewrite the slow bits of my program in C to get
>>> good performance.
>>
>> Python doesn't require you to re-write anything in C. If you want to
>> make a different trade-off (faster runtime, slower development time)
>> then you use a language that has made the appropriate trade-off.
>
> I believe that Robert Brown wanted to imply that Common Lisp is quite
> optimal on both sides. It supports dynamic interactive development and
> yet it has implementations with very efficient compilers. The trade-off
> is not necessarily between the two.

Yes, exactly.  Sometimes I don't know in advance which parts of my
Python program will run too slowly or take too much memory.  I only find
out after the code is written, when it fails to run fast enough or
doesn't fit in my computer's 32-bit address space.  Then the slow parts
get recoded in C.  Common Lisp supports a larger performance range.  A
developer can write slow code quickly or faster code by giving the
compiler more information, which requires more developer time.


> But of course "development time" is a nicely vague concept. Depending on
> the argument it can include just the features of language and
> implementation. Other times it could include all the available resources
> such as documentation, library archives and community mailing lists. All
> these can reduce development time.

This is definitely true.  The total time to complete any task always
depends on tons of factors outside of the programming language.  The
ecosystem is important ... How much code can I avoid writing myself?

bob

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

#4492

On 5/2/2011 9:14 AM, Hans Georg Schaathun wrote:
> On Sun, 01 May 2011 18:24:30 -0400, Terry Reedy

> :  Python does not do this automatically because 1) it can be a semantic
> :  change under some circumstances; 2) one who wants the iterative version
> :  can just as easily write it directly;
>
> That's the silliest argument I ever heard.

Calling something silly when you have not really read it and perhaps 
asked questions to really understand it is, to me, silly.

If you want a compiler that can introduce bugs into your program by 
doing what it thinks you meant, rather than what you said, don't use 
CPython.

> :        and 3) Python has a better way to
> :  process collections that removes essentially all the boilerplate in the
> :  recursive-call and while-loop versions:

To properly use modern Python, one should know and use for loops and 
iterators.

-- 
Terry Jan Reedy

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

#4503

On Mon, May 2, 2011 at 11:14 PM, Hans Georg Schaathun <hg@schaathun.net> wrote:
> That's the silliest argument I ever heard.  The programmer should write
> the code the way he and application domain experts think, i.e. very
> often recursively.  The compiler should generate code the way the CPU
> thinks (most optimally), i.e. iteratively.

The CPU can function iteratively or recursively. The main difference
between the programmer and the CPU there is that the CPU is always
imperative, while a programmer might want to think functionally, or in
an event-driven model, and then "under the covers" the compiler
translates that into imperative code.

But in my opinion, the programmer and the interpreter/compiler are
teammates. If you allow programmers to be stupid, you will get a lot
of stupid programmers writing code. (I think that's one of PHP's
biggest downsides.) If the human and the machine know each other well
enough, the resulting code can be orders of magnitude more efficient
to run, *without taking any more tme to code* because the programmer
already knew the right things to do.

Perhaps it will take you four hours to read through something, study
it, maybe eyeball the compiler's source code, maybe do some
disassembly. If you have a few years of career ahead of you, you'll
benefit many times over from those few hours, and without spending
extra time, you'll produce better code. THAT is what distinguishes the
master from the novice.

Chris Angelico

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

#4530

On Tue, 3 May 2011 07:56:26 +1000, Chris Angelico
  <rosuav@gmail.com> wrote:
: > often recursively.  The compiler should generate code the way the CPU
: > thinks (most optimally), i.e. iteratively.
: 
:  The CPU can function iteratively or recursively.

I should have said 'hardware' rather than CPU.  Iteratively it is not
as optimal as the call contexts have to be stored.

:  But in my opinion, the programmer and the interpreter/compiler are
:  teammates. If you allow programmers to be stupid, you will get a lot
:  of stupid programmers writing code. (I think that's one of PHP's
:  biggest downsides.) If the human and the machine know each other well
:  enough, the resulting code can be orders of magnitude more efficient
:  to run, *without taking any more tme to code* because the programmer
:  already knew the right things to do.

There are situations where that team is essential.  However, in many
more situation, the programmer has to team primarily with domain
experts and work with a language in which the domain expert is fluent.
The compiler and hardware are slaves of the engineers, and extra staff
to team up with the compiler is an added cost and delay.

:  Perhaps it will take you four hours to read through something, study
:  it, maybe eyeball the compiler's source code, maybe do some
:  disassembly. If you have a few years of career ahead of you, you'll
:  benefit many times over from those few hours, and without spending
:  extra time, you'll produce better code. THAT is what distinguishes the
:  master from the novice.

That depends on /what/ your career is, and what you need to master.

-- 
:-- Hans Georg

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web