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

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

by Steven D'Aprano

On Wed, May 06, 2015 at 03:15:38PM +0200, Ivan Levkivskyi wrote: > Dear all, > > The matrix multiplication operator @ is going to be introduced in Python > 3.5 and I am thinking about the following idea: > > The semantics of matrix multiplication is the composition of the > corresponding linear transformations. > A linear transformation is a particular example of a more general concept - > functions. > The latter are frequently composed with ("wrap") each other. For example: > > plot(real(sqrt(data))) > > However, it is not very readable in case of many wrapping layers. > Therefore, it could be useful to employ > the matrix multiplication operator @ for indication of function > composition. This could be done by such (simplified) decorator: I like the idea of @ as a function compose operator. There have been many requests and attempts at support for function composition: http://code.activestate.com/recipes/574458-composable-functions/ http://code.activestate.com/recipes/52902-function-composition/ http://code.activestate.com/recipes/528929-dynamic-function-composition-dec… http://blog.o1iver.net/2011/08/09/python-function-composition.html https://mail.python.org/pipermail/python-dev/2009-August/091161.html http://stackoverflow.com/questions/2281693/is-it-a-good-idea-to-have-a-synt… The last one is notable, as it floundered in part on the lack of a good operator. I think @ makes a good operator for function composition. I think that there are some questions that would need to be answered. For instance, given some composition: f = math.sin @ (lambda x: x**2) what would f.__name__ return? What about str(f)? Do the composed functions: (spam @ eggs @ cheese)(x) perform acceptibly compared to the traditional syntax? spam(eggs(cheese(x)) -- Steve

8 years, 11 months

Add 'composable' decorator to functools (with @ matrix multiplication)

by Ivan Levkivskyi

Dear all, The matrix multiplication operator @ is going to be introduced in Python 3.5 and I am thinking about the following idea: The semantics of matrix multiplication is the composition of the corresponding linear transformations. A linear transformation is a particular example of a more general concept - functions. The latter are frequently composed with ("wrap") each other. For example: plot(real(sqrt(data))) However, it is not very readable in case of many wrapping layers. Therefore, it could be useful to employ the matrix multiplication operator @ for indication of function composition. This could be done by such (simplified) decorator: class composable: def __init__(self, func): self.func = func def __call__(self, arg): return self.func(arg) def __matmul__(self, other): def composition(*args, **kwargs): return self.func(other(*args, **kwargs)) return composable(composition) I think using such decorator with functions that are going to be deeply wrapped could improve readability. You could compare (note that only the outermost function should be decorated): plot(sorted(sqrt(real(data_array)))) vs. (plot @ sorted @ sqrt @ real) (data_array) I think the latter is more readable, also compare def sunique(lst): return sorted(list(set(lst))) vs. sunique = sorted @ list @ set Apart from readability, there are following pros of the proposed decorator: 1. Similar semantics as for matrix multiplication. 2. Same symbol for composition as for decorators. 3. The symbol @ resembles mathematical notation for function composition: ∘ I think it could be a good idea to add such a decorator to the stdlib functools module.

8 years, 11 months

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

by Erik Bray

On Wed, May 6, 2015 at 9:20 AM, Ivan Levkivskyi <levkivskyi(a)gmail.com> wrote: > Dear all, > > The matrix multiplication operator @ is going to be introduced in Python 3.5 > and I am thinking about the following idea: > > The semantics of matrix multiplication is the composition of the > corresponding linear transformations. > A linear transformation is a particular example of a more general concept - > functions. > The latter are frequently composed with ("wrap") each other. For example: > > plot(real(sqrt(data))) > > However, it is not very readable in case of many wrapping layers. Therefore, > it could be useful to employ > the matrix multiplication operator @ for indication of function composition. > This could be done by such (simplified) decorator: > > class composable: > > def __init__(self, func): > self.func = func > > def __call__(self, arg): > return self.func(arg) > > def __matmul__(self, other): > def composition(*args, **kwargs): > return self.func(other(*args, **kwargs)) > return composable(composition) > > I think using such decorator with functions that are going to be deeply > wrapped > could improve readability. > You could compare (note that only the outermost function should be > decorated): > > plot(sorted(sqrt(real(data_array)))) vs. (plot @ sorted @ sqrt @ real) > (data_array) > > I think the latter is more readable, also compare > > def sunique(lst): > return sorted(list(set(lst))) > > vs. > > sunique = sorted @ list @ set > > Apart from readability, there are following pros of the proposed decorator: > > 1. Similar semantics as for matrix multiplication. > 2. Same symbol for composition as for decorators. > 3. The symbol @ resembles mathematical notation for function composition: ∘ > > I think it could be a good idea to add such a decorator to the stdlib > functools module. In the astropy.modeling package, which consists largely of collection of fancy wrappers around analytic functions, we used the pipe operator | (that is, __or__) to implement function composition, as demonstrated here: http://docs.astropy.org/en/stable/modeling/compound-models.html#model-compo… I do like the idea of using the new @ operator for this purpose--it makes sense as a generalization of linear operators, and it just looks a little more like the circle operator often used for functional composition. On the other hand I'm also fond of the choice to use |, for the similarity to UNIX shell pipe operations, as long as it can't be confused with __or__. Point being something like this could be implemented now with __or__. I think this is simple enough that it doesn't need to be in the stdlib, especially if there are different ways people would like to do this. But I do like the idea. Erik

