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

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

Feature suggestion -- return if true

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

Contents

  Feature suggestion -- return if true zildjohn01 <zildjohn01@gmail.com> - 2011-04-11 16:17 -0700
    Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-12 10:27 +1000
      Re: Feature suggestion -- return if true Grant Edwards <invalid@invalid.invalid> - 2011-04-12 01:44 +0000
        Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-12 12:12 +1000
          Re: Feature suggestion -- return if true Grant Edwards <invalid@invalid.invalid> - 2011-04-12 02:18 +0000
            Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-12 12:44 +1000
              Re: Feature suggestion -- return if true Grant Edwards <invalid@invalid.invalid> - 2011-04-12 13:42 +0000
              Re: Feature suggestion -- return if true "Martin v. Loewis" <martin@v.loewis.de> - 2011-04-17 12:03 +0200
                Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-18 09:36 +1000
        Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-12 12:20 +1000
        Re: Feature suggestion -- return if true Zero Piraeus <schesis@gmail.com> - 2011-04-11 22:43 -0400
        Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-12 12:44 +1000
        Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-12 12:49 +1000
        Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-12 12:59 +1000
        Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-12 13:01 +1000
          Re: Feature suggestion -- return if true Nobody <nobody@nowhere.com> - 2011-04-12 07:08 +0100
            Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-12 16:21 +1000
              Re: Feature suggestion -- return if true Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-12 10:52 +0000
              Re: Feature suggestion -- return if true scattered <tooscattered@gmail.com> - 2011-04-12 03:55 -0700
                Re: Feature suggestion -- return if true "Colin J. Williams" <cjw@ncf.ca> - 2011-04-12 10:01 -0400
              Re: Feature suggestion -- return if true Grant Edwards <invalid@invalid.invalid> - 2011-04-12 13:50 +0000
          Re: Feature suggestion -- return if true Grant Edwards <invalid@invalid.invalid> - 2011-04-12 13:44 +0000
        Re: Feature suggestion -- return if true Westley Martínez <anikom15@gmail.com> - 2011-04-12 07:05 -0700
          Re: Feature suggestion -- return if true scattered <tooscattered@gmail.com> - 2011-04-12 07:58 -0700
            Re: Feature suggestion -- return if true Westley Martínez <anikom15@gmail.com> - 2011-04-12 15:45 -0700
            Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-13 08:52 +1000
          Re: Feature suggestion -- return if true zildjohn01 <zildjohn01@gmail.com> - 2011-04-12 11:25 -0700
            Re: Feature suggestion -- return if true Terry Reedy <tjreedy@udel.edu> - 2011-04-12 15:14 -0400
            Re: Feature suggestion -- return if true alex23 <wuwei23@gmail.com> - 2011-04-12 21:05 -0700
      Re: Feature suggestion -- return if true Teemu Likonen <tlikonen@iki.fi> - 2011-04-12 21:00 +0300
        Re: Feature suggestion -- return if true Ian Kelly <ian.g.kelly@gmail.com> - 2011-04-12 12:25 -0600
          Re: Feature suggestion -- return if true Neil Cerutti <neilc@norwich.edu> - 2011-04-12 20:13 +0000
            Re: Feature suggestion -- return if true Neil Cerutti <neilc@norwich.edu> - 2011-04-12 20:16 +0000
        Re: Feature suggestion -- return if true Ian Kelly <ian.g.kelly@gmail.com> - 2011-04-12 12:29 -0600
        Re: Feature suggestion -- return if true Paul Rudin <paul.nospam@rudin.co.uk> - 2011-04-12 19:28 +0100
        Re: Feature suggestion -- return if true Chris Rebert <clp2@rebertia.com> - 2011-04-12 13:26 -0700
        Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-13 08:34 +1000
        Re: Feature suggestion -- return if true Ethan Furman <ethan@stoneleaf.us> - 2011-04-12 16:06 -0700
          Re: Feature suggestion -- return if true Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-04-21 12:13 +0200
        Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-13 09:12 +1000
        Re: Feature suggestion -- return if true Westley Martínez <anikom15@gmail.com> - 2011-04-12 16:15 -0700
        Re: Feature suggestion -- return if true Ethan Furman <ethan@stoneleaf.us> - 2011-04-12 16:48 -0700
          Re: Feature suggestion -- return if true Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-13 00:03 +0000
            Re: Feature suggestion -- return if true Ethan Furman <ethan@stoneleaf.us> - 2011-04-12 19:42 -0700
            Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-13 13:00 +1000
            Re: Feature suggestion -- return if true James Mills <prologic@shortcircuit.net.au> - 2011-04-13 13:28 +1000
        Re: Feature suggestion -- return if true Teemu Likonen <tlikonen@iki.fi> - 2011-04-13 13:58 +0300
    Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-12 10:46 +1000
      Re: Feature suggestion -- return if true Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-17 16:21 +1200
        Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-17 14:31 +1000
        Re: Feature suggestion -- return if true Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-17 08:45 +0000
          Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-17 19:07 +1000
            Re: Feature suggestion -- return if true Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-17 15:23 +0000
          Re: Feature suggestion -- return if true Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-18 12:25 +1200
          Re: Feature suggestion -- return if true Dave Angel <davea@ieee.org> - 2011-04-17 22:04 -0400
          Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-18 12:10 +1000
            Re: Feature suggestion -- return if true Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-19 12:35 +1200
              Re: Feature suggestion -- return if true Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2011-04-19 09:42 +0300
                Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-19 17:01 +1000
        Re: Feature suggestion -- return if true "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-04-17 08:33 -0400
          Re: Feature suggestion -- return if true Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-17 15:10 +0000
          Re: Feature suggestion -- return if true aahz@pythoncraft.com (Aahz) - 2011-04-18 09:11 -0700
        Re: Feature suggestion -- return if true Greg Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-18 11:09 +1200
    Re: Feature suggestion -- return if true Chris Angelico <rosuav@gmail.com> - 2011-04-12 10:51 +1000
    Re: Feature suggestion -- return if true Paul Rubin <no.email@nospam.invalid> - 2011-04-11 23:58 -0700
      Re: Feature suggestion -- return if true John Roth <johnroth1@gmail.com> - 2011-04-12 06:16 -0700
      Re: Feature suggestion -- return if true Mel <mwilson@the-wire.com> - 2011-04-12 11:12 -0400

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#3100

