Question about coercion model

71 views
Skip to first unread message

Gareth Ma

unread,
Feb 12, 2024, 6:21:36 AM2/12/24
to sage-...@googlegroups.com
Hi all,

I am currently torturing myself by looking at the coercion model. I saw this line which I have questions about, in particular about its interaction with Python objects. Take the following code for example:

sage: class Number:
....:     def __init__(self, x): self.x = x
....:     def __repr__(self): return f"Number({self.x})"
....:     def _acted_upon_(self, other, _): return Number(self.x * ZZ(other))
....: a = Number(5)
....: a
....: a * ZZ(3)
....: a * int(3)
Number(5)
Number(15)
<TypeError>

It goes through the coercion model and arrives at the line I linked to, where Y is `ZZ` in the first case and `int` in the second. Then the `int` fails because the `isinstance(Y, Parent)` call fails, whereas the first succeeds.

My question is whether this behaviour is desirable, and whether there is any reason why Sage doesn't also check for actions with Python objects. More directly, will adding a check for say `or (isinstance(Y, type) and Y != type)` directly break anything conceptually?

For a more realistic example, currently multiplying an elliptic curve point by a Python `int` uses a slow binary addition method, whereas multiplying by a Sage `Integer` uses an optimised pari call, due to the behaviour.

Nils Bruin

unread,
Feb 12, 2024, 12:43:47 PM2/12/24
to sage-devel
On Monday 12 February 2024 at 03:21:36 UTC-8 Gareth Ma wrote:
sage: class Number:
....:     def __init__(self, x): self.x = x
....:     def __repr__(self): return f"Number({self.x})"
....:     def _acted_upon_(self, other, _): return Number(self.x * ZZ(other))

I think that would have horrible side effects. With that code and your proposed change, I think

"100" * a

should succeed and hence lead to the discovery (and caching!) of an action of "str" on "Number". I would expect that _acted_upon_ should be pretty sure of the objects it handles and not rely on generic "try and convert this" operations.

Another place where Parent may be needed is in the caching code itself: some of it happens in (partially weak) global dictionaries, but some of it happens *on the parent*. So `int` would probably fail to have the appropriate infrastructure for caching.

Gareth Ma

unread,
Feb 13, 2024, 4:56:35 PM2/13/24
to sage-...@googlegroups.com
I see, thanks for the clear explanation, indeed "100" * a is absurd.

Still, should there at least be some mechanism to handle `int` in this code path? Since the path for `_mul_` works:

```
sage: class Number(Parent):

....:     def __init__(self, x): self.x = x
....:     def __repr__(self): return f"Number({self.x})"
....:     def _mul_(self, other): return Number(self.x * ZZ(other))

....:
....: a = Number(5)
....: a * ZZ(3)
....: a * int(3)
Number(15)
Number(15)
```
--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/a7ae43b1-d186-4ca1-a754-c669eec7b6e5n%40googlegroups.com.

Reply all
Reply to author
Forward
0 new messages