Hi!

Let me transplant my answers on trac ...

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

Note that the distinction between (a) and (b) will be made clearer
with the upcoming functorial construction patch #10963 which
introduces an infrastructure for "axioms" to handle (b).

I totally agree that (a) should not change over the lifetime of an
object. On the other hand, that (b) can change over time, is a very
important feature: when we discover new properties of an object, we
want to exploit them to use better algorithms; and get more methods if
there are more things that one can compute. And we might as well have
every reference to that object in the current Sage session benefit
from the improvement.

Note that GAP is doing (b) intensively for precisely that reason
(although they use a different mechanism, through method selection
rather than object orientation).

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. Same thing for Q.gens().


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()``.

Note: in a perfect world Python would have full troolean values, and
``parent in Foos()`` would return ``Unknown`` when relevant; this
would more satisfying, since users not aware of the difference between
``in Foos()`` and ``is_foo`` would not be misguided.


> By the way:
> {{{
> sage: R.category()
> Join of Category of commutative rings and Category of subquotients of monoids 
> and Category of quotients of semigroups and Category of finite enumerated sets
> sage: R2.category()
> Join of Category of subquotients of monoids and Category of quotients of 
> semigroups and Category of finite fields
> }}}
> I have to say those values do a good job of dissuading people from ever 
> looking at them!

Working on that :-) With the current functorial patch, this should be
roughly "Category of finite commutative quotient fields."

Cheers,
                                 Nicolas
--
Nicolas M. ThiƩry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/

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