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 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.
--
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.
