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

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

Coolest Python recipe of all time

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

Contents

  Coolest Python recipe of all time Raymond Hettinger <python@rcn.com> - 2011-05-02 10:33 -0700
    Re: Coolest Python recipe of all time David Monaghan <monaghand.david@gmail.com> - 2011-05-02 21:48 +0100
      Re: Coolest Python recipe of all time Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-02 14:58 -0600
        Re: Coolest Python recipe of all time David Monaghan <monaghand.david@gmail.com> - 2011-05-02 22:45 +0100
          Re: Coolest Python recipe of all time Stefan Behnel <stefan_ml@behnel.de> - 2011-05-03 07:04 +0200
            Re: Coolest Python recipe of all time Raymond Hettinger <python@rcn.com> - 2011-05-03 09:43 -0700
              Re: Coolest Python recipe of all time Chris Angelico <rosuav@gmail.com> - 2011-05-04 07:54 +1000
              Re: Coolest Python recipe of all time Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-03 16:10 -0600
          Re: Coolest Python recipe of all time Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-02 23:17 -0600
          Re: Coolest Python recipe of all time Terry Reedy <tjreedy@udel.edu> - 2011-05-03 02:00 -0400
            Re: Coolest Python recipe of all time Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-03 18:29 +1200
              Re: Coolest Python recipe of all time Terry Reedy <tjreedy@udel.edu> - 2011-05-03 11:49 -0400
              Re: Coolest Python recipe of all time Raymond Hettinger <python@rcn.com> - 2011-05-03 09:32 -0700
              Re: Coolest Python recipe of all time geremy condra <debatem1@gmail.com> - 2011-05-03 09:51 -0700
          Re: Coolest Python recipe of all time Stefan Behnel <stefan_ml@behnel.de> - 2011-05-03 08:23 +0200
            Re: Coolest Python recipe of all time Raymond Hettinger <python@rcn.com> - 2011-05-03 15:19 -0700
    Re: Coolest Python recipe of all time Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-06 16:59 +0000
      Re: Coolest Python recipe of all time geremy condra <debatem1@gmail.com> - 2011-05-06 10:43 -0700
      Re: Coolest Python recipe of all time Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-06 12:36 -0600
        Re: Coolest Python recipe of all time Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-07 08:29 +0000
          Re: Coolest Python recipe of all time Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-07 08:54 -0600
          Re: Coolest Python recipe of all time Raymond Hettinger <python@rcn.com> - 2011-05-07 14:02 -0700
      Re: Coolest Python recipe of all time Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-06 13:38 -0600
      Re: Coolest Python recipe of all time Raymond Hettinger <python@rcn.com> - 2011-05-06 12:58 -0700
    RE: Coolest Python recipe of all time Trent Nelson <trent@snakebite.org> - 2011-05-09 02:31 -0700
      Re: Coolest Python recipe of all time Raymond Hettinger <python@rcn.com> - 2011-05-09 14:10 -0700

Page 1 of 2  [1] 2  Next page →

#4488 — Coolest Python recipe of all time

I think it is time to give some visibility to some of the instructive
and very cool recipes in ActiveState's python cookbook.

My vote for the coolest recipe of all time is:

    http://code.activestate.com/recipes/365013-linear-equations-solver-in-3-lines/

What are your favorites?


Raymond
twitter: @raymondh

[toc] | [next] | [standalone]

#4498

On Mon, 2 May 2011 10:33:31 -0700 (PDT), Raymond Hettinger <python@rcn.com>
wrote:

>I think it is time to give some visibility to some of the instructive
>and very cool recipes in ActiveState's python cookbook.
>
>My vote for the coolest recipe of all time is:
>
>    http://code.activestate.com/recipes/365013-linear-equations-solver-in-3-lines/

Really cool, but wrong. x = 3234.667, not 3236.0

DaveM

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

#4499

On Mon, May 2, 2011 at 2:48 PM, David Monaghan
<monaghand.david@gmail.com> wrote:
> On Mon, 2 May 2011 10:33:31 -0700 (PDT), Raymond Hettinger <python@rcn.com>
> wrote:
>
>>I think it is time to give some visibility to some of the instructive
>>and very cool recipes in ActiveState's python cookbook.
>>
>>My vote for the coolest recipe of all time is:
>>
>>    http://code.activestate.com/recipes/365013-linear-equations-solver-in-3-lines/
>
> Really cool, but wrong. x = 3234.667, not 3236.0

