On Mon, Feb 11, 2013 at 3:10 PM, Nils Bruin <[email protected]> wrote: > On Feb 11, 11:35 am, "Nicolas M. Thiery" <[email protected]> > wrote: > >> By design, the category of an object in Sage describes: >> >> (a) It's "operations" (additive structure, multiplicative >> structure). This conditions what the morphisms are in the category. >> >> (b) The properties of the operations that Sage is aware of at this >> point in time (either because they were specified by the user or >> discovered during some computation). > [...] >> Of course for that to make sense changing (b) should only influence >> efficiency, and not change the *semantic* of questions; for that the >> questions should be unambiguous. Hence one should ask questions like: >> {{{ >> sage: Q.is_finitely_generated(Fields()) >> }}} >> or >> {{{ >> sage: Q.is_finitely_generated_field() >> }}} >> with >> {{{ >> sage: Q.is_finitely_generated() >> }}} >> being just a lousy syntactic sugar, for the user convenience, when >> there is no ambiguity. > > I think the examples referred to earlier that (b) presently seems > capable of creating ambiguity where originally there wasn't. Assume we > have a constructor TotalQuotientRing (which would be straightforward > to write and probably useful too): > > sage: ZX.<x>=ZZ['x'] > sage: A.<a>=ZX.quo(x^2-1) > sage: B.<b>=ZX.quo(x^2+1) > sage: QA=TotalQuotientRing(A) > sage: QB=TotalQuotientRing(B) > > then QA and QB are clearly created as rings, so asking for > "is_finitely_generated" can only refer to whether they are finitely > generated as rings (asking the question in the category of ZZ-modules > should really need the application of a forgetful functor), and they > are not. > > But now we do: > > sage: QA.is_field() > False > sage: QB.is_field() > False > sage: QB in Fields() > True > > Now it's not clear anymore what `is_finitely_generated` would refer > to! Should it do the same thing as when it was unambiguous? > Discovering more information should not change answers to other > questions, so I think there's no choice here: The thing came from a > constructor that generically produces objects in the category of > rings, so that's where questions should be answered. In particular, > that means that that in this case > > FieldOfFractions(B) is not QB > > Since (a) and (b) are separate functions, the cleanest solution would > be to store them separately. As a means of optimization, I can see how > you might want to use the python MRO to take care of method selection > for you. But I think this shows you have to careful that you only > allow routines to get shadowed that are intended to get shadowed. > >> A consequence of (b), and this is by design, is that a call to >> ``parent in Foos()`` is guaranteed to be cheap. And this too is very >> important so that, for examples, constructors don't hesitate to call >> it and take appropriate decision accordingly. If one wants a >> guaranteed answer, one should use ``parent.is_foo()``. > > The currently proposed solution to #13370 violates that: `ZZ.quo(17) > in Fields()` triggers a primality test with the patch proposed there. > > Also it shows that the very attractive generic > > def is_finitely_generated(self): > if self in Fields(): > return is_finitely_generated_as_a_field(self) > else > return is_finitely_generated_as_a_ring(self) > > would be wrong, since "parent in Category" is indeterministic. It > should read something along the lines: > > def is_finitely_generated(self): > if is_subcategory(self.category_by_construction, Fields()): > return is_finitely_generated_as_a_field(self) > else > return is_finitely_generated_as_a_ring(self) > > [For the result of TotalQuotientRing, the test > is_subcategory(self.category_by_construction, Fields()) should be > false and for the result of FieldOfFractions it should be true] > > If I correctly understand, you would prefer to avoid the question by > banning the question altogether by saying the question is ill-defined > because it's unclear in which category this question needs to be > answered. > > However, for a category object it IS clear: the category of which it > is an object, so it seems to me that you are advocating that parents > aren't really category objects. > > Are you advocating that sage parents should instead model collections > of category objects, the closure under application of a certain set of > functors probably? I would think doing so makes for a very interesting > research project, but at this point is not a good basis for defining > the semantics of a computer algebra system (being too experimental).
I don't think we should have a separate ZZ whose category is EuclideanDomains another one whose category is Rings, another one whose category is AbelianGroups, and another one whose category is Sets. Perhaps this is a special case, as this is a nested set of subcategories. > I think it shows (b) should be a little more conservative: If we're > finding that certain parents can be considered in a subcategory of the > one in which they are constructed, we can use that if it improves > efficiency, but only for operations that give the same result. > Surprisingly, things like "is_finitely_generated" do not have that > property. I would propose that (1) every method (within reason) whose result depends on the category take a category as an argument and (2) for most (but perhaps not all) methods this defaults to the category in which the element was constructed, regardless of specializations that are later discovered. Perhaps this could be (partially) enforced with a decorator for such methods. This is why we have sage: ZZ.quo(5) is Integers(5) True sage: Integers(5) is GF(5) False - Robert -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
