#11935: Make parent/element classes independent of base rings
---------------------------+------------------------------------------------
   Reporter:  SimonKing    |          Owner:  nthiery                           
   
       Type:  enhancement  |         Status:  new                               
   
   Priority:  major        |      Milestone:  sage-4.7.3                        
   
  Component:  categories   |       Keywords:  parent class, element class, 
category
Work_issues:               |       Upstream:  N/A                               
   
   Reviewer:               |         Author:                                    
   
     Merged:               |   Dependencies:  #11900                            
   
---------------------------+------------------------------------------------

Comment(by SimonKing):

 Replying to [comment:3 nthiery]:
 > A good thing to do at this point would be to search through the sage
 > pickle jar for how many parent_class's and element_class's are pickled
 > there.

 Old pickles will not break, I believe. Let `P3 =
 Algebras(GF(3)).parent_class` and `PQ = Algebras(QQ).parent_class`. Here
 are a few scenarios:

 __1. P3 and PQ have been created and pickled with an old version of Sage__

 In the old version of Sage, `P3!=PQ`. They are pickled by construction.
 Hence, after applying my yet-to-be-submitted patches, they are unpickled
 as `Algebras(GF(3)).parent_class` and `Algebras(QQ).parent_class` - which
 is the same class after applying the patch.

 '''Conclusion:''' An old pickle will not break, with either approach 2. or
 3. The worst what could happen is  `P3!=PQ` before pickling and `P3==PQ`
 after unpickling. But the defining property
 `P3==Algebras(GF(3)).parent_class` and `PQ==Algebras(QQ).parent_class` is
 preserved.

 __2. P3 and PQ are created and pickled according to approach 2. from
 above__

 Of course, `P3==PQ` at the time of pickling. The pickle will only depend
 on the parent classes of the super categories of `Algebras(GF(3))` and
 `Algebras(QQ)`. If there was a change in the super categories between
 pickling and unpickling, we would have `P3!=Algebras(GF(3)).parent_class`
 after unpickling.

 '''Conclusion:''' A new pickle of P3 and PQ can be unpickled after a
 change in the category graph, but a change in the category graph will
 destroy the defining property `P3==Algebras(GF(3)).parent_class`.

 __3. P3 and PQ are created and pickled according to approach 3. from
 above__

 Of course, `P3==PQ` at the time of pickling. `PQ` and `P3` will both be
 pickled by construction. In particular, a change in the category graph
 would not matter, as long as the super categories of `Algebras(QQ)` and
 `Algebras(GF(3))` still coincide (up to the base ring) after the change in
 the category graph.

 A problem would arise if, in a distant future, the super categories of
 `Algebras(QQ)` and `Algebras(GF(3))` would become essentially different.
 Say, some algebra person finds that vector spaces over fraction fields
 should have their own category, different from the usual category of
 vector spaces. Then,
 `Algebras(QQ).parent_class!=Algebras(GF(3)).parent_class`. In particular,
 after such change, unpickling `P3` or `PQ` would result in either
 `PQ!=Algebras(QQ).parent_class` or `P3!=Algebras(GF(3)).parent_class`.

 '''Conclusion''': A new pickle of P3 and PQ can be unpickled after a
 change in the category graph. Most changes in the category graph will
 preserve the defining property `P3==Algebras(GF(3)).parent_class` and
 `PQ==Algebras(QQ).parent_class` after unpickling. However, if the super
 categories will depend on the base ring in a different way as it is now,
 then either P3 or PQ will lose the defining property after unpickling,
 while the other will keep the defining property - and we don't know which
 of the two will break.

 ----------

 It seems to me that approach 3. is less fragile than 2. But I believe that
 in applications (hence, for pickling parents) both should be fine. So,
 I'll prepare patches for both approaches.

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11935#comment:5>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sage-trac?hl=en.

Reply via email to