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, ...). Now, to what `x in Y` should return. That's a general problem, that we also often encounter in our enumerated sets. For example, in generic code, it's often natural to write: sage: assert x in Y But what if containment test is expensive/indecidable/not implemented? In the use case above, we would like the assertion to just be ignored. In MuPAD, we had taken advantage of the available three-valued logic (TRUE / FALSE / UNKNOWN), to write: sage: assert x in Y = TRUE which is pretty similar to the suggestion of using None for UNKNOWN (without the peculiarities of `None` and its disadvantages that William pointed out). In fact, most of this kind of type checking was done by specifying the types of the arguments of a procedure: MuPAD: proc(R: Rings()) ... which resulted down the road to an assertion check as above. The downside is that there is no way to specify how hard one wants to do a containment test. Altogether, I would vote for something along the lines: sage: x in Y returns True or False if provable; raises an exception in all other cases sage: Y.__contains__(x, proof = False) returns a best guess, or raises an exception sage: x.hopefully_in(Y) # find a better name! Try in turn Y.__contains__(x, proof = False) and Y.__contains__(x) Return False if the first returned False, or if the first raised and the second returned False Return True in all other situations (exception, ...). Allowing altogether for: sage: assert x.hopefully_in(Y) Programmatically speaking, it might be easier to use something like Y._contains_probabilist(x) rather then Y.__contains__(x, proof = False); this plays better with inheritance. More thoughts on demand! Cheers, Nicolas -- Nicolas M. Thiéry "Isil" <nthi...@users.sf.net> http://Nicolas.Thiery.name/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---