Nope, I get 3236.  Maybe you made a mistake somewhere.

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

#4501

On Mon, 2 May 2011 14:58:50 -0600, Ian Kelly <ian.g.kelly@gmail.com> wrote:

>On Mon, May 2, 2011 at 2:48 PM, David Monaghan
><monaghand.david@gmail.com> wrote:
>> On Mon, 2 May 2011 10:33:31 -0700 (PDT), Raymond Hettinger <python@rcn.com>
>> wrote:
>>
>>>I think it is time to give some visibility to some of the instructive
>>>and very cool recipes in ActiveState's python cookbook.
>>>
>>>My vote for the coolest recipe of all time is:
>>>
>>>    http://code.activestate.com/recipes/365013-linear-equations-solver-in-3-lines/
>>
>> Really cool, but wrong. x = 3234.667, not 3236.0
>
>Nope, I get 3236.  Maybe you made a mistake somewhere.

Oops. What a plonker .Three times I checked and got the same result each
time. Now it works fine. Sorry!

DaveM

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

#4520

David Monaghan, 02.05.2011 23:45:
> On Mon, 2 May 2011 14:58:50 -0600, Ian Kelly wrote:
>
>> On Mon, May 2, 2011 at 2:48 PM, David Monaghan wrote:
>>> On Mon, 2 May 2011 10:33:31 -0700 (PDT), Raymond Hettinger wrote:
>>>
>>>> I think it is time to give some visibility to some of the instructive
>>>> and very cool recipes in ActiveState's python cookbook.
>>>>
>>>> My vote for the coolest recipe of all time is:
>>>>
>>>>     http://code.activestate.com/recipes/365013-linear-equations-solver-in-3-lines/
>>>
>>> Really cool, but wrong. x = 3234.667, not 3236.0
>>
>> Nope, I get 3236.  Maybe you made a mistake somewhere.
>
> Oops. What a plonker .Three times I checked and got the same result each
> time. Now it works fine. Sorry!

The bad thing about this recipe is that it requires quite a bit of 
background knowledge in order to infer that the code the developer is 
looking at is actually correct. At first sight, it looks like an evil hack, 
and the lack of documentation doesn't help either.

Stefan

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

#4551

On May 2, 10:04 pm, Stefan Behnel <stefan...@behnel.de> wrote:
> The bad thing about this recipe is that it requires quite a bit of
> background knowledge in order to infer that the code the developer is
> looking at is actually correct. At first sight, it looks like an evil hack,
> and the lack of documentation doesn't help either.

The recipe is cool in the same way that a magic trick is cool.

A practical recipe would use a more general purpose method (perhaps
using finite differences or continued fractions); it would have
documentation and tests; it would accept a regular python function
instead of a string; and it would avoid an unsanitized eval().  But
then it would completely lose its panache, its flourish, and the
pleasant gratification that you get when solving the riddle of how it
works.

We should have a separate thread for the most practical, best
documented, least surprising, and most boring recipe ;-)


Raymond

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

#4577

On Wed, May 4, 2011 at 2:43 AM, Raymond Hettinger <python@rcn.com> wrote:
> We should have a separate thread for the most practical, best
> documented, least surprising, and most boring recipe ;-)

a += b   # Adds b to a in-place. Polymorphic - works on a wide variety of types.

You didn't say it had to be complicated...

Chris Angelico

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

#4581

On Tue, May 3, 2011 at 3:54 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, May 4, 2011 at 2:43 AM, Raymond Hettinger <python@rcn.com> wrote:
>> We should have a separate thread for the most practical, best
>> documented, least surprising, and most boring recipe ;-)
>
> a += b   # Adds b to a in-place. Polymorphic - works on a wide variety of types.

Too surprising to qualify.  For some types it modifies a, while for
others it replaces a.

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

#4521

On Mon, May 2, 2011 at 11:04 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
> The bad thing about this recipe is that it requires quite a bit of
> background knowledge in order to infer that the code the developer is
> looking at is actually correct. At first sight, it looks like an evil hack,
> and the lack of documentation doesn't help either.