On Tue, 2011-04-12 at 16:06 -0700, Ethan Furman wrote:
> James Mills wrote:
> > Are we done with this discussion yet ? :)
> > *sigh* It was a slow day yesterday and I have
> > a funny feeling it's going to be the same today!
> > 
> > Regardless of anyone's subjective opinions as to what
> > was clear - I still stand by what I said.
> 
> I think I see your point -- the OP said:
> -->    _temp = expr
> -->    if _temp: return _temp
> 
> which is where you're getting
> -->    return _temp or None
> 
> However, most everyone ('cept you, it seems! ;) understood that there 
> would be more lines of code such that if bool(expr) == False no return 
> is executed and the function keeps going merrily along.  Like this:
> --> def func():
> -->     var1 = something()
> -->     var2 = something_else('this')
> -->     return? var1.hobgle(var2)
> -->     var3 = last_resort(var1)
> -->     return var3.wiglat(var2)
> 
> 
> Looking back at the whole post now, I see nothing there to concretely 
> make that point except the question mark on the return.
> 
> Hope this helps.
> 
> ~Ethan~

The question mark makes the programmer look like he wasn't sure of what
he was doing at the time.  "Hmm, should I return this object or not?"

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

#3101

Westley Martínez wrote:
> On Tue, 2011-04-12 at 16:06 -0700, Ethan Furman wrote:
>> --> def func():
>> -->     var1 = something()
>> -->     var2 = something_else('this')
>> -->     return? var1.hobgle(var2)
>> -->     var3 = last_resort(var1)
>> -->     return var3.wiglat(var2)
> 
> The question mark makes the programmer look like he wasn't sure of what
> he was doing at the time.  "Hmm, should I return this object or not?"
> 

Yeah, I'm definitely -1 on the ?, as well as -1 on the idea.  All other 
major flow control uses indentation, and this does not.

~Ethan~

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

#3104

On Tue, 12 Apr 2011 16:48:31 -0700, Ethan Furman wrote:

> Westley Martínez wrote:
>> On Tue, 2011-04-12 at 16:06 -0700, Ethan Furman wrote:
>>> --> def func():
>>> -->     var1 = something()
>>> -->     var2 = something_else('this') -->     return?
>>> var1.hobgle(var2)
>>> -->     var3 = last_resort(var1)
>>> -->     return var3.wiglat(var2)
>> 
>> The question mark makes the programmer look like he wasn't sure of what
>> he was doing at the time.  "Hmm, should I return this object or not?"
>> 
>> 
> Yeah, I'm definitely -1 on the ?, as well as -1 on the idea.  All other
> major flow control uses indentation, and this does not.

Neither return nor raise use indentation, and you don't get much more 
major than those. Nor do list comps or generator expressions.

Indentation is not appropriate here because it doesn't involve a block of 
code. The whole point is that it just involves a single expression.

But in any case, I'm -1 on any syntax involving ? in Python, and +0 on 
the concept on a conditional return. I suspect it's too specialised to be 
worth special syntax or a keyword, but I can definitely see some uses for 
it.



-- 
Steven

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

#3110

Steven D'Aprano wrote:
> On Tue, 12 Apr 2011 16:48:31 -0700, Ethan Furman wrote:
> 
>> Westley Martínez wrote:
>>> On Tue, 2011-04-12 at 16:06 -0700, Ethan Furman wrote:
>>>> --> def func():
>>>> -->     var1 = something()
>>>> -->     var2 = something_else('this') -->     return?
>>>> var1.hobgle(var2)
>>>> -->     var3 = last_resort(var1)
>>>> -->     return var3.wiglat(var2)
>>> The question mark makes the programmer look like he wasn't sure of what
>>> he was doing at the time.  "Hmm, should I return this object or not?"
>>>
>>>
>> Yeah, I'm definitely -1 on the ?, as well as -1 on the idea.  All other
>> major flow control uses indentation, and this does not.
> 
> Neither return nor raise use indentation, and you don't get much more 
> major than those. Nor do list comps or generator expressions.

The indentation for return and raise is the next coded line.  List comps 
and gen exps are basically uber-functions, and regardless of how you 
categorize them when they finish it is easy to see where control goes to 
next because of indentation.  With this idea flow can leave the function 
with no indentation clue, making it easy to miss (assuming, of course, 
it's not some bright syntax highlighted color).

~Ethan~

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

#3111

On Wed, Apr 13, 2011 at 12:42 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
> The indentation for return and raise is the next coded line.  List comps and
> gen exps are basically uber-functions, and regardless of how you categorize
> them when they finish it is easy to see where control goes to next because
> of indentation.  With this idea flow can leave the function with no
> indentation clue, making it easy to miss (assuming, of course, it's not some
> bright syntax highlighted color).

So if I have a function that can early-abort, I should indent after that?

def foo(param):
    resource=malloc(50000) # Shtarker, zis is Python! We don't malloc here!
    if not resource: return 0
    resource[param]=5
    del resource
    return 1

Now, this pattern of "attempt to acquire resource, return if unable
to" is probably better recoded as "acquire resource and have it throw
an error if it can't"; but if you're eyeballing for control-flow
changes, a called function throwing an error is even less obvious than
an if: return.

Where should the indentation go?

As I understand it, Python uses indents the way C uses braces - to
delimit blocks of code. The only reason to indent in foo() above would
be if the if has an else:

    if not resource: return 0
    else:
        resource[param]=5
        del resource
        return 1

or, flipping that the other way around:

    if resource:
        resource[param]=5
        del resource
        return 1
    return 0

but both of these are grossly inferior to:

def foo(param):
    resource=generate_resource()
    resource.dosomething(param,5)
    return 1

However, what's to tell you that generate_resource() will throw a
KaosError if Siegfried is around?

(Oh, and apologies to all for picking a different comedy source for my
references. Sometimes even a python has to get smart...)

Chris Angelico

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

#3113

On Wed, Apr 13, 2011 at 1:00 PM, Chris Angelico <rosuav@gmail.com> wrote:
> def foo(param):
>    resource=malloc(50000) # Shtarker, zis is Python! We don't malloc here!
>    if not resource: return 0
>    resource[param]=5
>    del resource
>    return 1

In Python this can probably be done and perhaps is slightly more
readble with the "with" statement and a context manager:

def foo(param):
   try:
      with ResourceAllocator(50000) as resource:
         resource[param] = 5
         return 1
   except:
      return 0

Now I know I'm only adding to the discussion (argument) but
hey it's all in good fun until someone looses an eyeball!

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"

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

#3123

* 2011-04-12T13:26:48-07:00 * Chris Rebert wrote:

> I think Ben "Yahtzee" Croshaw's comments on open-world sandbox video
> games (of all things) have a lot of applicability to why allowing
> full-on macros can be a bad idea.

> IOW, a language is usually better for having such discussions and
> having a fairly coherent worldview enforced by the existence of a
> managing authority.

Thanks for the info. That's a strange view, and I must disagree. Lisp
people certainly love the power they have. But different language,
different philosophy, I guess.

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

#3009

On Tue, Apr 12, 2011 at 10:27 AM, James Mills
<prologic@shortcircuit.net.au> wrote:
> This could be simplified to just:
>
> return expr or None
>
> And more to the point... If your calee is relying
> on the result of this function, just returning the
> evaluation of "expr" is enough.

I'm thinking here that that's not a solution; he'll have more code to
follow. An example of what I think he's trying to do:

def fac(n):
    # attempt to get from a cache
    return? cache[n]
    # not in cache, calculate the value
    ret=1 if n<=1 else fac(n-1)*n
    # and cache and return it
    cache[n]=ret; return ret

If the rest of the function can be implemented as an expression, it
might be possible to use:

return expr or other_expr

But in the example of a lookup cache, that wouldn't work so easily -
assignment isn't an expression. If 'x=y' had a value as it does in C,
the above function could become:

def fac(n):
    return cache[n] or (cache[n]=1 if n<=1 else fac(n-1)*n)

which is a reasonable one-liner, albeit not the most efficient
factorial implementation. Is there a simple and Pythonic way to do
this?

BTW, assume for the purposes of discussion that the return? expr is a
complex one, such that it's well worth evaluating only once (maybe
even has side effects).

Chris Angelico

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

#3368

Chris Angelico wrote:

> def fac(n):
>     # attempt to get from a cache
>     return? cache[n]
>     # not in cache, calculate the value
>     ret=1 if n<=1 else fac(n-1)*n
>     # and cache and return it
>     cache[n]=ret; return ret

My idiom for fetching from a cache looks like this:

   def get_from_cache(x):
     y = cache.get(x)
     if not y:
       y = compute_from(x)
       cache[x] = y
     return y

which doesn't require any conditional returns.

-- 
Greg

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

#3371

On Sun, Apr 17, 2011 at 2:21 PM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> My idiom for fetching from a cache looks like this:
>
>  def get_from_cache(x):
>    y = cache.get(x)
>    if not y:
>      y = compute_from(x)
>      cache[x] = y
>    return y
>
> which doesn't require any conditional returns.

There's not a lot of difference between conditionally returning and
conditionally executing all the code between here and the return,
except that when you string three conditional returns together by your
method, it gets three indentations.

Chris Angelico

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

#3380

On Sun, 17 Apr 2011 16:21:53 +1200, Gregory Ewing wrote:

> Chris Angelico wrote:
> 
>> def fac(n):
>>     # attempt to get from a cache
>>     return? cache[n]
>>     # not in cache, calculate the value
>>     ret=1 if n<=1 else fac(n-1)*n
>>     # and cache and return it
>>     cache[n]=ret; return ret
> 
> My idiom for fetching from a cache looks like this:
> 
>    def get_from_cache(x):
>      y = cache.get(x)
>      if not y:
>        y = compute_from(x)
>        cache[x] = y
>      return y
> 
> which doesn't require any conditional returns.


I'm sure you realise that that snippet needlessly recalculates any cached 
result that happens to be false, but others reading might not.

If the compute_from function is expensive (and it better be, otherwise 
why are you bothering with a cache?), that could be expensive:

compute_from = is_prime_number
get_from_cache(253590421923456781012937340348512751108342137327 *
               195789732345627381015532937340363481051277321451)

:)

