Mailman 3 Search results for "matrix function composition" - Python-ideas

Re: [Python-ideas] Function composition (was no subject)

by Gregory Salvan

Nobody convinced by arrow operator ? like: arg -> spam -> eggs -> cheese or cheese <- eggs <- spam <- arg This also make sense with annotations: def func(x:type1, y:type2) -> type3: pass we expect func to return type3(func(x, y)) 2015-05-09 22:41 GMT+02:00 Gregory Salvan <apieum(a)gmail.com>: > pipeline operator may be confusing with bitwise operator. > In this case : > eggs = arg | spam | cheese > > Is eggs a composed function or string of bits ? > > > 2015-05-09 21:15 GMT+02:00 Koos Zevenhoven <koos.zevenhoven(a)aalto.fi>: > >> >> On 2015-05-09 21:16, Steven D'Aprano wrote: >> >>> On Sat, May 09, 2015 at 11:38:38AM -0400, Ron Adam wrote: >>> >>> How about an operator for partial? >>>> >>>> root @ mean @ map $ square(xs) >>>> >>> Apart from the little matter that Guido has said that $ will never be >>> used as an operator in Python, what is the association between $ and >>> partial? >>> >>> Most other operators have either been used for centuries e.g. + and - or >>> at least decades e.g. * for multiplication because ASCII doesn't have >>> the × symbol. The barrier to using a completely arbitrary symbol with no >>> association to the function it plays should be considered very high. >>> >>> I would only support an operator for function composition if it was at >>> least close to the standard operators used for function composition in >>> other areas. @ at least suggests the ∘ used in mathematics, e.g. >>> sin∘cos, but | is used in pipelining languages and shells and could be >>> considered, e.g. ls | wc. >>> >>> My own preference would be to look at @ as the closest available ASCII >>> symbol to ∘ and use it for left-to-right composition, and | for >>> left-to-right function application. E.g. >>> >>> (spam @ eggs @ cheese)(arg) is equivalent to spam(eggs(cheese(arg))) >>> >>> (spam | eggs | cheese)(arg) is equivalent to cheese(eggs(spam(arg))) >>> >>> also known as compose() and rcompose(). >>> We can read "@" as "of", "spam of eggs of cheese of arg", and | as >>> a pipe, "spam(arg) piped to eggs piped to cheese". >>> >> >> For me these are by far the most logical ones too, for exactly the same >> reasons (and because of the connection of @ with matrix multiplication and >> operators that operate from the left). >> >> It's a pity we can't match the shell syntax and write: >>> >>> spam(args)|eggs|cheese >>> >>> but that would have a completely different meaning. >>> >>> >> >> But it does not need to have a different meaning. You could in addition >> have: >> >> spam @ eggs @ cheese @ arg # equivalent to spam(eggs(cheese(arg))) >> >> arg | spam | eggs | cheese # equivalent to cheese(eggs(spam(arg))) >> >> Here, arg would thus be recognized as not a function. >> >> In this version, your example of spam(args)|eggs|cheese would do exactly >> the same operation as (spam | eggs | cheese)(args) :-). >> >> >> David Beazley has a tutorial on using coroutines in pipelines: >>> >>> http://www.dabeaz.com/coroutines/ >>> >>> where he ends up writing this: >>> >>> f = open("access-log") >>> follow(f, >>> grep('python', >>> printer())) >>> >>> >>> Coroutines grep() and printer() make up the pipeline. I cannot help but >>> feel that the | syntax would be especially powerful for this sort of >>> data processing purpose: >>> >>> # could this work using some form of function composition? >>> follow(f, grep('python')|printer) >>> >>> >>> >>> >> This seems promising! >> >> >> -- Koos >> >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas(a)python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > >

9 years, 6 months

Re: [Python-ideas] [RFC] draft PEP: Dedicated infix operators for matrix multiplication and matrix power

by Antoine Pitrou

On Fri, 14 Mar 2014 14:54:02 +0000 (UTC) Joseph Martinot-Lagarde <joseph.martinot-lagarde(a)m4x.org> wrote: > > Putting aside tha ascii problem, ° is easily written using a AZERTY > keyboard. It is smaller and less convoluted than @ and looks like the > mathematical notation for function composition, which is similar to matrix > multiplication. Perhaps we should keep it for the temperature literals that will appear in Python 4, though :-) Regards Antoine.

