Mailman 3 March 2002 - Edu-sig

Re: [Tutor] Thoughts on little lambda
by Burley, Brent March 12, 2002

March 12, 2002

Kirby wrote: > Just to review the construct, I was suggesting a way to > make "function factories" (functions that build other > functions) which have internal complexity beyond lambda's > ability by itself, is to use an internal function called > with lambda. > > E.g. the example below includes a print statement -- > something lambda can't, by itself, invoke: > > >>> def makeadder(n): > def main(x): > print "Adding %s" % n > return x + n > return main In "functional language" language, binding a function with a partial argument list is called "currying". Here's a nice description: http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?curried+function Here's the same thing, but in an explicitly curried form: def adder(x, n): print "Adding %s" % n return x + n def makeadder(n): return lambda x: adder(x, n) The main difference is that it wraps the adder function rather than redefining it each time. There's also a recipe for a general currying class here: http://aspn.ActiveState.com/ASPN/Cookbook/Python/Recipe/52549 You use it directly like this: add2 = curry(adder, 2) The curry class supports currying of arbitrary arguments (including keyword args!) and has the added benefit that it doesn't require nested scopes and thus works on older versions of python. Brent

2 1

Re: [Edu-sig] Re: [Tutor] Thoughts on little lambda
by Kirby Urner March 11, 2002

March 11, 2002

At 12:11 PM 3/11/2002 -0800, Danny Yoo wrote: > > A brief experiment in the interpreter seems to indicate that a > > function's __doc__ is assignable, so it should be possible, after > > defining the function but before returning it, to do > > > > main.__doc__ = "This function returns %s" % descripton > > > > or something similar. > > >Here's a concrete example of this: > >### > >>> def makeAdder(n): >... def function(x): >... "This function adds %(n)s to x." >... return n + x >... function.__doc__ = function.__doc__ % {'n' : n} >... return function >... > >>> f = makeAdder(42) > >>> f.__doc__ >'This function adds 42 to x.' >### > Or even just: >>> def makeAdder(n): def function(x): return n + x function.__doc__ = "This function adds %s to x." % n return function >>> add42 = makeAdder(42) >>> help(add42) Help on function function: function(x) This function adds 1 to x. Kirby

1 0

Re: [Tutor] Thoughts on little lambda
by Kirby Urner March 11, 2002

March 11, 2002