A better way is to explicitly test for the sentinel:

    y = cache.get(x)
    if y is not None:
        ...




-- 
Steven

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

#3382

On Sun, Apr 17, 2011 at 6:45 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sun, 17 Apr 2011 16:21:53 +1200, Gregory Ewing wrote:
>
>> Chris Angelico wrote:
>>
>>> def fac(n):
>>>     # attempt to get from a cache
>>>     return? cache[n]
>>>     # not in cache, calculate the value
>>>     ret=1 if n<=1 else fac(n-1)*n
>>>     # and cache and return it
>>>     cache[n]=ret; return ret
>>
>> My idiom for fetching from a cache looks like this:
>>
>>    def get_from_cache(x):
>>      y = cache.get(x)
>>      if not y:
>>        y = compute_from(x)
>>        cache[x] = y
>>      return y
>>
>> which doesn't require any conditional returns.
>
>
> I'm sure you realise that that snippet needlessly recalculates any cached
> result that happens to be false, but others reading might not.

Sure. In my (somewhat contrived) example of factorials, that's going
to be true (apart from 0! = 0); and if the function returns a string
or other object rather than an integer, same thing. If there's the
possibility of _ANY_ value coming back from the computation, then it
would need to be done as:

if x in cache: return cache[x]

or as:

try:
  return cache[x]
