On Sat, Aug 22, 2009 at 12:17 PM, Jason Grout <[email protected]>wrote:
> > William Stein wrote: > > > > > > On Sat, Aug 22, 2009 at 4:16 AM, Sebastian Pancratz <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > Dear all, > > > > At SAGE Days 16 I implemented some code for division-free matrix > > operations, which is being tracked as ticket #6441. The main > > contribution is code to compute the characteristic polynomial without > > divisions, and this leads to code to compute the characteristic > > polynomial, the adjoint matrix and the determinant of matrices over > > any ring (commutative and with unity). On the one hand this will > > extend the capabilities of SAGE, but in some cases it will also > > provide a speed-up (by avoiding working in the field of fractions, or > > because an O(n^4) algorithm beats the previous backup option for > > computing determinants). > > > > With this little background provided, here is the actual problem on > > which I would very much like to hear your opinion. > > > > A design-related technical problem is that, when given a ring R and > > asked to construct or compute with certain objects related to R (see > > below for some examples), SAGE tries to find out whether R is merely > a > > ring, or maybe an integral domain,or perhaps even a field. The > > generic methods for this are located in sage/rings/ring.pyx. > > > > In this file, the current behaviour is the following, > > > > o Try to establish the answer (yes or no). > > o If this doesn't work, throw an exception. > > > > although the actual behaviour is down to the inheriting classes. > > > > From the point of view of the ring, this might seem sensible. But I > > think the case where this is used is something like this: One has > > various algorithms at hand for computing with a given ring, and the > > computation would be done much better if one knew the ring was a > > field, say. I think the code would be a lot cleaner if the following > > behaviour was offered: > > > > o Try to find out whether the ring is a field, say. > > o If the positive answer can be established, return yes. Otherwise, > > return false. > > > > > > If R is a ring that is in fact a field, I'm sure that many people will > > be very unhappy if we have: > > > > sage: R.is_field() > > False > > > > This would be more acceptable: > > > > sage: R.is_field(unknown_returns_false=True) > > True or False > > > > So why not just add a flag that is off by default to the "is_field", > > etc. functions, so they do what you want? It makes the code very > > easy to read, will be easy to document, since it will be easy to learn > > about if you get frustrated and type "R.is_field?". Then much of the > > library code code use it. > > > Would this be a good place for the proof=True/False parameter? If > proof=True, then an exception is thrown if we don't know the result. If > proof=False, then False means that we don't know for sure it is True. I thought about that too. I'm not sure. Usually I think of proof=True/False as not changing the behavior of the function so much. It might work here. > > A similar issue to this came up when testing equality of symbolic > expressions. There, the decision was that True was returned if we knew > two expressions were equal, and otherwise False was returned. The logic > between the equality testing and this question seems like it should be > consistent. That's a good point -- the question is perhaps impossible to answer in general in both cases. That said, I know for a fact a lot of people will complain if R.is_field() returns False by default when one can't decide, even when R is a field, since I think that used to be the case and people *very* frequently completely. This was when is_Field(...) was in the top-level namespace (it has since been deprecated). -- William --~--~---------~--~----~------------~-------~--~----~ 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 URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
