On Sat, Aug 22, 2009 at 2:23 PM, Sebastian Pancratz <[email protected]>wrote:
> > > > 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. > > > > William > > I am sorry if my post wasn't very clear; by "I think the code would be > a lot cleaner if the following behaviour was offered" I did not mean > that the default behaviour of the current implementations of > "is_field" etc should be changed. Instead, that is why I included the > methods "is_certainly_field" etc. However, I think your suggestion of > adjusting the current implementation of "is_field" etc by including an > optional parameter looks much cleaner. > > If other people agree with this approach, I guess I can just leave a > short note explaining this behaviour in the generic method in sage/ > rings/ring.pyx and then go through all inheriting classes overwriting > the method to make the adjustments, right? > Yes. I'm not sure I agree or not, but since you're "in the code" and actually working on code that is made much cleaner by making this change, I assume you know what you're talking about. So I'm fine with you making the change suggested above. -- 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 -~----------~----~----~----~------~----~------~--~---