What do you mean, "looks like"?  For crying out loud, it abuses
complex numbers to represent 2-element vectors, and it passes
unvalidated input to eval().  It is *absolutely* an evil hack!  Albeit
a clever one...

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

#4526

On 5/3/2011 1:04 AM, Stefan Behnel wrote:

> The bad thing about this recipe is that it requires quite a bit of
> background knowledge in order to infer that the code the developer is
> looking at is actually correct.

The main math knowledge needed is the trivial fact that if a*x + b = 0, 
then x = -b/a. The other math knowledge needed is that complex numbers 
add componentwise. The trick is that replacing x with j and evaluating 
therefore causes (in Python) all the coefficients of x (now j) to be 
added together separately from all the constant terms to reduce the 
linear equation to a*x+b (= 0 implied).

-- 
Terry Jan Reedy

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

#4529

Terry Reedy wrote:
> The trick is that replacing x with j and evaluating 
> therefore causes (in Python) all the coefficients of x (now j) to be 
> added together separately from all the constant terms to reduce the 
> linear equation to a*x+b (= 0 implied).

Hmmm... so if we used quaternions, could we solve systems
of linear equations in 3 variables?

-- 
Greg

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

#4547

On 5/3/2011 2:29 AM, Gregory Ewing wrote:
> Terry Reedy wrote:
>> The trick is that replacing x with j and evaluating therefore causes
>> (in Python) all the coefficients of x (now j) to be added together
>> separately from all the constant terms to reduce the linear equation
>> to a*x+b (= 0 implied).
>
> Hmmm... so if we used quaternions, could we solve systems
> of linear equations in 3 variables?

Yes and no. The use of 1*j merely collected and added together all the 
multipliers of 'x' (and all the constant terms). That is a fairly 
trivial matter of constant folding. Systems of linear equations are 
usually presented in that form already. The actual solution to the 
simple equation is in the formula x = -a/b (where a and b are the sums). 
The solution formula for three variables would be far more complex.

-- 
Terry Jan Reedy

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

#4550

On May 2, 11:29 pm, Gregory Ewing <greg.ew...@canterbury.ac.nz> wrote:
> Terry Reedy wrote:
> > The trick is that replacing x with j and evaluating
> > therefore causes (in Python) all the coefficients of x (now j) to be
> > added together separately from all the constant terms to reduce the
> > linear equation to a*x+b (= 0 implied).
>
> Hmmm... so if we used quaternions, could we solve systems
> of linear equations in 3 variables?

Yes :-)

The implementation of a Quanternion class and the Quartic equation is
left as an exercise for the reader ;-)


Raymond
@raymondh

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

#4552

On Tue, May 3, 2011 at 8:49 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 5/3/2011 2:29 AM, Gregory Ewing wrote:
>>
>> Terry Reedy wrote:
>>>
>>> The trick is that replacing x with j and evaluating therefore causes
>>> (in Python) all the coefficients of x (now j) to be added together
>>> separately from all the constant terms to reduce the linear equation
>>> to a*x+b (= 0 implied).
>>
>> Hmmm... so if we used quaternions, could we solve systems
>> of linear equations in 3 variables?
>
> Yes and no. The use of 1*j merely collected and added together all the
> multipliers of 'x' (and all the constant terms). That is a fairly trivial
> matter of constant folding. Systems of linear equations are usually
> presented in that form already. The actual solution to the simple equation
> is in the formula x = -a/b (where a and b are the sums). The solution
> formula for three variables would be far more complex.

Or just use a gauss-jordan solver, which has the advantage of being
easy to explain and possible to verify by hand on small instances.

Geremy Condra

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

#4528

Terry Reedy, 03.05.2011 08:00:
> On 5/3/2011 1:04 AM, Stefan Behnel wrote:
>
>> The bad thing about this recipe is that it requires quite a bit of
>> background knowledge in order to infer that the code the developer is
>> looking at is actually correct.
>
> The main math knowledge needed is the trivial fact that if a*x + b = 0,
> then x = -b/a. The other math knowledge needed is that complex numbers add
> componentwise. The trick is that replacing x with j and evaluating
> therefore causes (in Python) all the coefficients of x (now j) to be added
> together separately from all the constant terms to reduce the linear
> equation to a*x+b (= 0 implied).

