William Stein wrote: > > > On Sat, Aug 22, 2009 at 4:16 AM, Sebastian Pancratz <s...@pancratz.org > <mailto:s...@pancratz.org>> 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. 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. Thanks, Jason --~--~---------~--~----~------------~-------~--~----~ 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 URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
