Re: Is this a good use for lambda
Jeff Shannon wrote: Er, not as far as I can tell the 2.4 feature was what wouldn't work consistently; the corrected version, using list() and reverse(), doesn't look like it has anything that'll be a problem in my 2.2 installation, and probably not in 2.1 What he said :) Although if you genuinely prefer a functional programming style, I'd go with Terry's answer rather than mine. (Incidentally, I didn't even know what the reduce trap *was* until Terry described it, but the iterative version avoids it automatically) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Nick Coghlan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Although if you genuinely prefer a functional programming style, I'd go with Terry's answer rather than mine. The 'iterative' version can also be written recursively, which to most is functional. For me, the important question for general composition is whether one unpacks the sequence of functions to construct a nested sequence of wrappers (via compose2) *before* one has any data to apply it to, or whether one bundles the flat list of functions, as it is, with a generic composer which, once it gets a piece of data to operate on, unpacks and applies the functions one at a time. The former has a certain theoretical elegance, the latter seems more practical and, for Python, probably faster. So my previous answer was about how the make the former approach perhaps clearer, by explicit naming compose2, but not a claim that it is necessarily the 'better' approach. (Incidentally, I didn't even know what the reduce trap *was* until Terry described it, but the iterative version avoids it automatically) Yes, I noticed that A properly-written recursive version of the unpack and apply algorithm would do the same. To me, Python's builtin reduce has two related problems. The second is that it overlays two related but distinct functions, one with three parameters and the other, a special case, with just two. The first problem is that as one way to do the second, it defines the three parameter function with contradictory parameter orders. To explain the first: the three-param signature of Python's reduce is reduce(update_result_with_item, items, initial_result) The order of result and item(s) is switched between the update function and reduce itself. Some people (including GvR according to a post on PyDev) find this confusing and error-prone enough that they avoid using reduce. The proper, order-consistent signature is either reduce(update_result_with_item, initial_result, items) or possibly (but I prefer the above) reduce(apply_item_toupdate_result, items, initial_result) so that the order of the args to the update function matchwa the order they are given to reduce. As to the second problem: if the abbreviated and slightly specialized reduce1(updater, items), equivalent to def reduce1(updater, items): if items: return reduce(updater, items[0], items[1:]) else raise TypeError(reduce1 requires at least 1 item) is important enough to be in builtins, then perhaps it was/is important enough to have its own name instead of being overlayed on reduce with a perverted signature. (Though, reduce1(applier, items) *could* be overlayed on full reduce with the second consistent signature). Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Alan G Isaac wrote: I need a clarification of the argument. Are the opponents saying that I should not be able to: def compose(list_of_functions): return reduce(lambda f, g: lambda x: f(g(x)), list_of_functions) Personally, I think something like this is a place where lambdas are probably better than named functions. Still, you can do this without lambdas: def compose(list_of_functions): def compose2(f, g): def func(x): return f(g(x)) return func return reduce(compose2, list_of_functions) And may I see the proposed better replacement for function composition. Whether this is better or not, I don't know. -- Codito ergo sum Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Replying to myself, with a simpler version: Roel Schroeven wrote: Alan G Isaac wrote: def compose(list_of_functions): return reduce(lambda f, g: lambda x: f(g(x)), list_of_functions) def compose(list_of_functions): def compose2(f, g): def func(x): return f(g(x)) return func return reduce(compose2, list_of_functions) def compose(lof): def func(x): for f in reversed(lof): x = f(x) return x return func Still not sure what version is best though. -- Codito ergo sum Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Alan G Isaac wrote: I need a clarification of the argument. Are the opponents saying that I should not be able to: def compose(list_of_functions): return reduce(lambda f, g: lambda x: f(g(x)), list_of_functions) As things stand, I can live with lambda. However, if something can't be said in a single expression, then it's too complicated to be embedded inside another statement and have the whole remain even remotely readable. Even the above example is impossible to parse easily unless you happen to recognise that the 'compose' means 'function composition'. (cf. Fredrik's reaction. . .) In a nutshell: why? I dislike the use of lambda here, because it isn't very readable for most people, and readability counts. To actually understand what this code does, I had to rewrite it as I have below. To parse a statement using lambdas and figure out what it does, one almost *has* to assign a mental name to each lambda. Why should every reader of the code have to go to that effort, when the author of the code can do it once, and provide premade mental handles for every code reader to come after them? And may I see the proposed better replacement for function composition. Moving to a programming world where whitespace and typed characters are so cheap as to be practically free: def compose(list_of_functions): def compose_pair(f, g): def composed_pair(x): f(g(x)) return composed_pair return reduce(compose_pair, list_of_functions) The advantage of this version is that what it does is fairly obvious, even to someone that doesn't often use the term 'function composition' (like, say, me - I know what it means, but it doesn't spring to mind naturally). Moving on, I'd suggest that for any significant list of functions, the performance of the recursive version is going to be lousy, and I'd rewrite it with the iterative version: def compose(list_of_functions): application_order = reversed(list_of_functions) def composed(x): for f in application_order: x = f(x) return x return composed With this last version, even people that don't use functional programming at all can see immediately what the function is doing, including what the order of application is for the functions that combine to give the overall function composition (I had to go look up the precise operation of reduce() to be sure I had the order of application for function composition correct). The initial creation is going to be much faster (creating a single function object, rather than a big stack of them), and the actual invocation is going to be faster (since it's a simple iteration, rather than a big chain of recursive function calls). What are the disavantages of my final version? 1. It will deeply offend the aesthetic sensibilities of any functional purists in the audience. 2. It no longer directly implements the theoretical concept of function composition (although it has the same effect). From a real world programming point of view, though, it's self-documenting, runs faster and uses less memory, so it's really a pure win. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Nick Coghlan wrote: def compose(list_of_functions): application_order = reversed(list_of_functions) def composed(x): for f in application_order: x = f(x) return x return composed reversed returns an iterator to the list in reverse order, not a copy of the list: lst = range(10) riter = reversed(lst) list(riter) [9, 8, 7, 6, 5, 4, 3, 2, 1, 0] list(riter) [] so you either need to call reversed each time in 'composed' or copy the list and call reverse. Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Steven Bethard wrote: Nick Coghlan wrote: def compose(list_of_functions): application_order = reversed(list_of_functions) def composed(x): for f in application_order: x = f(x) return x return composed so you either need to call reversed each time in 'composed' or copy the list and call reverse. These iterator thingies sure are handy most of the time, but occasionally. . . I suspect the iterator (e.g. reversed()) vs list (e.g. sorted()) distinction is going to end up on a few of those 'Python Gotchas' pages. Ah well, at least I caught the 'return x' that was missing from my first draft version :) Corrected version: def compose(functions): application_order = list(functions) application_order.reverse() def composed(x) for f in application_order: x = f(x) return x return composed Cheers, Nick. P.S. For the curious: C:\python -m timeit -s x = range(1) y = x[:]; y.reverse() 1 loops, best of 3: 102 usec per loop C:\python -m timeit -s x = range(1) y = list(x); y.reverse() 1 loops, best of 3: 100 usec per loop C:\python -m timeit -s x = range(1) y = list(reversed(x)) 1 loops, best of 3: 166 usec per loop -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
So as I understand it, so far the best proposal for a replacement of my function-composition function uses a (compatibility reducing) Python 2.4 feature that Nick suggests will end up on Gotcha lists. Hmmm: lambda is looking pretty good, I'd say. The readability issue is valid, of course. But then, it has been one of the standard justifications for lambda. Thanks, Alan Isaac -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Alan G Isaac wrote: So as I understand it, so far the best proposal for a replacement of my function-composition function uses a (compatibility reducing) Python 2.4 feature that Nick suggests will end up on Gotcha lists. Er, not as far as I can tell the 2.4 feature was what wouldn't work consistently; the corrected version, using list() and reverse(), doesn't look like it has anything that'll be a problem in my 2.2 installation, and probably not in 2.1 Jeff Shannon Technician/Programmer Credit International -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Alan G Isaac [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I need a clarification of the argument. Are the opponents saying that I should not be able to: If you define 'opponent to lambda' as one who thinks such, then sure ;-). def compose(list_of_functions): return reduce(lambda f, g: lambda x: f(g(x)), list_of_functions) In a nutshell: why? And may I see the proposed better replacement for function composition. The issue with respect to lambda is not whether composition should be explicit, by building on a compose2 function, or implict, by induction, but whether, in this case, the function that composes two functions should get a name like 'compose2' or be anonymous (and generically referred to by CPython as 'lambda'. To me, the following is clearer to read and hardly takes more keystrokes: def compose2(f, g): return lambda x: f(g(x)) def compose(*callables):return reduce(compose2, callables) This allows independent use of compose2 and may give a better error message should callables include a non-callable. But understanding either version requires knowing that composition is associative, so that reducing left to right with reduce() has the same effect as reducing right to left as did with a for loop. Also, as written, both reduce versions fall into the reduce trap and fail with an empty list. To avoid this, add the identity function either always: def compose(*callables): return reduce(compose2, callables, lambda x: x) or, more efficiently, just when needed: def compose(*callables): if callables: return reduce(compose2, callables) else: return lambda x: x Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
The entity Fredrik Lundh wrote: /F Isn't it about time you became xml avare, and changed that to: f/ ? -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Max M wrote: Isn't it about time you became xml avare, and changed that to: f/ That makes no sense. -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Michael Hoffman wrote: Max M wrote: Isn't it about time you became xml avare, and changed that to: f/ That makes no sense. Yeah, but give the guy a break, we've all made feeble attempts at humor from time to time. You realize, I suppose, that it's a reference to the fact that XHTML uses lower-case tags and allows self-closure with a trailing slash after the tag name? let's-keep-that-christmas-spirit-coming-ly y'rs - steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Fredrik Lundh [EMAIL PROTECTED] writes: Simo Melenius wrote: Sure, but mental pollution counts too IMO. What you write and what you read must go through your brain, including dummy variables. And next you start thinking how to hide it from your own mind (e.g. naming it _my_local_func or something as ugly as the leading underscores in it). use something short, like f. hopefully, a single character won't overload your brain. I've heard some brain can tackle even Java's overly verbose syntax, it just depends on one's mind set how the verbosity is perceived: some find it a disrupting must, some like spending time writing things for which another programmer would've written a code generator by now. Elaborating more: Yes, naming functions that are only used once is minor nuisance (but still something I hope to get rid of eventually). In a level, it's probably similar to how whitespace at the end of the lines bogs some people -- that stuff just doesn't need to be there, so the text feels cluttered. (For _that_, Emacs luckily has its whitespace mode.. :)) *** Like someone pointed, using _ is a good convention for throwaways. The fact that such a convention exist just emphasizes that it _is_ an issue from which people try to sway away. And I think that it does, in fact, touch the innermost symbol table yes, but the overhead of keeping a local slot updated is very small, Sure; though I considered it more of a conceptual issue rather than a performance one. br, S -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
I just found it amusing that somenone like Frederik Lundh, who has written xml stuff like ElementTree, uses something that reminds of an old HTML tag as a sig. it's a perfectly valid XML end tag. locating the start tag is left as an exercise... /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Simo Melenius wrote: use something short, like f. hopefully, a single character won't overload your brain. I've heard some brain can tackle even Java's overly verbose syntax I find that hard to believe. Are you sure they're not relying on eclipse, or some other body part? Like someone pointed, using _ is a good convention for throwaways. The fact that such a convention exist just emphasizes that it _is_ an issue from which people try to sway away. The drawback is that _ is commonly used for translations: http://docs.python.org/lib/node317.html (using f for some function is of course well-established also outside programming, as your nearest dictionary or encyclopedia will tell you. x and i are other letters for which programming use often matches established meanings...) /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
I need a clarification of the argument. Are the opponents saying that I should not be able to: def compose(list_of_functions): return reduce(lambda f, g: lambda x: f(g(x)), list_of_functions) In a nutshell: why? And may I see the proposed better replacement for function composition. Thanks, Alan Isaac -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Alan G Isaac wrote: Are the opponents saying that I should not be able to: def compose(list_of_functions): return reduce(lambda f, g: lambda x: f(g(x)), list_of_functions) In a nutshell: why? I was about to reply, but I couldn't figure out what the piece of code does in the allotted timeframe. /F -- http://mail.python.org/mailman/listinfo/python-list
RE: Is this a good use for lambda
Steven Bethard wrote: Charlie Taylor wrote: I have tried using named functions instead of using lambda functions, however, I always end up with a convoluted, hard to follow mess. ... Well, I think the jury could still be out on which version is more readable, but I don't understand the comment I have tried using named functions instead of using lambda functions, however, I always end up with a convoluted, hard to follow mess. If you know that: name = lambda *args, **kwds: expr is eqivalent to: def name(*args, **kwds): return expr then it's quite straightforward to translate from one to the other. I think that Charlie's point is that, when you use def name, you have name polluting your namespace. The whole program becomes harder to understand because you can't ignore name anywhere, even if it was only ever intended to be used in one place. It's a good point, and reasonable people can disagree about whether the namespace pollution or the unreadability of lambda is a bigger problem. I've used lambda from time to time, but only socially, and I can quit any time I want... -- Walt -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Walter S. Leipold wrote: I think that Charlie's point is that, when you use def name, you have name polluting your namespace. The whole program becomes harder to understand because you can't ignore name anywhere, even if it was only ever intended to be used in one place. Ahem. If you name the function, you can reuse the name (or just forget about it) as soon as you've used the function object. If you don't want to reuse the name because you might want to reuse the function object, you have to name it anyway. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Walter S. Leipold wrote: I've used lambda from time to time, but only socially, and I can quit any time I want... +1 QOTW Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Fredrik Lundh [EMAIL PROTECTED] writes: Walter S. Leipold wrote: I think that Charlie's point is that, when you use def name, you have name polluting your namespace. The whole program becomes harder to understand because you can't ignore name anywhere, even if it was only ever intended to be used in one place. Ahem. If you name the function, you can reuse the name (or just forget about it) as soon as you've used the function object. Sure, but mental pollution counts too IMO. What you write and what you read must go through your brain, including dummy variables. And next you start thinking how to hide it from your own mind (e.g. naming it _my_local_func or something as ugly as the leading underscores in it). And I think that it does, in fact, touch the innermost symbol table too, even if the case is optimized out by the compiler -- is it? Why do something for the sake of not actually having to do it? *** Anyway, personally, this namespace cluttering most often happens because lambda is only a single expression. If one could write a true function block into a lambda, there would be less cases where lambda doesn't suffice, really. Now, if lambda was more than an expr, dumping lambda keyword would be a convenient idea -- unnecessary keywords can make the language less clear in some cases. One could do with Python's plain and simple def, like this: filter (def (x): x*2, myseq) (Disclaimer: Without thinking further I'm not sure whether the above syntax would be unique enough, Python grammar-wise.) br, S -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Simo Melenius wrote: Now, if lambda was more than an expr, dumping lambda keyword would be a convenient idea -- unnecessary keywords can make the language less clear in some cases. One could do with Python's plain and simple def, like this: filter (def (x): x*2, myseq) (Disclaimer: Without thinking further I'm not sure whether the above syntax would be unique enough, Python grammar-wise.) If you'd like to think further about it, check the archves -- there's about a million different arguments about this. A recent brief one (2 days ago): http://mail.python.org/pipermail/python-list/2004-December/255728.html Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Simo Melenius wrote: Ahem. If you name the function, you can reuse the name (or just forget about it) as soon as you've used the function object. Sure, but mental pollution counts too IMO. What you write and what you read must go through your brain, including dummy variables. And next you start thinking how to hide it from your own mind (e.g. naming it _my_local_func or something as ugly as the leading underscores in it). use something short, like f. hopefully, a single character won't overload your brain. And I think that it does, in fact, touch the innermost symbol table too, even if the case is optimized out by the compiler -- is it? yes, but the overhead of keeping a local slot updated is very small, especially compared to all the work Python's doing to create a new function object. (or did you mean that you're trying to keep the entire symbol table in your head? I think my point was that you don't really have to do that; just concentrate on what's close to the code you're reading) Why do something for the sake of not actually having to do it? not sure I parsed that one correctly, but when I name functions, I usually do that because it makes my code cleaner, more self-describing, gives it a better visual layout, makes it easier to modify/maintain, makes it easier to set breakpoints or add debugging statements, etc. lambda blocks can address some of that, but not all of it. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
On Sun, 19 Dec 2004 20:59:43 +0100, Fredrik Lundh [EMAIL PROTECTED] wrote:
Walter S. Leipold wrote:
I think that Charlie's point is that, when you use def name, you have
name polluting your namespace. The whole program becomes harder to
understand because you can't ignore name anywhere, even if it was only
ever intended to be used in one place.
Ahem. If you name the function, you can reuse the name (or just forget about
it)
as soon as you've used the function object.
If you don't want to reuse the name because you might want to reuse the
function
object, you have to name it anyway.
Are you forgetting that all bindings are not directly name bindings as created
by def? ;-)
(See also various tkinter-related uses).
funs = [lambda:'one', lambda:'two', lambda:'three']
for use in xrange(2):
... for i in xrange(3):
... print '%susing fun[%s] = %r' %('re'*(use0), i, funs[i]())
...
using fun[0] = 'one'
using fun[1] = 'two'
using fun[2] = 'three'
reusing fun[0] = 'one'
reusing fun[1] = 'two'
reusing fun[2] = 'three'
Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Bengt Richter wrote:
Ahem. If you name the function, you can reuse the name (or just forget about
it)
as soon as you've used the function object.
If you don't want to reuse the name because you might want to reuse the
function
object, you have to name it anyway.
Are you forgetting that all bindings are not directly name bindings as
created by def? ;-)
(See also various tkinter-related uses).
funs = [lambda:'one', lambda:'two', lambda:'three']
now you've used the function objects once each.
for use in xrange(2):
... for i in xrange(3):
... print '%susing fun[%s] = %r' %('re'*(use0), i, funs[i]())
and now you're using the data structure you built... at this point, it doesnt
matter
if the functions had distinct names to start with.
(coming up with a contrived example where it matters is trivial, of course, but
by
then, we've moved into whitespace or static typing leads to more reliable
code
country)
/F
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Charlie Taylor [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I find that I use lambda functions mainly for callbacks to things like integration or root finding routines as follows. flow = integrate(lambda x: 2.0*pi * d(x)* v(x) * sin(a(x)),xBeg, xEnd) root = findRoot(xBeg, xEnd, lambda x: y2+ lp*(x-x2) -wallFunc( x )[0], tolerance=1.0E-15) To each there own is my philosophy. However, with multiple arguments, I might prefer def f(x): return 2.0*pi * d(x)* v(x) * sin(a(x)) flow = integrate(f, xBeg, xEnd) def g(x): return y2+ lp*(x-x2) -wallFunc( x )[0] root = findRoot(xBeg, xEnd, g, tolerance=1.0E-15) even if I might use lambda initially. (And the above is in no way a 'mess'.) In any case, as soon as one wants to do even two things with a function -- plot and integrate, or integrate with two methods and compare, or ditto with findRoot, or calculate g(root) after findRoot, one will want a separate def statement. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
On Fri, 17 Dec 2004 15:58:09 -0800, Charlie Taylor [EMAIL PROTECTED] wrote: I find that I use lambda functions mainly for callbacks to things like integration or root finding routines as follows. flow = integrate(lambda x: 2.0*pi * d(x)* v(x) * sin(a(x)),xBeg, xEnd) root = findRoot(xBeg, xEnd, lambda x: y2+ lp*(x-x2) -wallFunc( x )[0], tolerance=1.0E-15) I have tried using named functions instead of using lambda functions, however, I always end up with a convoluted, hard to follow mess. Is there a better solution than a lambda in the above situations? Yes. Your code is horribly unreadable. You should not even be allowed near a computer. Your lambdas, in order of definition, should obviously be named twicePiTimesDxVxTimesSinAx and y2PlusLpTimesTheQuantityXLessX2LessWallFuncXOfZero. Please be more careful and attentive in the future. Jp -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Harlin Seritt wrote: Charlie Taylor wrote: I find that I use lambda functions mainly for callbacks to things like integration or root finding routines as follows. flow = integrate(lambda x: 2.0*pi * d(x)* v(x) * sin(a(x)),xBeg, xEnd) root = findRoot(xBeg, xEnd, lambda x: y2+ lp*(x-x2) -wallFunc( x )[0], tolerance=1.0E-15) I have tried using named functions instead of using lambda functions, however, I always end up with a convoluted, hard to follow mess. Is there a better solution than a lambda in the above situations? Yes. Write a separate function for it. It may actually take less time and be a good deal more readable. Also, you'll be able to call this mess again if you need to. :-) Well, I think the jury could still be out on which version is more readable, but I don't understand the comment I have tried using named functions instead of using lambda functions, however, I always end up with a convoluted, hard to follow mess. If you know that: name = lambda *args, **kwds: expr is eqivalent to: def name(*args, **kwds): return expr then it's quite straightforward to translate from one to the other. As an illustration, here are your functions translated from lambdas to defs: def flowfunc(x): return 2.0*pi * d(x)* v(x) * sin(a(x)) flow = integrate(flowfunc, xBeg, xEnd) def rootfunc(x): return y2 + lp*(x - x2) - wallFunc(x)[0] root = findRoot(xBeg, xEnd, rootfunc, tolerance=1.0E-15) I'm not necessarily suggesting that this is the right answer for your situation, just that the translation from lambda to def should be relatively simple if you decide that that's what you want to do. Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this a good use for lambda
Charlie Taylor wrote:
root = findRoot(xBeg, xEnd,
lambda x: y2+ lp*(x-x2) -wallFunc( x )[0], tolerance=1.0E-15)
Um, so which parts of this are the actual lambda?? Just from reading
that, it's hard to be sure. My mind keeps wanting to break at 'lambda
x: y2 + lp*(x-x2)', but when I stop to think about it, I know that it
must be the entire segment between commas ('lambda x: y2 + lp*(x-x2)
-wallFunc( x )[0]').
This is exactly why I don't like using lambdas. Very easy to get
confused by the syntax, and (IMO) not much benefit.
I have tried using named functions instead of using lambda functions,
however, I always end up with a convoluted, hard to follow mess.
See, to my mind, the above is a bit convoluted and hard to follow. I'd
prefer to see something like:
def func(x):
answer = y2 + (lp * (x-x2)) - wallFunc(x)[0]
return answer
root = findRoot(xBeg, xEnd, func, tolerance=1.0E-15)
(I'm hoping, of course, that y2, x2, and lp are local variables, rather
than global variables...)
I find this named function to be much more clear in regards to what's
part of the lambda and what's actually a parameter to findRoot(). I
suppose that opinions may vary, however.
Jeff Shannon
Technician/Programmer
Credit International
--
http://mail.python.org/mailman/listinfo/python-list
