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<[email protected]> 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" <[email protected]>
http://Nicolas.Thiery.name/
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
