[Python-ideas] Re: Double "at" operator for matmul exponentiation
> On 5 Jul 2023, at 21:07, Chris Angelico wrote: > > On Thu, 6 Jul 2023 at 04:02, Dom Grigonis wrote: >> What I would alternatively propose is to introduce a couple of (meaningless >> operators), so that library developers can make use of them as they wish. >> What characters aren't used? “$, ?, `” (or are they?). >> > > What should their precedences be? Operators have to be given that, at > least. Unfortunately, whatever precedence you choose, it's going to be > awkwardly wrong for at least some potential use-cases. Lowest precedence? a + b + c ?op? a / b / c a + b + (c ?op? a) / b / c As this in theory is the highest level operator, given it would mostly be used in framework level packages, it’s precedence naturally begs for the lowest status. But yes, then this would limit the operator to certain use cases. E.g. it wouldn’t be suitable to solve the problem of OP. > That said, though, there are some pretty cool packages out there that > create arbitrary operators. Some of them take advantage of multiple > operators to allow multiple effective precedences. Consider for > example: > https://pypi.org/project/infix/ Infix operator is where my though process began in the first place - see the e-mail. My proposal is exactly to have a free operator to be used in packages such as the one you pointed to. Ok, so Infix works in the way that operands can not recognise object in between operators, so that it falls to `dunders` of the object between operators. Although this works, there would be more flexibility if both the operands and operator class had `free` operator implementation space. Some new patterns might arise. It would be cleaner approach, currently `Infix` feels a bit hacky to me due to reusing of operators, which have another purpose. > ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/YQDJ5UMH23FYL5FVFNBLWPOROD5ZZQOG/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RVAKUXJ53QUBWFBGOSWTHP47HE3C4GCR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Double "at" operator for matmul exponentiation
On Thu, 6 Jul 2023 at 04:02, Dom Grigonis wrote: > What I would alternatively propose is to introduce a couple of (meaningless > operators), so that library developers can make use of them as they wish. > What characters aren't used? “$, ?, `” (or are they?). > What should their precedences be? Operators have to be given that, at least. Unfortunately, whatever precedence you choose, it's going to be awkwardly wrong for at least some potential use-cases. That said, though, there are some pretty cool packages out there that create arbitrary operators. Some of them take advantage of multiple operators to allow multiple effective precedences. Consider for example: https://pypi.org/project/infix/ ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/YQDJ5UMH23FYL5FVFNBLWPOROD5ZZQOG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Double "at" operator for matmul exponentiation
From perspective of calculation time of matrix multiplications Infix operators
is a reasonable solution to define a subset of your own.
https://doc.sagemath.org/html/en/reference/misc/sage/misc/decorators.html#sage.misc.decorators.infix_operator
The problem is that if one implements it, there has to be a substitution at the
expense of loosing a default operator. In scientific libraries this isn't great
as all existing operators tend to be used.
What I would alternatively propose is to introduce a couple of (meaningless
operators), so that library developers can make use of them as they wish. What
characters aren't used? “$, ?, `” (or are they?).
A $pow$ 3- meh
A ?pow? 3- looks ok. The question mark is appropriately marking
ambiguous/implementation dependent meaning.
A `pow` 3 - looks good
A @@ 3 - doesn’t look too great...
A.pow(3) - nice
If I was lacking just one operator (especially in such case where different
algorithms can be used), A.pow(-1, inv_type=‘LU') feels most convenient given
flexibility of arguments.
If I was to go heavy on operators in matrix algebra or defining some sort of
new syntax, then @@ wouldn’t help anyways - it’s just one (and fairly awful
looking).
> On 5 Jul 2023, at 13:02, ha...@interia.pl wrote:
>
>
> Python has the "star" ("*") operator for multiplication. In the context of
> collections it is supposed to mean element-wise multiplication. Its
> associated operator is __mul__. It also has the double star ("**") operator
> for exponentiation, which is repeated multiplication. Its associated operator
> is __exp__.
>
> In addition to that Python has the "at" ("@") operator for multiplication. In
> the context of collections it should mean linear product, like matrix times a
> matrix, or matrix times vector. Its associated method is __matmul__.
>
> For completeness we should now have the exponentiation operator meaning
> repeated application of the "at" operator. Its method could me __matexp__.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/AS3F4V4PCR4EUMYGC7HEECQHAFUVNU2M/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/F7ZNL3FCVY7HAXGB52D5HOOFG2RQFA7B/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Double "at" operator for matmul exponentiation
None of the other repeated infix operators follow the same "repeated application" relation that * and ** have, i.e. // isn't repeated division, << and >> aren't repeated inequality comparisons (whathever that may be), and == isn't repeated assignment. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/X6JVECQNENCOWXVVAXMMOYXW2HXR365G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Double "at" operator for matmul exponentiation
On Wed, 5 Jul 2023 at 11:18, wrote:
>
>
> Python has the "star" ("*") operator for multiplication. In the context of
> collections it is supposed to mean element-wise multiplication. Its
> associated operator is __mul__. It also has the double star ("**") operator
> for exponentiation, which is repeated multiplication. Its associated operator
> is __exp__.
>
> In addition to that Python has the "at" ("@") operator for multiplication. In
> the context of collections it should mean linear product, like matrix times a
> matrix, or matrix times vector. Its associated method is __matmul__.
>
> For completeness we should now have the exponentiation operator meaning
> repeated application of the "at" operator. Its method could me __matexp__.
This was discussed at the time of the PEP that introduced matmul:
https://peps.python.org/pep-0465/#non-definition-of-matrix-power
Quote:
"""
Earlier versions of this PEP also proposed a matrix power operator,
@@, analogous to **. But on further consideration, it was decided that
the utility of this was sufficiently unclear that it would be better
to leave it out for now, and only revisit the issue if – once we have
more experience with @ – it turns out that @@ is truly missed.
"""
It has been nearly 10 years which I guess is enough time to revisit
but most likely the numpy-discussion mailing list is the place to
start that discussion:
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
I think that the original authors wanted @@ and also other operators.
At the time there had been previous more ambitious PEPs proposing many
more operators or custom operators but those were rejected at least
partly for being too broad. As I remember it there was a conscious
effort to make PEP 465 as minimal as possible just to make sure that
at least the @ operator got accepted.
Matrix powers are not as widely used as matrix multiplication and
probably the most common use would be M@@-1 as a strange looking
version of M^-1 which would otherwise be spelled as np.linalg.inv(M).
It is usually a bad idea to compute matrix inverses though
(np.linalg.solve(a, b) is both faster and more accurate than
np.linalg.inv(a)*b). Matlab uses left and right division like a\b and
a/b for this but NumPy etc already define a/b to mean elementwise
division and then having a new operator a\b mean something completely
different from a/b might be confusing.
I think that the people who would have wanted to push forward with
things like this have probably reduced the scope of what seems
possible to the extent that the only thing left to do is to possibly
add @@. If that is all that is on the table then it possibly does not
have enough value to be worth the effort of a language change. On the
other hand it is a relatively small change since @ is already added.
--
Oscar
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/YKLPXMYCDOXBZ5AFC4WDDOF64RQPUT7M/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Double "at" operator for matmul exponentiation
Every Python idea that has ever been proposed "for the sake of
completeness" has been rejected... at least in the 24 years I've been
following such closely.
Do you have an actual compelling use case? An abstract symmetry isn't going
to do it.
On Wed, Jul 5, 2023 at 6:17 AM wrote:
>
> Python has the "star" ("*") operator for multiplication. In the context of
> collections it is supposed to mean element-wise multiplication. Its
> associated operator is __mul__. It also has the double star ("**") operator
> for exponentiation, which is repeated multiplication. Its associated
> operator is __exp__.
>
> In addition to that Python has the "at" ("@") operator for multiplication.
> In the context of collections it should mean linear product, like matrix
> times a matrix, or matrix times vector. Its associated method is __matmul__.
>
> For completeness we should now have the exponentiation operator meaning
> repeated application of the "at" operator. Its method could me __matexp__.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/AS3F4V4PCR4EUMYGC7HEECQHAFUVNU2M/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
The dead increasingly dominate and strangle both the living and the
not-yet born. Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/U2XN5X67YZEAQOLCQZ4KRPPO5E3Z3QSE/
Code of Conduct: http://python.org/psf/codeofconduct/
