Hi Florent,

On 2014-03-08, Florent Hivert <florent.hiv...@lri.fr> wrote:
>> The theory here is that Sets defines a Finite axiom, and by some metaclass 
>> magic the inner class Cs.Finite ends up being a subcategory of Sets.Finite. 
>> [...]
>> Nicolas thinks this amount of breverity is a desirable feature, and I think
>> we should make Cs.Finite be explicit about which axiom it implements (and,
>> therefore, not require that it is named Cs.Finite if you don't want
>> to).
>
> I completely second Nicolas on that point. There is a clash between Python's
>
>    "explicit is better that implicit"
>
> and mathematical usage. ...
> Now going back to Sage, I really think that if we don't keep the syntax *as
> short as possible* (as in math: `let's G1, G2 be a finite commutative group
> and Phi be a morphism from G1 to G2`) then this will be much to verbose to be
> programmed with and each user will start to makes it's own shortcut which is
> much worse.

I am not sure if Volker and you talk about the same meaning of "syntax".

It seems to me that you take the position of a user, who has a category
Cs() and wants to get the category of finite cs. Then, it is convenient
if one can just do Cs().Finite(). This syntax is clear and simple.

And I suppose that Volker agrees with you here. FWIW, *I* do.

However, it seems to me that Volker was arguing from the position of a
developer. Again, the nested class syntax seems nice and concise to me:
 sage: class Cs(Category):
 ....:     def super_categories(self):
 ....:         return [Sets()]
 ....:     class Finite(CategoryWithAxiom):
 ....:         class ParentMethods:
 ....:             def foo(self):
 ....:                 print "I am a method on finite C's"

But, as Volker has pointed out, the objects O of Cs().Finite() also inherit
from the parent class of Sets().Finite(). There is no surprise from a
mathematical point of view: O is a c and O is finite, every c is a set, the
property "finite" applies to sets, thus O is a finite set.

But is the mathematical syllogism really stated in the code in a
sufficient level of clarity? Volker, do I understand correctly that
this is your concern?

My opinion on it, from a user perspective:
- Yes, it is surprising for a novice user to see that O.is_finite()
  is available. If O.__class__ is a Cython extension class, you wouldn't
  even find an is_finite() method in O.__class__.mro(). But: This criticism
  also applies to the *existing* category framework. I don't think that
  the surprise will be worse with #10963. And as soon as one has
  understood what the category framework is about, the existence of
  O.is_finite() is *not* surprising.
- A couple of years back, I did not like the category framework, since
  it was very difficult to find the source code of stuff. Now,
  introspection has improved, and `O.is_finite??` will show you the
  code. And with the possibility to easily find the source code, I
  started to find the category framework much easier to understand.

My opinion, from a developer perspective:
- I wouldn't implement a statistical tests, since I don't know about
  statistics. So, I suppose a developer who wants to implement a
  category knows about categories.
- The code above clearly states that Cs() is a sub-category of Sets().
  Thus, knowing about categories, the developer should not be surprised
  that applying the axiom "Finite" to Sets() is relevant for Cs().Finite().

However, something that I have mentioned earlier (and hasn't been
answered yet) is the fact that sometimes Cs().Finite is not the class
Cs.Finite, but is a cached method that is gotten by some black magic
that I find not transparent, and (I think) for virtually no benefit.

Nicolas, is documentation the only reason to make Cs().Finite be a
cached method overriding Cs.Finite? Then I think we should find a
different way to make Cs().Finite/Cs.Finite point the user to the
specifications of the "Finite" axiom. Why not have a class method
specification() for a CategoryWithAxiom C, that will print the
documentation of the defining axiom of C (taken from where this
axiom is defined)?

Note that this documentation/specification problem could be solved by
making axioms proper objects (that know about their specification!),
rather than just strings. IIRC, Volker has provided a draft
implementation.

Best regards,
Simon


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to