#15183: x in IntegralDomains() should refine category
-------------------------------------+-------------------------------------
Reporter: saraedum | Owner:
Type: enhancement | Status: needs_review
Priority: minor | Milestone: sage-6.1
Component: categories | Resolution:
Keywords: | Merged in:
Authors: Julian Rueth | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/saraedum/ticket/15183 | 2282a39caa83c83ceef1000eb028014f5556a606
Dependencies: #14482 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by SimonKing):
Replying to [comment:23 ncohen]:
> Okay guys, it looks like Nicolas says that category containment should
*not* refine the category,
For good reason! Category refinement involves changing the '''class''' of
an object after creation, and actually after '''usage'''! Python lets you
do those things, but really it is a dangerous hack.
We have seen cases in which the hash of a parent depends on the class of
the parent. Hence, if a category refinement happens after (or while) using
a parent P as key of a dictionary, it used to be possible that P was put
in the wrong hash bucket of the dictionary. Fortunately, someone (I think
it was Volker) added a security layer, so that now changing the class
results in an error if it changes the hash.
But apart from hash, one often sees the following in `__cmp__` methods:
{{{
#!python
def __cmp__(self, other):
c = cmp(type(self),type(other))
if c:
return c
return cmp(<data for self>,<data for other>)
}}}
Hence, if you add category refinement, comparison could break: Imagine you
originally had `cmp(self,other)==0` and then did `self in
IntegralDomains()` (triggering a category refinement) but didn't `other in
IntegralDomains()`. Now, ask `cmp(self,other)`: The result will ''not'' be
zero any more!
Mathematically, a category refinement should be fine, and one may think
that the category framework is designed to be stable against category
refinement ("if you refine the category of P, then P may inherit different
methods from the category framework than before, but these new methods
will fit better."). However, some of these methods do caching. Hence, if P
originally belongs to category C1 and it got some method `meth()` which
did some caching, and then you refine P's category to be C2, so that P now
inherits a ''different'' version of `meth()` that uses a different cache,
then you have a mess.
One could argue that it is a bug if you ''do'' get a mess upon category
refinement. But perhaps it is wise to not consciously ask for trouble...
> and on the other hand Fields already do it.
Yes, I know, I have to take the full blame...
But the situation was different than the situation here!
When I introduced category refinement for fields, `Fields.__contains__`
used to be custom since a long time. This custom method was very very
slow, but the default `__contains__` method couldn't be used unless all
parents' categories were fully initialised. But then, the initialisation
took too much time. Hence, I went for a compromise: Keep initialisation
fast, and accept that the ''first'' `Fields()` containment test is slow;
but in case of success, make sure that all further containment test will
be quick.
I was motivated by a concrete example that was important to a "powerful"
Sage sub-community (you know, elliptic curves and so on): This example
became way too slow after implementing the category framework for all
rings. Reason: Initialisation of these rings took way too long, since for
each ring it was needed to test whether the modulus is a prime number.
Guided by this example (and a similar example for matrix spaces) I found
that a "lazy" category initialisation can avoid certain severe
regressions.
However, here, things are different: As much as I understand, the
suggestion is to let `IntegralDomains()` have a custom `__contains__`
method, just because `Fields()` has a custom `__contains__` method too.
But since `Category_singleton.__contains__` is very very fast, it should
not be overridden by a custom `__contains__` without a very very good and
compelling reason. It could actually be that some examples will become
''slower'' when the containment test will regress.
Put differently: I haven't seen any concrete "real world" example that
shows that we need lazy category initialisation for (some) integral
domains. Without such example, I'd say we should better not open Pandora's
box again.
--
Ticket URL: <http://trac.sagemath.org/ticket/15183#comment:25>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