8 years, 11 months

(no subject)

by Ivan Levkivskyi

Dear all, The matrix multiplication operator @ is going to be introduced in Python 3.5 and I am thinking about the following idea: The semantics of matrix multiplication is the composition of the corresponding linear transformations. A linear transformation is a particular example of a more general concept - functions. The latter are frequently composed with ("wrap") each other. For example: plot(real(sqrt(data))) However, it is not very readable in case of many wrapping layers. Therefore, it could be useful to employ the matrix multiplication operator @ for indication of function composition. This could be done by such (simplified) decorator: class composable: def __init__(self, func): self.func = func def __call__(self, arg): return self.func(arg) def __matmul__(self, other): def composition(*args, **kwargs): return self.func(other(*args, **kwargs)) return composable(composition) I think using such decorator with functions that are going to be deeply wrapped could improve readability. You could compare (note that only the outermost function should be decorated): plot(sorted(sqrt(real(data_array)))) vs. (plot @ sorted @ sqrt @ real) (data_array) I think the latter is more readable, also compare def sunique(lst): return sorted(list(set(lst))) vs. sunique = sorted @ list @ set Apart from readability, there are following pros of the proposed decorator: 1. Similar semantics as for matrix multiplication. 2. Same symbol for composition as for decorators. 3. The symbol @ resembles mathematical notation for function composition: ∘ I think it could be a good idea to add such a decorator to the stdlib functools module.

8 years, 11 months

Re: [Python-ideas] Function composition

by Ivan Levkivskyi

Dear Steve, Thank you for the feedback and for the links! I think that both (f(a)g).__name__ and str(f@g) should be f.__name__ + ' @ ' + g.__name__ and str(f) + ' @ ' +str(g) Concerning the performance, I think that it could be poor, and I don't know yet how to improve this. > > Dear all, > > > > The matrix multiplication operator @ is going to be introduced in Python > > 3.5 and I am thinking about the following idea: > > > > The semantics of matrix multiplication is the composition of the > > corresponding linear transformations. > > A linear transformation is a particular example of a more general concept - > > functions. > > The latter are frequently composed with ("wrap") each other. For example: > > > > plot(real(sqrt(data))) > > > > However, it is not very readable in case of many wrapping layers. > > Therefore, it could be useful to employ > > the matrix multiplication operator @ for indication of function > > composition. This could be done by such (simplified) decorator: > > I like the idea of @ as a function compose operator. > > There have been many requests and attempts at support for function > composition: > > http://code.activestate.com/recipes/574458-composable-functions/ > > http://code.activestate.com/recipes/52902-function-composition/ > > http://code.activestate.com/recipes/528929-dynamic-function-composition-dec… > > http://blog.o1iver.net/2011/08/09/python-function-composition.html > > https://mail.python.org/pipermail/python-dev/2009-August/091161.html > > http://stackoverflow.com/questions/2281693/is-it-a-good-idea-to-have-a-synt… > > > The last one is notable, as it floundered in part on the lack of a good > operator. I think @ makes a good operator for function composition. > > > I think that there are some questions that would need to be answered. > For instance, given some composition: > > f = math.sin @ (lambda x: x**2) > > what would f.__name__ return? What about str(f)? > > > Do the composed functions: > > (spam @ eggs @ cheese)(x) > > perform acceptibly compared to the traditional syntax? > > spam(eggs(cheese(x)) > > > > -- > Steve

8 years, 11 months

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

by Andrew Barnert

