On Sep 22, 2009, at 4:49 AM, Nicolas M. Thiery wrote: > > Hi, > > Getting back on my late sage e-mails ... > > On Mon, Aug 24, 2009 at 11:25:50PM -0700, William Stein wrote: >> On Mon, Aug 24, 2009 at 10:43 PM, Robert >> Bradshaw<rober...@math.washington.edu> wrote: >>> What I'd rather see is something like >>> >>> sage: R = Zmod(6) >>> sage: K = categories.Fields(R, check=False) # any ring R >>> sage: K >>> Ring of integers modulo 6 as a field. >>> sage: K.is_field() >>> True >>> >>> where all other methods are inherited via dynamically. >> >> That would be pretty cool. I'm not sure if I like >> >> sage: K = categories.Fields(R, check=False) >> >> since it could be hard for me to remember. That said, it does fit >> the "Sage/Magma" design philosophy pretty nicely, and is a natural >> way >> to use coercions and categories. > > Variant: > > sage: R = Zmod(6) > sage: R.set_category(Fields()) # or maybe better R.add_category > (Fields()) > sage: R in Fields() > True > sage: assert R in Fields() > > This avoids cluttering each sage object with an is_bla method which > might refer to a completely unrelated category bla. Also, this handles > automatically the inheritance of category (so that stating that R is > in Fields imposes that it also is a division ring, ...).
One issue with that is that, forever after in your sage session, Zmod (6) will be a field (unless you change it manually back, if you know that the library function you called changed it...) That's why I liked the new object method. Alternatively, this might be a good use for contexts. - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
