#10963: More functorial constructions
-------------------------------------+-------------------------------------
       Reporter:  nthiery            |        Owner:  stumpc5
           Type:  enhancement        |       Status:  needs_review
       Priority:  major              |    Milestone:  sage-6.1
      Component:  categories         |   Resolution:
       Keywords:  days54             |    Merged in:
        Authors:  Nicolas M. Thiéry  |    Reviewers:  Simon King, Frédéric
Report Upstream:  N/A                |  Chapoton
         Branch:                     |  Work issues:
  public/ticket/10963                |       Commit:
   Dependencies:  #11224, #8327,     |  8045aa4a4b7ada735b3eb6055382f9b341a39f1e
  #10193, #12895, #14516, #14722,    |     Stopgaps:
  #13589, #14471, #15069, #15094,    |
  #11688, #13394, #15150, #15506     |
-------------------------------------+-------------------------------------

Comment (by nbruin):

 Replying to [comment:391 vbraun]:

 > I'm not sure what kind of argument you are trying to make with axioms
 being
 > just labels. Variables are just labels in Python, but we still pass them
 around.

 We don't! We normally pass around the values that are bound to them.
 Passing around
 "variables" would necessarily boil down to passing around the strings that
 can
 then be looked up in the dictionaries representing the scope bindings to
 be investigated. THAT is
 indeed what the category code does (it also mangles strings, and that I
 don't
 like).

 > {{{
 > def sin():
 >     arg = globals().get('x')
 >     return math.sin(arg)
 > }}}

 I think this is fundamentally different from what is happening in this
 code. A
 direct corollary of storing the subcategory obtained by applying an axiom
 to a
 supercategory in an attribute labelled with the axiom name is that at
 least at
 some point axioms are represented by a string.

 It seems the strongest motivation (and a convincing one to me) for storing
 subcategories in attributes is that it allows leveraging Python's syntax
 for
 writing classes and attributes. Given that implementation, axioms are
 represented by a string at some point. Do we need another representation
 as
 well?

 If you take "applying an axiom to a category" literally, then basically
 the
 implementation
 {{{
 def Finite(category):
     return category.Finite()
     #or, to illustrate where the string is living:
     #return getattr(category,"Finite")()
 }}}
 would do the trick. There'd be room for documentation on that, but really
 there
 is not much to document. Checking whether a given axiom is applicable
 boils down
 to eventually
 {{{
 def has_axiom(category,axiom):
     return hasattr(category,string_corresponding_to(axiom))
 }}}
 where the implementation of `string_corresponding_to` is simplest if
 `axiom`
 itself is already given by a string. What do we gain from representing
 axioms
 otherwise?

--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:395>
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.

Reply via email to