On Feb 4, 10:01 pm, Simon King <simon.k...@uni-jena.de> wrote:

> Note that in some cases the _element_constructor of a complicated ring
> would try to convert the input into ZZ before converting it into self.

Ouch. by generic conversion?

> So, in order to strictly avoid it, we would need to carefully clean all
> of Sage. That's why I tried to suggest a mechanism that would allow to
> deallocate a conversion even when a conversion/coercion into ZZ is
> cached.

I guess all we require is that phi.domain() returns the domain, so if
internally this is stored via a weakref, there shouldn't be an issue.
If we just throw RuntimeError("Domain has disappeared") if it ends up
not being there anymore, I doubt we'd ever have problems. That way at
least we won't be keeping domains alive unless there's a reason for it
inside the map. I doubt any code is regularly inspecting domains of
coercion maps, so performance loss should be minimal.

I'd say: encourage maps to store their domains via weakref, but not
require it. Oddly enough, this means we should advise that maps should
NOT typecheck that their argument lies in the domain and also not try
to coerce/convert into the domain before applying the map, because
that would require accessing the stored domain. Is that a problem?
does that mean that coercion maps that are stored internally need to
be more bare bones than maps offered for public consumption?

> > (R,S,+) -> c
>
> I thought we are doing this already? Certainly TripleDict is used with a
> binop as a third argument, in some contexts.

Yes, but I was proposing other semantics for the value stored in it,
to avoid having strong references to morphisms outside their
codomains.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to