Categories for the working mathematics programmer

[nthiery]

This (series of) patch(es) extends the Sage category framework as a design pattern for organizing generic code.

Latest version of the patches:

•  categories-framework-nt.patch (reviewer: David Roe; review essentially complete up to some doctests)
•  categories-categories-nt.patch (reviewer: Florent Hivert, Javier, David Kohel, Anne Schilling, ...) See CategoriesCategoriesReview
•  categories-fixsagelib-nt.patch (positive review: Robert Bradshaw) updates to the sage library (import fixes, ...)
•  categories-fix-combinat-nt.patch (positive review: Florent)
•  categories-numberfield_homset-nt.patch (reviewer: William)
•  categories-unpickle_backward_compatibility_aliases-nt.patch (positive review: Florent)

Status and roadmap:  http://sagetrac.org/sage_trac/wiki/CategoriesRoadMap

[robertwb]

Where is categories-nt.patch itself?

[nthiery]

Replying to robertwb:

Where is categories-nt.patch itself?

On the sage-combinat patch server. It changes too often to keep it updated on trac. I highlighted the link on top of the description (and improved the ReSTing)

[nthiery]

There are the patches. They are file-orthogonal, so they should apply in any order.

[nthiery]

Note: to get the latest version, please use the patch server.

[was]

NOTES:

(1) Post the latest version here -- I don't want to mess with the patch server.

(2) It says "Experts: please redefine this properly and/or put CC/RR/... in NumberFields?()". I number field is by definition a finite extension of QQ, but CC and RR are infinite extensions of QQ. So we can't put them in that category. Having a function is_NumberFieldHomsetCodomain does seem like a good workaround for now.

(3) The function is_NumberFieldHomsetCodomain in the patch posted here doesn't have any documentation or doctests. Please add them.

(4) I would change these two lines:

        143	        if is_Field(codomain): 
 	144	            return True 

to the single line

        143	        return is_Field(codomain)

which should be functionally the same, and clearer to read.

(5) in a similar spirit, I would change

        145	    except: 
 	146	        pass     
 	147	    return False 

to just

        145	    except: 
 	146	        return False

which is again clearer and equivalent.

(6) I'm puzzled by this in your number_field_rel.py patch:

	543	            return NotImplemented 

What is NotImplemented?? It's not defined in the number_field_rel.py file in sage-4.2.

[nthiery]

Replying to was:

NOTES: (1) Post the latest version here -- I don't want to mess with the patch server.

I just added direct links in the description. I will post the patches shortly when they will be final.

(2) It says "Experts: please redefine this properly and/or put CC/RR/... in NumberFields?()". I number field is by definition a finite extension of QQ, but CC and RR are infinite extensions of QQ. So we can't put them in that category. Having a function is_NumberFieldHomsetCodomain does seem like a good workaround for now.

Ok.

(3) The function is_NumberFieldHomsetCodomain in the patch posted here doesn't have any documentation or doctests. Please add them.

Oops. Will do.

(4) (5) (6)

Yes better. Will do.

(6) I'm puzzled by this in your number_field_rel.py patch: {{{ 543 return NotImplemented? }}} What is NotImplemented?? It's not defined in the number_field_rel.py file in sage-4.2.

It's a builtin python object. Anyway, the function now raises a TypeError?, per the latest _Hom_ protocol.

[nthiery]

Replying to nthiery:

Replying to was: ...

Done! See the linked to patch.

I used the occasion to move the field containment logic into Fields where it belongs.

[mhansen]

Merged the patches from changeset e70487186111. They'll be posted on here in a bit.