As your above paragraph proves, it's the kind of implementation that 
requires three lines of executing code and at least 6 lines of additional 
comment. Hopefully accompanied by an excuse of the developer.

Stefan

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

#4583

On May 2, 11:23 pm, Stefan Behnel <stefan...@behnel.de> wrote:
> Terry Reedy, 03.05.2011 08:00:
>
> > On 5/3/2011 1:04 AM, Stefan Behnel wrote:
>
> >> The bad thing about this recipe is that it requires quite a bit of
> >> background knowledge in order to infer that the code the developer is
> >> looking at is actually correct.
>
> > The main math knowledge needed is the trivial fact that if a*x + b = 0,
> > then x = -b/a. The other math knowledge needed is that complex numbers add
> > componentwise. The trick is that replacing x with j and evaluating
> > therefore causes (in Python) all the coefficients of x (now j) to be added
> > together separately from all the constant terms to reduce the linear
> > equation to a*x+b (= 0 implied).
>
> As your above paragraph proves, it's the kind of implementation that
> requires three lines of executing code and at least 6 lines of additional
> comment. Hopefully accompanied by an excuse of the developer.

If you found nothing educational, interesting, or amusing about the
three-line linear equation solver, then you're *really* going to hate
this one:

  http://groups.google.com/group/comp.lang.python/browse_frm/thread/e46de4596e93188b/


Raymond
@raymondh

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

#4840

On Mon, 02 May 2011 10:33:31 -0700, Raymond Hettinger wrote:

> I think it is time to give some visibility to some of the instructive
> and very cool recipes in ActiveState's python cookbook.
[...]
> What are your favorites?


I'm not sure if favourite is the right word, but I'm amazed by this one: 
McCarthy's "amb" (ambiguous) operator.

http://code.activestate.com/recipes/577368

Here's how I might use it to solve the problem if making change. In 
Australian currency, I have 5, 10, 20, 50 cent and $1 and $2 coins. 
Ignoring the dollar coins, how can I make up change for any multiple of 
five cents up to a dollar?

Suppose I have more 5 cent coins that I can deal with, and I want to make 
sure I hand out at least three of them. Here's how to make 45 cents worth 
of change:

>>> amb = Amb()
>>> a = amb(range(3, 21))  # number of 5 cent coins
>>> b = amb(range(11))  # number of 10 cent coins
>>> c = amb(range(6))  # number of 20 cent coins
>>> d = amb(range(3))  # number of 50 cent coins
>>> for _ in amb(lambda a,b,c,d: 5*a+10*b+20*c+50*d == 45):
...     print a, b, c, d
...
3 1 1 0
3 3 0 0
5 0 1 0
5 2 0 0
7 1 0 0
9 0 0 0


Suppose I have some words, and want to put them together so that there 
are a certain number of vowels:

>>> amb = Amb()
>>> a = amb(['quick', 'slow', 'hungry', 'wise-old'])
>>> b = amb(['fox', 'hare', 'turtle', 'kangaroo'])
>>> c = amb(['lazy', 'stupid', 'sleepy', 'confused'])
>>> d = amb(['dog', 'aardvark', 'sloth', 'wombat'])
>>>
>>> def test(a, b, c, d):
...     s = "The %s brown %s jumped over the %s %s." % (a, b, c, d)
...     num_vowels = sum(s.count(c) for c in 'aeiou')
...     return num_vowels in (12, 18, 19)
...
>>> for _ in amb(test):
...     print a, b, c, d
...
quick fox lazy sloth
quick fox lazy dog
quick kangaroo stupid aardvark
[...more solutions cut for brevity]
hungry kangaroo confused aardvark



As written, amb is just a brute-force solver using more magic than is 
good for any code, but it's fun to play with.



-- 
Steven

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

#4842