10 years, 7 months

Re: [Python-ideas] Add 'composable' decorator to functools (with @ matrix multiplication)

by Ivan Levkivskyi

Dear Yann, The two options that you mentioned are indeed equivalent (the function application is much tighter that @), but note that z would be a partial-like object. Of course for this to work, not only the first function must be decorated with @composable, but also all multi-argument functions. On 6 May 2015 at 21:32, Yann Kaiser <kaiser.yann(a)gmail.com> wrote: > On Wed, 6 May 2015 at 09:10 Ivan Levkivskyi <levkivskyi(a)gmail.com> wrote: > >> Dear Guido, >> >> My original idea was to make the composable functions auto-curried >> (similar to proposed here >> http://code.activestate.com/recipes/52902-function-composition/ as >> pointed out by Steve) so that >> >> my_fun = square @ add(1) >> my_fun(x) >> >> evaluates to >> >> square(add(1,x)) >> > > This breaks the (IMO) fundamental expectation that > > z = add(1) > my_fun = square @ z > > is equivalent to > > my_fun = square @ add(1) > > -Yann >

9 years, 6 months

Re: [Python-ideas] Add 'composable' decorator to functools (with @ matrix multiplication)

by Chris Angelico

On Thu, May 7, 2015 at 2:10 AM, Ivan Levkivskyi <levkivskyi(a)gmail.com> wrote: > Dear Guido, > > My original idea was to make the composable functions auto-curried (similar > to proposed here > http://code.activestate.com/recipes/52902-function-composition/ as pointed > out by Steve) so that > > my_fun = square @ add(1) > my_fun(x) > > evaluates to > > square(add(1,x)) Hmm. This would require that your composable functions autocurry, which may be tricky to do in the general case. It also requires that the right hand function be composable, unlike in your earlier example. ChrisA

9 years, 6 months

Re: [Python-ideas] Partial operator (and 'third-party methods' and 'piping') [was Re: Function composition (was no subject)]

by Nicholas Chammas

> For Python, Fraser pointed out http://xion.io/pyqcy/ and Google tells me there's also https://pypi.python.org/pypi/pytest-quickcheck Don't forget about the latest and greatest Python library for property-based testing, Hypothesis <http://hypothesis.readthedocs.org/en/latest/>! On Mon, May 11, 2015 at 10:16 PM Nick Coghlan <ncoghlan(a)gmail.com> wrote: > On 12 May 2015 at 08:12, Gregory Salvan <apieum(a)gmail.com> wrote: > > Sorry the fun part: the more you write code the less you have to write > > tests. > > I think this is the key for the folks hoping to make the case for > increased support for function composition in the future (it's > definitely too late in the cycle for 3.5): focus on the *pragmatic* > benefits in testability, and argue that this makes up for the *loss* > of readability. "It's easier to read" is *not* a true statement for > anyone that hasn't already learned to think functionally, and "It is > worth your while to learn to think functionally, even if it takes you > years" is a very *different* statement. > > The human brain tends to think procedurally by default (presumably > because our stream of consciousness is typically experienced as a > linear series of events), while object oriented programming can > benefit from analogies with physical objects (especially when taught > via robotics or other embodied systems), and message passing based > concurrent systems can benefit from analogies with human > communications. By contrast, there aren't any easy "interaction with > the physical world" analogies to draw on for functional programming, > so it takes extensive training and practice to teach people to think > in functional terms. Folks with a strong mathematical background > (especially in formal mathematical proofs) often already have that > training (even if they're only novice programmers), while the vast > majority of software developers (even professional ones), don't. > > As a result, I think the more useful perspective to take is the one > taken for the PEP 484 type hinting PEP: positioning function > composition as an advanced tool for providing increased correctness > guarantees for critical components by building them up from > independently tested composable parts, rather than relying on ad hoc > procedural logic that may itself be a source of bugs. Aside from more > accurately reflecting the appropriate role of function composition in > Pythonic development (i.e. as a high barrier to entry technique that > is nevertheless sometimes worth the additional conceptual complexity, > akin to deciding to use metaclasses to solve a problem), it's also > likely to prove beneficial that Guido's recently been on the other > side of this kind of argument when it comes to both type hinting in > PEP 484 and async/await in PEP 492. I assume he'll still remain > skeptical of the value of the trade-off when it comes to further > improvements to Python's functional programming support, but at least > he'll be familiar with the form of the argument :) > > On the "pragmatic benefits in testability" front, I believe one key > tool to focus on is the Quick Check test case generator > (https://wiki.haskell.org/Introduction_to_QuickCheck1) which lets the > test generator take care of determining appropriate boundary > conditions to check based on a specification of the desired externally > visible behaviour of a function, rather than relying on the developer > to manually specify those boundary conditions as particular test > cases. > > I personally learned about that approach earlier this year through a > talk that Fraser Tweedale gave at LCA in January: > > https://speakerdeck.com/frasertweedale/the-best-test-data-is-random-test-da… > & > <https://speakerdeck.com/frasertweedale/the-best-test-data-is-random-test-da…> > https://www.youtube.com/watch?v=p7oRMB5V2kE > > For Python, Fraser pointed out http://xion.io/pyqcy/ and Google tells > me there's also https://pypi.python.org/pypi/pytest-quickcheck > > Gary Bernhardt's work is also worth exploring, including the > "Functional Core, Imperative Shell" model discussed in his > "Boundaries" presentation > (https://www.youtube.com/watch?v=yTkzNHF6rMs) a few years back (an > implementation of this approach is available for Python at > https://pypi.python.org/pypi/nonobvious/). His closing keynote > presentation at PyCon this year was also relevant (relating to the > differences between the assurances that testing can provide vs those > offered by powerful type systems like Idris), but unfortunately not > available online. > > Andrew's recommendation to "approach via NumPy" is also a good one. > Scientific programmers tend to be much better mathematicians than > other programmers (and hence more likely to appreciate the value of > development techniques based on function composition), and the rapid > acceptance of the matrix multiplication PEP shows the scientific > Python community have also become quite skilled at making the case to > python-dev for new language level features of interest to them :) > > Regards, > Nick. > > -- > Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >

9 years, 6 months

Re: [Python-ideas] Add 'composable' decorator to functools (with @ matrix multiplication)

by Yann Kaiser

On Wed, 6 May 2015 at 09:10 Ivan Levkivskyi <levkivskyi(a)gmail.com> wrote: > Dear Guido, > > My original idea was to make the composable functions auto-curried > (similar to proposed here > http://code.activestate.com/recipes/52902-function-composition/ as > pointed out by Steve) so that > > my_fun = square @ add(1) > my_fun(x) > > evaluates to > > square(add(1,x)) > This breaks the (IMO) fundamental expectation that z = add(1) my_fun = square @ z is equivalent to my_fun = square @ add(1) -Yann

9 years, 6 months

Re: [Python-ideas] [RFC] draft PEP: Dedicated infix operators for matrix multiplication and matrix power

by Joseph Martinot-Lagarde

Robert Kern <robert.kern@...> writes: > > On 2014-03-14 13:20, M.-A. Lemburg wrote: > > On 14.03.2014 12:25, Robert Kern wrote: > >> On 2014-03-14 10:16, M.-A. Lemburg wrote: > >> > >>> I have some questions: > >>> > >>> 1. Since in math, the operator is usually spelt "·" (the center dot, > >>> or "." but that's already reserved for methods and attributes in > >>> Python), why not try to use that instead of " <at> " (which in Python > >>> already identifies decorators) ? > >> > >> I think the current feeling of the Python core team is against including non-ASCII characters in the > >> language's keywords or operators. Even if that were not so, I would still recommend against it > >> because it would be quite difficult to type. I don't know off-hand the key combination to do it on > >> my native system, and it would change from system to system. > > > > That's a fair argument. How about using the degree symbol instead: "°" ? > > > > (A ° B).T == B.T ° A.T > > Your point is taken, though. I do find these smaller symbols more readable and > similar to standard mathematical notation than an <at> sign, which is as big or > bigger than most uppercase characters. Unfortunately, ASCII leaves us few > single-character options. > Putting aside tha ascii problem, ° is easily written using a AZERTY keyboard. It is smaller and less convoluted than @ and looks like the mathematical notation for function composition, which is similar to matrix multiplication. Still, not ascii and not displayed on every keyboard...

10 years, 7 months

Re: [Python-ideas] [RFC] draft PEP: Dedicated infix operators for matrix multiplication and matrix power

by Michael Mitchell

I haven't been following this thread too closely, so please stop me if this has been covered, but has overloading the @ operator as function composition been considered yet? An example would be filter(a @ b, lst) as opposed to filter(lambda x: a(b(x)), lst) On Sun, Apr 6, 2014 at 6:51 PM, Nathaniel Smith <njs(a)pobox.com> wrote: > On Mon, Apr 7, 2014 at 12:20 AM, Steven D'Aprano <steve(a)pearwood.info> > wrote: > > On Sun, Apr 06, 2014 at 11:02:00PM +0100, Nathaniel Smith wrote: > >> On Sun, Mar 16, 2014 at 1:05 PM, Nick Coghlan <ncoghlan(a)gmail.com> > wrote: > >> > Aye, but at the moment it makes sense to wait and see if there is even > >> > an argument to be had - Nathaniel may decide that even after reviewing > >> > the question seriously, he doesn't want to propose a right associative > >> > operator :) > >> > >> And indeed, that does seem to be the way things have worked out :-). > >> > http://mail.scipy.org/pipermail/numpy-discussion/2014-April/069834.html > > > > That's a shame in one way -- for anyone using operator overloading to > > define their own DSL, there's only ** if you want a right-associative > > operator to overload. Still, that's an extremely marginal, and > > hypothetical, use-case. Left-associative it is. > > > > Was that the last blocker for the PEP? > > Pretty much. Just posted to python-dev: > https://mail.python.org/pipermail/python-dev/2014-April/133791.html > > -n > > -- > Nathaniel J. Smith > Postdoctoral researcher - Informatics - University of Edinburgh > http://vorpus.org > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >

10 years, 7 months

Re: [Python-ideas] Fwd: [RFC] draft PEP: Dedicated infix operators for matrix multiplication and matrix power

by Robert Kern

On 2014-03-18 08:02, Nick Coghlan wrote: > > On 18 Mar 2014 09:08, "Nathaniel Smith" > <njs(a)pobox.com > <mailto:njs@pobox.com>> wrote: > > > > On Fri, Mar 14, 2014 at 8:15 PM, Nick Coghlan > <ncoghlan(a)gmail.com > <mailto:ncoghlan@gmail.com>> wrote: > > > A few other miscellaneous comments: > > > > > > - nice work on the PEP Nathaniel! > > > > Thanks! > > > > > - as with others, "@" as the operator doesn't thrill me, but I also think it > > > crosses the threshold of "good enough given the constraints" > > > - the PEP should probably recommend adding an "operator.matmul" function, a > > > "PyObject_MatrixMultiply" C API and consider whether or not the new special > > > method should be given a C level type slot. > > > > operator.matmul and PyObject_MatrixMultiply are obvious enough, but > > I'm afraid I'm not too clear on the tradeoffs about adding a C level > > type slot, or even entirely sure what the alternative is. (I guess I > > just assumed that all special methods used C level type slots and > > there was nothing to think about.) Do you (or anyone) have any > > thoughts? > > I suspect you're going to want one, as without it, the implementation method > ends up in the class dict instead (the context management protocol works that way). > > I suspect the design we will want is a new struct for Py_Matrix slots (akin to > those for numbers, etc). The alternative would be to just add more "Number" > slots, but that isn't really accurate. Would it be more palatable if the name were something like __altmul__ or __auxmul__ rather than __matmul__? Really, it's just a second multiplication-like operator. The leading use case for a second multiplication-like operator happens to be matrix multiplication, but I strongly suspect it will get used for other mathematical things like symbolic function composition or operator application (as in "linear operator", not +-*/) and maybe some secondary multiplication types in the weirder groups and fields (you can bet I will resurrect my Clifford algebra module to use this operator for one of the several types of multiplication they support). Granted, there is still some awkwardness in that *none* of the builtin number types will support it. And hey, look! It makes the @ux or @lt multiplication operator makes a sensible, language-independent mnemonic! (not that "auxiliary" or "alternate" work in all languages, but at least the 'a' is baked into the special method name) -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

10 years, 7 months

Re: [Python-ideas] Function composition (was no subject)

by Andrew Barnert

On May 9, 2015, at 16:28, Ivan Levkivskyi <levkivskyi(a)gmail.com> wrote: > > I was thinking about recent ideas discussed here. I also returned back to origins of my initial idea. The point is that it came from Numpy, I use Numpy arrays everyday, and typically I do exactly something like root(mean(square(data))). > > Now I am thinking: what is actually a matrix? It is something that takes a vector and returns a vector. But on the other hand the same actually do elementwise functions. It does not really matter, what we do with a vector: transform by a product of matrices or by composition of functions. In other words I agree with Andrew that "elementwise" is a good match with compose, and what we really need is to "pipe" things that take a vector (or just an iterable) and return a vector (iterable). > > So that probably a good place (in a potential future) for compose would be not functools but itertools. But indeed a good place to test this would be Numpy. Itertools is an interesting idea. Anyway, assuming NumPy isn't going to add this in the near future (has anyone even brought it up on the NumPy list, or only here?), it wouldn't be that hard to write a (maybe inefficient but working) @composable wrapper and wrap all the relevant callables from NumPy or from itertools, upload it to PyPI, and let people start coming up with good examples. If it's later worth direct support in NumPy and/or Python (for simplicity or performance), the module will still be useful for backward compatibility. > An additional comment: it is indeed good to have both @ and | for compose and rcompose. > Side note, one can actually overload __rmatmul__ on arrays as well so that you can write > > root @ mean @ square @ data But this doesn't need to overload it on arrays, only on the utuncs, right? Unless you're suggesting that one of these operations could be a matrix as easily as a function, and NumPy users often won't have to care which it is? > > Moreover, one can overload __or__ on arrays, so that one can write > > data | square | mean | root > > even with ordinary functions (not Numpy's ufuncs or composable) . That's an interesting point. But I think this will be a bit confusing, because now it _does_ matter whether square is a matrix or a function--you'll get elementwise bitwise or instead of application. (And really, this is the whole reason for @ in the first place--we needed an operator that never means elementwise.) Also, this doesn't let you actually compose functions--if you want square | mean | root to be a function, square has to have a __or__ operator. > These examples are actually "flat is better than nested" in the extreme form. > > Anyway, they (Numpy) are going to implement the @ operator for arrays, may be it would be a good idea to check that if something on the left from me (array) is not an array but a callable then apply it elementwise. > > Concerning the multi-argument functions, I don't like $ symbol, don't know why. It seems really unintuitive why it means partial application. > One can autocurry composable functions and apply same rules that Numpy uses for ufuncs. > More precisely, if I write > > add(data1, data2) > > with arrays it applies add pairwise. But if I write > > add(data1, 42) > > it is also fine, it simply adds 42 to every element. With autocurrying one could write > > root @ mean @ add(data) @ square @ data2 > > or > > root @ mean @ square @ add(42) @ data > > However, as I see it now it is not very readable, so that may be the best choise is to reserve @ and | for "piping" iterables through transformers that take one argument. In other words it should be left to user to make add(42) of an appropriate type. It is the same logic as for decorators, if I write > > @modify(arg) > def func(x): > return None > > I must care that modify(arg) evaluates to something that takes one callable and returns a callable. > > >> On May 9, 2015, at 01:36, Stephen J. Turnbull <stephen(a)xemacs.org> wrote: >> > >> > Andrew Barnert writes: >> >>> On May 8, 2015, at 19:58, Stephen J. Turnbull <stephen(a)xemacs.org> wrote: >> >>> >> >>> Koos Zevenhoven writes: >> >>> >> >>>> As a random example, (root @ mean @ square)(x) would produce the right >> >>>> order for rms when using [2]. >> >>> >> >>> Hardly interesting. :-) The result is an exception, as root and square >> >>> are conceptually scalar-to-scalar, while mean is sequence-to-scalar. >> >> >> >> Unless you're using an elementwise square and an array-to-scalar >> >> mean, like the ones in NumPy, >> > >> > Erm, why would square be elementwise and root not? I would suppose >> > that everything is element-wise in Numpy (not a user yet). >> >> Most functions in NumPy are elementwise when applied to arrays, but can also be applied to scalars. So, square is elementwise because it's called on an array, root is scalar because it's called on a scalar. (In fact, root could also be elementwise--aggregating functions like mean can be applied across just one axis of a 2D or higher array, reducing it by one dimension, if you want.) >> >> Before you try it, this sounds like a complicated nightmare that can't possibly work in practice. But play with it for just a few minutes and it's completely natural. (Except for a few cases where you want some array-wide but not element-wise operation, most famously matrix multiplication, which is why we now have the @ operator to play with.) >> >> >> in which case it works perfectly well... >> > >> > But that's an aspect of my point (evidently, obscure). Conceptually, >> > as taught in junior high school or so, root and square are scalar-to- >> > scalar. If you are working in a context such as Numpy where it makes >> > sense to assume they are element-wise and thus composable, the context >> > should provide the compose operator(s). >> >> I was actually thinking on these lines: what if @ didn't work on types.FunctionType, but did work on numpy.ufunc (the name for the "universal function" type that knows how to broadcast across arrays but also work on scalars)? That's something NumPy could implement without any help from the core language. (Methods are a minor problem here, but it's obvious how to solve them, so I won't get into it.) And if it turned out to be useful all over the place in NumPy, that might turn up some great uses for the idiomatic non-NumPy Python, or it might show that, like elementwise addition, it's really more a part of NumPy than of Python. >> >> But of course that's more of a proposal for NumPy than for Python. >> >> > Without that context, Koos's >> > example looks like a TypeError. >> >> >> But Koos's example, even if it was possibly inadvertent, shows that >> >> I may be wrong about that. Maybe compose together with element-wise >> >> operators actually _is_ sufficient for something beyond toy >> >> examples. >> > >> > Of course it is!<wink /> I didn't really think there was any doubt >> > about that. >> >> I think there was, and still is. People keep coming up with abstract toy examples, but as soon as someone tries to give a good real example, it only makes sense with NumPy (Koos's) or with some syntax that Python doesn't have (yours), because to write them with actual Python functions would actually be ugly and verbose (my version of yours). >> >> I don't think that's a coincidence. You didn't write "map square" because you don't know how to think in Python, but because using compose profitably inherently implies not thinking in Python. (Except, maybe, in the case of NumPy... which is a different idiom.) Maybe someone has a bunch of obvious good use cases for compose that don't also require other functions, operators, or syntax we don't have, but so far, nobody's mentioned one. >> >> ------------------------------ >> >> On 5/9/2015 6:19 AM, Andrew Barnert via Python-ideas wrote: >> >> > I think there was, and still is. People keep coming up with abstract toy examples, but as soon as someone tries to give a good real example, it only makes sense with NumPy (Koos's) or with some syntax that Python doesn't have (yours), because to write them with actual Python functions would actually be ugly and verbose (my version of yours). >> > >> > I don't think that's a coincidence. You didn't write "map square" because you don't know how to think in Python, but because using compose profitably inherently implies not thinking in Python. (Except, maybe, in the case of NumPy... which is a different idiom.) Maybe someone has a bunch of obvious good use cases for compose that don't also require other functions, operators, or syntax we don't have, but so far, nobody's mentioned one. >> >> I agree that @ is most likely to be usefull in numpy's restricted context. >> >> A composition operator is usually defined by application: f@g(x) is >> defined as f(g(x)). (I sure there are also axiomatic treatments.) It >> is an optional syntactic abbreviation. It is most useful in a context >> where there is one set of data objects, such as the real numbers, or one >> set + arrays (vectors) defined on the one set; where all function are >> univariate (or possible multivariate, but that can can be transformed to >> univariate on vectors); *and* where parameter names are dummies like >> 'x', 'y', 'z', or '_'. >> >> The last point is important. Abbreviating h(x) = f(g(x)) with h = f @ g >> does not lose any information as 'x' is basically a placeholder (so get >> rid of it). But parameter names are important in most practical >> contexts, both for understanding a composition and for using it. >> >> dev npv(transfers, discount): >> '''Return the net present value of discounted transfers. >> >> transfers: finite iterable of amounts at constant intervals >> discount: fraction per interval >> ''' >> divisor = 1 + discount >> return sum(tranfer/divisor**time >> for time, transfer in enumerate(transfers)) >> >> Even if one could replace the def statement with >> npv = <some combination of @, sum, map, add, div, power, enumerate, ...> >> with parameter names omitted, it would be harder to understand. Using >> it would require the ability to infer argument types and order from the >> composed expression. >> >> I intentionally added a statement to calculate the common subexpression >> prior to the return. I believe it would have to put back in the return >> expression before converting. >> >> -- >> Terry Jan Reedy >> >> >> >> ------------------------------ >> >> On 05/09/2015 03:21 AM, Andrew Barnert via Python-ideas wrote: >> >> >I suppose you could write (root @ mean @ (map square)) (xs), >> >> > Actually, you can't. You could write (root @ mean @ partial(map, >> > square))(xs), but that's pretty clearly less readable than >> > root(mean(map(square, xs))) or root(mean(x*x for x in xs). And that's >> > been my main argument: Without a full suite of higher-level operators >> > and related syntax, compose alone doesn't do you any good except for toy >> > examples. >> >> How about an operator for partial? >> >> root @ mean @ map $ square(xs) >> >> >> Actually I'd rather reuse the binary operators. (I'd be happy if they were >> just methods on bytes objects BTW.) >> >> compose(root, mean, map(square, xs)) >> >> root ^ mean ^ map & square (xs) >> >> root ^ mean ^ map & square ^ xs () >> >> Read this as... >> >> compose root, of mean, of map with square, of xs >> >> Or... >> >> apply(map(square, xs), mean, root) >> >> map & square | mean | root (xs) >> >> xs | map & square | mean | root () >> >> >> Read this as... >> >> apply xs, to map with square, to mean, to root >> >> >> These are kind of cool, but does it make python code easier to read? That >> seems like it may be subjective depending on the amount of programming >> experience someone has. >> >> Cheers, >> Ron >> >> >> >> ------------------------------ >> >> Hi, >> I had to answer some of these questions when I wrote Lawvere: >> https://pypi.python.org/pypi/lawvere >> >> First, there is two kind of composition: pipe and circle so I think a >> single operator like @ is a bit restrictive. >> I like "->" and "<-" >> >> Then, for function name and function to string I had to introduce function >> signature (a tuple). >> It provides a good tool for decomposition, introspection and comparison in >> respect with mathematic definition. >> >> Finally, for me composition make sense when you have typed functions >> otherwise it can easily become a mess and this make composition tied to >> multiple dispatch. >> >> I really hope composition will be introduced in python but I can't see how >> it be made without rethinking a good part of function definition. >> >> >> >> 2015-05-09 17:38 GMT+02:00 Ron Adam <ron3200(a)gmail.com>: >> >> > >> > >> > On 05/09/2015 03:21 AM, Andrew Barnert via Python-ideas wrote: >> > >> >> >I suppose you could write (root @ mean @ (map square)) (xs), >> >>> >> >> >> > Actually, you can't. You could write (root @ mean @ partial(map, >> >> square))(xs), but that's pretty clearly less readable than >> >> root(mean(map(square, xs))) or root(mean(x*x for x in xs). And that's >> >> been my main argument: Without a full suite of higher-level operators >> >> and related syntax, compose alone doesn't do you any good except for toy >> >> examples. >> >> >> > >> > How about an operator for partial? >> > >> > root @ mean @ map $ square(xs) >> > >> > >> > Actually I'd rather reuse the binary operators. (I'd be happy if they >> > were just methods on bytes objects BTW.) >> > >> > compose(root, mean, map(square, xs)) >> > >> > root ^ mean ^ map & square (xs) >> > >> > root ^ mean ^ map & square ^ xs () >> > >> > Read this as... >> > >> > compose root, of mean, of map with square, of xs >> > >> > Or... >> > >> > apply(map(square, xs), mean, root) >> > >> > map & square | mean | root (xs) >> > >> > xs | map & square | mean | root () >> > >> > >> > Read this as... >> > >> > apply xs, to map with square, to mean, to root >> > >> > >> > These are kind of cool, but does it make python code easier to read? That >> > seems like it may be subjective depending on the amount of programming >> > experience someone has. >> > >> > Cheers, >> > Ron >> > >> > > > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/

9 years, 6 months

Python-ideas search results for query "matrix function composition"