except KeyError:
  # calculate etc

Obviously, as with everything, you need to know your own code and your own data.

Chris Angelico

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

#3403

On Sun, 17 Apr 2011 19:07:03 +1000, Chris Angelico wrote:

> If there's the
> possibility of _ANY_ value coming back from the computation, then it
> would need to be done as:
> 
> if x in cache: return cache[x]

Or you can create a sentinel value that is guaranteed to never appear 
anywhere else:


SENTINEL = object()
obj = cache.get(x, SENTINEL)
if obj is SENTINEL:
   obj = calculate(x)
   cache[x] = obj
return obj

You can create the sentinel once, at the start of your program, rather 
than each time.

-- 
Steven

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

#3442

Steven D'Aprano wrote:

> I'm sure you realise that that snippet needlessly recalculates any cached 
> result that happens to be false, but others reading might not.

I only use it as written when I'm dealing with types that
don't have false values. If I did need to cache such a
type, I would use a different test, such as 'if y is None'.

-- 
Greg

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

#3449

On 01/-10/-28163 02:59 PM, Chris Angelico wrote:
>  <snip>
>
> Sure. In my (somewhat contrived) example of factorials, that's going
> to be true (apart from 0! = 0); and if the function returns a string
> or other object rather than an integer, same thing. If there's the