You make an excellent point Jeff. It wasn't clear to me at first that I was moving towards such a simple lambda, so simple, in fact, that we don't need it at all. So the template should be revised as you've indicated: def builder(B_arg1,B_arg2...): def main(E_args): # statements using B_arg1,B_arg2 return main # expecting E_args as inputs So take all of my earlier templates and make this change of 'return lambda x: main(x)' --> 'return main' Thanks for the insight! Next question: Is there a way to associate a customized doc string with the built function? Kirby >Recently, Kirby Urner described a bit about the differences between >Python's lambda and Lisp-ish >lambdas. To create something that works a bit more like the Lisp-ish >lambda, Kirby proposed using a >function factory like this: > > > > def funcfact(r,j): > > def main(x): > > if not x%2: > > return pow(x,j)+4 > > else: > > return pow(x,r)+3 > > return lambda x: main(x) > >Now, I might be missing something (wouldn't be the first time ;) ) but it >seems to me that the return >statement doesn't need to create a lambda; it should be equivalent to >change it to simply > > return main > >shouldn't it? ISTM that the lambda here creates a function object that >calls a function, using >exactly the arguments passed to it; I see no benefit to encapsulating >that second function object >(the main in the above example) inside of another function object (and >some cost in terms of >overhead). > >Jeff Shannon >Technician/Programmer >Credit International

3 2

RE: [Tutor] Thoughts on little lambda
by Kirby Urner March 11, 2002

March 11, 2002

> >Python 2.2's IDLE should resolve the problem. Good luck! 2.2 does make import from __future__ work directly in the IDLE shell (you needn't be in a module), e.g.: >>> from __future__ import division >>> 3/2 1.5 However, in this particular case, using the nested scopes feature, the "fix" comes from not needing to import from __future__ at all, because nested scopes are the default for version 2.2 on. Just to review the construct, I was suggesting a way to make "function factories" (functions that build other functions) which have internal complexity beyond lambda's ability by itself, is to use an internal function called with lambda. E.g. the example below includes a print statement -- something lambda can't, by itself, invoke: >>> def makeadder(n): def main(x): print "Adding %s" % n return x + n return lambda x: main(x) This is the classic case of building an "adder" e.g.: >>> add1 = makeadder(1) >>> add1(5) Adding 1 6 Now it comes up in many applications that you want to do one thing to a number if it's odd, something else if it's even. The template below accepts two *functions* as inputs, and builds a "switcher" with 'em: >>> def evenodd(fe,fo): def main(x): if x%2: # odd return fo(x) else: # even return fe(x) return lambda x: main(x) So, for example, if you'd earlier defined add0 and add1 using the makeadder() function, then here you could pass these to function-builder evenodd() and get a function which adds 0 to evens, 1 to odds: >>> switcher = evenodd(add0,add1) >>> switcher(3) Adding 1 4 >>> switcher(2) Adding 0 2 But note that evenodd(fe,fo) is designed to accept *any* two functions, one to execute if the input is even, the other if odd. I think this provides a good example of "functional programming" in the sense of using functions to build other functions, which in turn involves thinking of functions as the arguments of other functions. But my main focus was to explore ways of overcoming little lambda's inherent limitations, by taking advantage of nested scopes to put the real guts of a function in some internally called construct. The arguments to the builder provide the static content for these guts (variable only at the time the function is built), and then the final lambda return statement handles what will be the dynamic inputs to the built function. In the case of a polynomial builder, you could have a list of coefficients at "build time", then, presuming it's a poly of a single variable (but it doesn't *have* to be) pass "x" in the lambda statement: >>> def buildpoly(coeffs): def main(x): dim = len(coeffs)-1 sum = 0 for c in coeffs: sum += c * pow(x,dim) dim -= 1 return sum return lambda x: main(x) >>> p = buildpoly([2,3,1]) # f(x) = 2x^2 + 3x + 1 >>> p(3) 28 >>> 2*(3**2) + 3*(3) + 1 >>> q = buildpoly([1,2,3,4]) # f(x) = x^3 + 2x^2 + 3x + 4 >>> q(10) 1234 >>> 10**3 + 2*(10**2) + 3*10 + 4 1234 The important thing to note here is buildpoly is returning callable functions, which functions are then applied to specific numbers. Note also that the internally called construct might be recursive. In the example below, recursop(op) wants an operation as input. It builds a recursive function which decrements the argument by 1 each time, stopping when the argument reaches 1 (up to the user here not to pass 1.5 or -1 -- asking for trouble [1]). So if you import mul and add from operator, you can use recursop to build a primitive factorial and and triangular number cruncher. I call it "triangular" because 5+4+3+2+1 may be represented as a triangle: * * * * * * * * * * * * * * * >>> def recursop(op): def main(x): if x==1: return x else: return apply(op,(x,main(x-1))) return lambda x: main(x) >>> factorial = recursop(mul) >>> factorial(5) 120 >>> factorial(7) 5040 >>> 7*6*5*4*3*2 5040 >>> triangular = recursop(add) >>> triangular(10) 55 >>> 10+9+8+7+6+5+4+3+2+1 55 It's a little harder to figure what's going on with recursive subtraction, but it works, if you import sub: >>> something = recursop(sub) >>> something(10) 5 i.e.: >>> 10-(9-(8-(7-(6-(5-(4-(3-(2-1)))))))) 5 These ideas are not new to programmers. It's the kind of stuff you see in Scheme/LISP all the time. I was just wanting to see how Python's little lambda (vs. the big honker lambda of the LISPs) isn't really a major limitation when it comes to writing function-building functions. The new way of doing scoping is what adds power, as the bindings are all local within the builder, and the lambda is charged only with passing what will be the external arguments to the built output functions -- expecting lots of reuse. The builder's calling args, on the other hand, are the one-time definers of the product's behavior. A natural next topic would be to explore this same construct as a way of returning generators, i.e. functions built around the new 'yield' keyword. Kirby [1] because we're using an internal function to provide the guts, more elaborate argument checking, including try/excepts, are certainly doable.

1 0

Re: [Edu-sig] OnLisp
by Chris Meyers March 3, 2002

March 3, 2002

Thanks for the tip Dethe. I've got the book downloaded and it looks like a real gem. That many of the special things you can do in Lisp can also be done in Python, makes this book especially valuable for this community. Chris 02/26/2002 9:41:38 AM, Dethe Elza <delza(a)mac.com> wrote: >You can download Paul Graham's out-of-print book On Lisp. I found out >about this from an interesting weblog called "Everything Burns" >(http://jimfl.tensegrity.net/), which had this to say about it: > ><quote> >I esteem OnLisp to be one of the most well-written, compelling books I >have encountered on any topic in computing. This is no mean praise >considering various works by one Stanford Professor name of Knuth. You >don't really have to care much about Lisp or its variants to enjoy this >book, though you should, at least, be able to tolerate topics which >arise from the peculiarities in Lisp-shaped languages. Familiarity with >Lisp will serve a programmer in any language anyway. > >Sadly, OnLisp is out of print, but you can download it free of charge. >You will be missing only the weight of the dense paperback in your >hands, the attractive cover, and the few figures sprinkled throughout. ></quote> > >http://www.paulgraham.com/onlisptext.html > >--Dethe > >-- >Dethe Elza (delza(a)burningtiger.com) >Chief Mad Scientist >Burning Tiger Technologies (http://www.burningtiger.com) >Weblog: http://livingcode.manilasites.com/ > > >_______________________________________________ >Edu-sig mailing list >Edu-sig(a)python.org >http://mail.python.org/mailman/listinfo/edu-sig >

3 2

re: Algorithm help Subsets
by Arthur Siegel March 3, 2002

March 3, 2002

Danny writes - >>Here is a recursive definition of the subsets function: Thanks. I *almost* understand it - though still having trouble wrapping my head around recursive stuff. Similarly an alogorithm I am using to get the permutations of a list excluding case were list = list.reverse(): def perms(source,done,current=[]): if done == len(source): if current[0] < current[-1]: P.append(current) else: for i in source: if i not in current: perms(source,done+1,current+[i]) I got it from a python-list discussion - but only sort of follow it. Not above using algorithms I don't fully understand. Putting your alogorithm into 'prodiction' with a small amendment: case1 = addHeads(sequence.pop(0), subsets(sequence, n-1)) case2 = subsets(sequence, n) thinking that I am saving 2 slice (sequence[1:]) operations at no cost. Thanks again. Art

2 1

Useful Things => Contagious Fun goes Pro !
by Jason Cunliffe March 3, 2002

March 3, 2002

http://www.profoundeffects.com/article.php?sid=1&mode=thread&order=0&thold=0 http://www.profoundeffects.com/ut.php ./Jason

1 0

Algorithm help
by Arthur Siegel March 2, 2002

March 2, 2002

Having inititally thought that asking for advice on algorithms was a bit OT for edu-sig and it more appropriate to go to the vast web for resources, I do a Google on "permutations algorithm" and get back as hit #1 a posting here by Kirby from May 1991. Great. So I click my ruby (small "r") slippers. My geometry meanderings have more and more (and somewhat unexpectedly) led me into needing algorithms related to permutations and subsets. E.g., I have X points in space and want to draw all the lines defined by them - a line being defined by 2 points. So I come up with: def unique2(pointslist): P=[] s=pointslist[:] while len(s): r=s.pop(0) for x in s: P.append([r,x]) return P Or for some number of points > 3, I want to draw all the planes defined by them - a plane being defined by 3 points. So, def unique3(pointslist): P=[] s=pointslist[:] while len(s): r=s.pop(0) t=s[:] while len(t): m=t.pop(0) for x in t: P.append([r,m,x]) return P I haven't been able to come up with a generalization - an alogrithm with a second parameter as the number of elements I want in the returned subset. I am sure these are well-worn issues - but I haven't found the right resource for answers. Anybody have ideas? Art

2 1

re: Algorithm help
by Arthur Siegel March 2, 2002

March 2, 2002

>>by Kirby from May 1991. Meant to say May,2001. Still not bad.

1 0