On Fri, May 6, 2011 at 9:59 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Mon, 02 May 2011 10:33:31 -0700, Raymond Hettinger wrote:
>
>> I think it is time to give some visibility to some of the instructive
>> and very cool recipes in ActiveState's python cookbook.
> [...]
>> What are your favorites?
>
>
> I'm not sure if favourite is the right word, but I'm amazed by this one:
> McCarthy's "amb" (ambiguous) operator.
>
> http://code.activestate.com/recipes/577368
>
> Here's how I might use it to solve the problem if making change. In
> Australian currency, I have 5, 10, 20, 50 cent and $1 and $2 coins.
> Ignoring the dollar coins, how can I make up change for any multiple of
> five cents up to a dollar?
>
> Suppose I have more 5 cent coins that I can deal with, and I want to make
> sure I hand out at least three of them. Here's how to make 45 cents worth
> of change:
>
>>>> amb = Amb()
>>>> a = amb(range(3, 21))  # number of 5 cent coins
>>>> b = amb(range(11))  # number of 10 cent coins
>>>> c = amb(range(6))  # number of 20 cent coins
>>>> d = amb(range(3))  # number of 50 cent coins
>>>> for _ in amb(lambda a,b,c,d: 5*a+10*b+20*c+50*d == 45):
> ...     print a, b, c, d
> ...
> 3 1 1 0
> 3 3 0 0
> 5 0 1 0
> 5 2 0 0
> 7 1 0 0
> 9 0 0 0
>
>
> Suppose I have some words, and want to put them together so that there
> are a certain number of vowels:
>
>>>> amb = Amb()
>>>> a = amb(['quick', 'slow', 'hungry', 'wise-old'])
>>>> b = amb(['fox', 'hare', 'turtle', 'kangaroo'])
>>>> c = amb(['lazy', 'stupid', 'sleepy', 'confused'])
>>>> d = amb(['dog', 'aardvark', 'sloth', 'wombat'])
>>>>
>>>> def test(a, b, c, d):
> ...     s = "The %s brown %s jumped over the %s %s." % (a, b, c, d)
> ...     num_vowels = sum(s.count(c) for c in 'aeiou')
> ...     return num_vowels in (12, 18, 19)
> ...
>>>> for _ in amb(test):
> ...     print a, b, c, d
> ...
> quick fox lazy sloth
> quick fox lazy dog
> quick kangaroo stupid aardvark
> [...more solutions cut for brevity]
> hungry kangaroo confused aardvark
>
>
>
> As written, amb is just a brute-force solver using more magic than is
> good for any code, but it's fun to play with.

I use a similar technique *a lot* for various kinds of constraint
solvers, but I have yet to come up with a really satisfying spelling
for it. Have you looked at the way this is done in Sage?

Geremy Condra

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

#4847

On Fri, May 6, 2011 at 10:59 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> As written, amb is just a brute-force solver using more magic than is
> good for any code, but it's fun to play with.

This isn't really amb; as you said it's just a brute-force solver with
some weird syntax.  The whole point of amb is to enable
non-deterministic programming, such as this:

def find_values():
    a = amb(1, 3, 5)
    b = amb(2, 4, 8)
    if a + b <= 5:
        fail()
    if not is_prime(a * b + 1):
        fail()
    c = amb(a, b, None)
    if c is not None and c < 5:
        fail()
    return a, b, c

The amb engine would conceptually execute this function for every
possible combination of a, b, and c, pruning away the combinations
that fail at some point, and arbitrarily returning one of the
remaining combinations.  So find_values() here might return (3, 4,
None) after failing at one point or another on (1, 2); (1, 4); (1, 8);
(3, 2); (3, 4, 3); and (3; 4; 4).

Note in particular that the declaration of c is not easily expressible
using the Python recipe.

This is typically implemented using continuations, and I'm not sure
whether a true amb could actually be achieved in Python without adding
continuations or flow-control macros to the language.

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

#4891

On Fri, 06 May 2011 12:36:09 -0600, Ian Kelly wrote:

> On Fri, May 6, 2011 at 10:59 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> As written, amb is just a brute-force solver using more magic than is
>> good for any code, but it's fun to play with.
> 
> This isn't really amb; as you said it's just a brute-force solver with
> some weird syntax.  The whole point of amb is to enable
> non-deterministic programming, such as this:
[...]
> The amb engine would conceptually execute this function for every
> possible combination of a, b, and c, 

Which pretty much is the definition of "brute-force solver", no?



-- 
Steven

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web