On Mar 23, 2014, at 3:51, Devin Jeanpierre <jeanpierreda(a)gmail.com> wrote: > On Sun, Mar 23, 2014 at 3:40 AM, Sturla Molden <sturla.molden(a)gmail.com> wrote: >> On 15/03/14 01:09, Antoine Pitrou wrote: >> >>> Really? That should be up to the third-party library implementing the @ >>> operator for its types, not to the language itself: Python _suggests_ >>> an use case for @, it doesn't mandate it (especially as there's no >>> appropriate data type in the stdlib). >> >> >> array.array is an appropriate type for supporting @ for matrix >> multiplication. > > I was thinking the function type, as a composition operator. Matrix > multiplication corresponds exactly with composition of linear > functions, so it makes some sort of sense. And it has some kind of > neat similarity to decorators, which generalize function composition. > > If you rename "matmul" to "compose" and "matpow" to something like > "iterate" (except less confusing), then you've generalized the > operators a little and given them more potential use cases. This sounds nice from a purity point of view, but I'm not sure it's a good idea. First, matrix multiplication only corresponds exactly with function composition if matrix*vector multiplication corresponds exactly with function calling, which is generally not true in programming. You can't assign a matrix to f, then write f(v) to apply the matrix as an operation; you write f @ v. Meanwhile, Python doesn't even have compose in functools, much less in builtins, and I don't think anyone had seriously proposed it in decades. If we don't even need it in the stdlib, do we really need is as an operator? Also, is it right-compose or left-compose? (That is, does (f@g)(2) call f then g, or g then f?) One answer is obvious to people who think mathematically, the other to novices. And even if you argue that the right answer to that is to teach the novices the right way to think about it clearly, reverse composition is still often useful; that's why many languages that have a compose function or operator also have rcompose and/or make it trivial to write as flip(compose). Also, how exactly do you define compose? This is easy in a language like Haskell, where every function takes one argument and returns one value (which, because of currying, may actually be a function that takes the next argument...), but in Python, where functions can take any number of arguments, with default values and *args and keyword-only arguments and so on, it's a lot less clear. Does the second function need to be a single-argument function, or do tuple returns match to *args, or something different? Different third-party function libraries use different answers to that, sometimes offering more than one under different names, but obviously the operator has to be either compose1 or composestar, and then the other one won't even be in the stdlib? Meanwhile, looking at languages that care about mathematical purity and about functional composition: you don't write . for matrix multiplication in Haskell, you write `multStd` or, more likely, define *, **, `mult`, or something else more readable.

10 years, 1 month

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

by Ivan Levkivskyi

Dear Erik, Thank you for the link! I agree that this idea is too raw for stdlib (there are problems with many argument functions, keyword arguments, etc.) Concerning the shell | vs. matrix @ I think it is a good idea to have both... but with different order. I mean in shell logic f | g means g (f (x)), while for matrix multiplication f @ g means f(g(x)). The former is probably more natural for people with more "programming" background, while the latter is more natural for people with a "scientific" background. We could now do good for both, since we now have a new operator. On 6 May 2015 at 16:10, Erik Bray <erik.m.bray(a)gmail.com> wrote: > On Wed, May 6, 2015 at 9:20 AM, Ivan Levkivskyi <levkivskyi(a)gmail.com> > wrote: > > Dear all, > > > > The matrix multiplication operator @ is going to be introduced in Python > 3.5 > > and I am thinking about the following idea: > > > > The semantics of matrix multiplication is the composition of the > > corresponding linear transformations. > > A linear transformation is a particular example of a more general > concept - > > functions. > > The latter are frequently composed with ("wrap") each other. For example: > > > > plot(real(sqrt(data))) > > > > However, it is not very readable in case of many wrapping layers. > Therefore, > > it could be useful to employ > > the matrix multiplication operator @ for indication of function > composition. > > This could be done by such (simplified) decorator: > > > > class composable: > > > > def __init__(self, func): > > self.func = func > > > > def __call__(self, arg): > > return self.func(arg) > > > > def __matmul__(self, other): > > def composition(*args, **kwargs): > > return self.func(other(*args, **kwargs)) > > return composable(composition) > > > > I think using such decorator with functions that are going to be deeply > > wrapped > > could improve readability. > > You could compare (note that only the outermost function should be > > decorated): > > > > plot(sorted(sqrt(real(data_array)))) vs. (plot @ sorted @ sqrt @ real) > > (data_array) > > > > I think the latter is more readable, also compare > > > > def sunique(lst): > > return sorted(list(set(lst))) > > > > vs. > > > > sunique = sorted @ list @ set > > > > Apart from readability, there are following pros of the proposed > decorator: > > > > 1. Similar semantics as for matrix multiplication. > > 2. Same symbol for composition as for decorators. > > 3. The symbol @ resembles mathematical notation for function > composition: ∘ > > > > I think it could be a good idea to add such a decorator to the stdlib > > functools module. > > In the astropy.modeling package, which consists largely of collection > of fancy wrappers around analytic functions, > we used the pipe operator | (that is, __or__) to implement function > composition, as demonstrated here: > > > http://docs.astropy.org/en/stable/modeling/compound-models.html#model-compo… > > I do like the idea of using the new @ operator for this purpose--it > makes sense as a generalization of linear operators, > and it just looks a little more like the circle operator often used > for functional composition. On the other hand > I'm also fond of the choice to use |, for the similarity to UNIX shell > pipe operations, as long as it can't be confused with > __or__. Point being something like this could be implemented now with > __or__. > > I think this is simple enough that it doesn't need to be in the > stdlib, especially if there are different ways people > would like to do this. But I do like the idea. > > Erik >