Just to be pedantic, by any reasonable definition, 0! == one, not zero.

One reference:  http://en.wikipedia.org/wiki/Factorial
3rd sentence.

More interestingly, There is a gamma function defined for lots of real 
and complex numbers, which for all non-negative integers matches the 
factorial:

    gamma(n) = (n-1)!

The gamma function has the same value (1) for one and two, so to be 
consistent, factorial should have that value for both zero and one.

DaveA

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

#3450

On Mon, Apr 18, 2011 at 12:04 PM, Dave Angel <davea@ieee.org> wrote:
> On 01/-10/-28163 02:59 PM, Chris Angelico wrote:
>>
>>  <snip>
>>
>> Sure. In my (somewhat contrived) example of factorials, that's going
>> to be true (apart from 0! = 0); and if the function returns a string
>> or other object rather than an integer, same thing. If there's the
>
> Just to be pedantic, by any reasonable definition, 0! == one, not zero.
>
> One reference:  http://en.wikipedia.org/wiki/Factorial
> 3rd sentence.

Hm! I never thought to check the definition... I just coded it up
quickly, and didn't even consider the possibility of a zero return
until the cache's loophole was challenged. Guess with a more correct
definition of factorial, it's even safer in the cache.

Question: How many factorial functions are implemented because a
program needs to know what n! is, and how many are implemented to
demonstrate recursion (or to demonstrate the difference between
iteration and recursion)? :)

