Hi John, Hard to be certain without the context, but I think this is the relevant discussion: http://groups.google.com/group/sage-devel/browse_thread/thread/dc104b7cb64d39e3/
In short, IIRC, sometimes a construction will create a ring. In certain instances the construction might also be a field. Maybe it is easy to know this (perhaps certain parameters establish the certainty of this), while in other constructions it may be difficult (or expensive) to know if the ring constructed is a field or not. You might care about this if you have an algorithm that would be faster if you were certain the input is a field, and not just a ring. So I think this construct is there to handle this sort of situation. But read the discussion referenced for the details, because I'm pretty sure I'm not summarizing it properly. Rob On Nov 25, 7:26 pm, John H Palmieri <jhpalmier...@gmail.com> wrote: > In ring.pyx, there is code like this: > > if proof: > return NotImplementedError > else: > return False > > I would think that the second line should say "raise > NotImplementedError". (Changing it makes some doctests fail, > though.) Is there a good reason for doing "return > NotImplementedError"? > > -- > John -- 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