8 years, 11 months

Re: [Python-ideas] (no subject)

by Andrew Barnert

This was discussed when the proposal to add @ for matrix multiplication came up, so you should first read that thread and make sure you have answers to all of the issues that came up before proposing it again. Off the top of my head: Python functions don't just take 1 parameter, they take any number of parameters, possibly including optional parameters, keyword-only, *args, **kwargs, etc. There are a dozen different compose implementations on PyPI and ActiveState that handle these differently. Which one is "right"? The design you describe can be easily implemented as a third-party library. Why not do so, put it on PyPI, see if you get any traction and any ideas for improvement, and then suggest it for the stdlib? The same thing is already doable today using a different operator--and, again, there are a dozen implementations. Why isn't anyone using them? Thinking in terms of function composition requires a higher level of abstraction than thinking in terms of lambda expressions. That's one of the reasons people perceive Haskell to be a harder language to learn than Lisp or Python. Of course learning Haskell is rewarding--but being easy to learn is one of Python's major strengths. Python doesn't have a static optimizing compiler that can avoid building 4 temporary function objects to evaluate (plot @ sorted @ sqrt @ real) (data_array), so it will make your code significantly less efficient. Is @ for composition and () for application really sufficient to write point free code in general without auto-curried functions, operator sectioning, reverse compose, reverse apply, etc.? Most of the examples people use in describing the feature from Haskell have a (+ 1) or (== x) or take advantage of map-type functions being (a->b) -> ([a] -> [b]) instead of (a->b, [a]) -> [b]. Sent from my iPhone > On May 6, 2015, at 06:15, Ivan Levkivskyi <levkivskyi(a)gmail.com> wrote: > > Dear all, > > The matrix multiplication operator @ is going to be introduced in Python 3.5 and I am thinking about the following idea: > > The semantics of matrix multiplication is the composition of the corresponding linear transformations. > A linear transformation is a particular example of a more general concept - functions. > The latter are frequently composed with ("wrap") each other. For example: > > plot(real(sqrt(data))) > > However, it is not very readable in case of many wrapping layers. Therefore, it could be useful to employ > the matrix multiplication operator @ for indication of function composition. This could be done by such (simplified) decorator: > > class composable: > > def __init__(self, func): > self.func = func > > def __call__(self, arg): > return self.func(arg) > > def __matmul__(self, other): > def composition(*args, **kwargs): > return self.func(other(*args, **kwargs)) > return composable(composition) > > I think using such decorator with functions that are going to be deeply wrapped > could improve readability. > You could compare (note that only the outermost function should be decorated): > > plot(sorted(sqrt(real(data_array)))) vs. (plot @ sorted @ sqrt @ real) (data_array) > > I think the latter is more readable, also compare > > def sunique(lst): > return sorted(list(set(lst))) > > vs. > > sunique = sorted @ list @ set > > Apart from readability, there are following pros of the proposed decorator: > > 1. Similar semantics as for matrix multiplication. > 2. Same symbol for composition as for decorators. > 3. The symbol @ resembles mathematical notation for function composition: ∘ > > I think it could be a good idea to add such a decorator to the stdlib functools module. > _______________________________________________ > 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/

8 years, 11 months

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

by Erik Bray