ChrisA

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

#3514

Chris Angelico wrote:

> Question: How many factorial functions are implemented because a
> program needs to know what n! is, and how many are implemented to
> demonstrate recursion (or to demonstrate the difference between
> iteration and recursion)? :)

A related question is how often factorial functions are even
*used* in real code.

I can think of two uses for factorials off the top of my
head:

* Coefficients of polynomials resulting from Taylor expansions.
In that case you probably have a loop that's calculating the
numerators and denominators iteratively, and the factorial
is folded into that. Or you're looking up the coefficients in
a table and not calculating factorials at all.

* Combinations and permutations -- again, the factorials are
probably folded into a loop that calculates the result in a
more direct and efficient way.

-- 
Greg

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

#3543

Gregory Ewing writes:
> Chris Angelico wrote:
> 
> > Question: How many factorial functions are implemented because a
> > program needs to know what n! is, and how many are implemented to
> > demonstrate recursion (or to demonstrate the difference between
> > iteration and recursion)? :)

(I can't get to the parent directly, so I follow up indirectly.)

Factorials become an interesting demonstration of recursion when done
well. There's a paper by Richard J. Fateman, citing Peter Luschny:

<http://www.cs.berkeley.edu/~fateman/papers/factorial.pdf>
<http://www.luschny.de/math/factorial/FastFactorialFunctions.htm>

Fateman's "major conclusion is that you should probably not use the
'naive' factorial programs for much of anything". I take this to
include their use as examples of recursion, unless the purpose is to
make the idea of recursion look bad.

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

#3544

On Tue, Apr 19, 2011 at 4:42 PM, Jussi Piitulainen
<jpiitula@ling.helsinki.fi> wrote:
> Factorials become an interesting demonstration of recursion when done
> well. There's a paper by Richard J. Fateman, citing Peter Luschny:
>
> <http://www.cs.berkeley.edu/~fateman/papers/factorial.pdf>
> <http://www.luschny.de/math/factorial/FastFactorialFunctions.htm>
>
> Fateman's "major conclusion is that you should probably not use the
> 'naive' factorial programs for much of anything". I take this to
> include their use as examples of recursion, unless the purpose is to
> make the idea of recursion look bad.

"
And here is an algorithm which nobody needs, for the Simple-Minded only:
long factorial(long n) { return n <= 1 ? 1 : n * factorial(n-1); }  Do
not use it if n > 12.
"

I suppose the n > 12 issue is based on the assumption that
sizeof(long)==4. That's not an algorithmic question, that's a return
type issue... not to mention a rather naive assumption. 64-bit
integers let you go to n == 20 (iirc), and if you go bignum, even that
simple algorithm will be fine for up to n == 500 or so without stack
issues.

But sometimes you need a simple and well-known algorithm to
demonstrate a language feature with. Maybe we should switch to
Fibonacci instead... Anyone for caramel sauce?

http://www.dangermouse.net/esoteric/chef_fib.html

(As a side point, I have become somewhat noted around the house for
always saying "Fibonacci" whenever caramel sauce is mentioned...)

Chris Angelico

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

#3394

On Sun, 17 Apr 2011 16:21:53 +1200
Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote:
> My idiom for fetching from a cache looks like this:
> 
>    def get_from_cache(x):
>      y = cache.get(x)
>      if not y:
>        y = compute_from(x)
>        cache[x] = y
>      return y

I prefer not to create and destroy objects needlessly.

 def get_from_cache(x):
   if not x in cache:
     cache[x] = compute_from(x)
   return cache[x]

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web