On Wed, May 6, 2015 at 11:21 AM, Ivan Levkivskyi <levkivskyi(a)gmail.com> wrote: > Dear Erik, > > Thank you for the link! I agree that this idea is too raw for stdlib (there > are problems with many argument functions, keyword arguments, etc.) > Concerning the shell | vs. matrix @ I think it is a good idea to have > both... but with different order. > I mean in shell logic f | g means g (f (x)), while for matrix multiplication > f @ g means f(g(x)). > The former is probably more natural for people with more "programming" > background, while the latter is more natural for people with a "scientific" > background. > We could now do good for both, since we now have a new operator. Absolutely! I've found that it takes a little work sometimes for scientific users to wrap their heads around the g | f syntax. Once Python 3.5 is out I might add support for "f @ g" as well, though I'm wary of having more than one way to do it. Worth trying out though, so thanks for the idea. Erik > On 6 May 2015 at 16:10, Erik Bray <erik.m.bray(a)gmail.com> wrote: >> >> On Wed, May 6, 2015 at 9:20 AM, Ivan Levkivskyi <levkivskyi(a)gmail.com> >> wrote: >> > Dear all, >> > >> > The matrix multiplication operator @ is going to be introduced in Python >> > 3.5 >> > and I am thinking about the following idea: >> > >> > The semantics of matrix multiplication is the composition of the >> > corresponding linear transformations. >> > A linear transformation is a particular example of a more general >> > concept - >> > functions. >> > The latter are frequently composed with ("wrap") each other. For >> > example: >> > >> > plot(real(sqrt(data))) >> > >> > However, it is not very readable in case of many wrapping layers. >> > Therefore, >> > it could be useful to employ >> > the matrix multiplication operator @ for indication of function >> > composition. >> > This could be done by such (simplified) decorator: >> > >> > class composable: >> > >> > def __init__(self, func): >> > self.func = func >> > >> > def __call__(self, arg): >> > return self.func(arg) >> > >> > def __matmul__(self, other): >> > def composition(*args, **kwargs): >> > return self.func(other(*args, **kwargs)) >> > return composable(composition) >> > >> > I think using such decorator with functions that are going to be deeply >> > wrapped >> > could improve readability. >> > You could compare (note that only the outermost function should be >> > decorated): >> > >> > plot(sorted(sqrt(real(data_array)))) vs. (plot @ sorted @ sqrt @ real) >> > (data_array) >> > >> > I think the latter is more readable, also compare >> > >> > def sunique(lst): >> > return sorted(list(set(lst))) >> > >> > vs. >> > >> > sunique = sorted @ list @ set >> > >> > Apart from readability, there are following pros of the proposed >> > decorator: >> > >> > 1. Similar semantics as for matrix multiplication. >> > 2. Same symbol for composition as for decorators. >> > 3. The symbol @ resembles mathematical notation for function >> > composition: ∘ >> > >> > I think it could be a good idea to add such a decorator to the stdlib >> > functools module. >> >> In the astropy.modeling package, which consists largely of collection >> of fancy wrappers around analytic functions, >> we used the pipe operator | (that is, __or__) to implement function >> composition, as demonstrated here: >> >> >> http://docs.astropy.org/en/stable/modeling/compound-models.html#model-compo… >> >> I do like the idea of using the new @ operator for this purpose--it >> makes sense as a generalization of linear operators, >> and it just looks a little more like the circle operator often used >> for functional composition. On the other hand >> I'm also fond of the choice to use |, for the similarity to UNIX shell >> pipe operations, as long as it can't be confused with >> __or__. Point being something like this could be implemented now with >> __or__. >> >> I think this is simple enough that it doesn't need to be in the >> stdlib, especially if there are different ways people >> would like to do this. But I do like the idea. >> >> Erik > >

8 years, 11 months

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

by Devin Jeanpierre

On Sun, Mar 23, 2014 at 3:40 AM, Sturla Molden <sturla.molden(a)gmail.com> wrote: > On 15/03/14 01:09, Antoine Pitrou wrote: > >> Really? That should be up to the third-party library implementing the @ >> operator for its types, not to the language itself: Python _suggests_ >> an use case for @, it doesn't mandate it (especially as there's no >> appropriate data type in the stdlib). > > > array.array is an appropriate type for supporting @ for matrix > multiplication. I was thinking the function type, as a composition operator. Matrix multiplication corresponds exactly with composition of linear functions, so it makes some sort of sense. And it has some kind of neat similarity to decorators, which generalize function composition. If you rename "matmul" to "compose" and "matpow" to something like "iterate" (except less confusing), then you've generalized the operators a little and given them more potential use cases. -- Devin

10 years, 1 month

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