On Nov 26, 2007, at 1:11 PM, Ondrej Certik wrote: >> It is wrong / abusive to call _verify_canonical_coercion_c because >> that >> function is never supposed to fail. You should check that the >> parents >> are the same explicitly and if not pass through to the next case. > > Agree. That's why I am proposing the fix here (at the end of the > message): > > http://groups.google.com/group/sage-devel/msg/752742fd202f6868 > > as opposed to Robert's proposal here: > > http://groups.google.com/group/sage-devel/msg/d0aab9c309a3aa29 > > So if there are no more objections (Robert?) I'll implement my > proposal and the patch will be ready.
I did a sage -upgrade and am waiting for it to finish building... When that finishes I'm going to check out your segfault with Spec(QQ) == 5. (If it doesn't finish soon I'll be on my way to campus, but will get back to you tonight at the latest) This should not segfault, but if it does I think it is due to an error elsewhere. Also, I think we should only be callling _sage_ if one of the objects is not a SageObject, rather than if one of the objects is not an Element. The requirement would be that _sage_ MUST return an instance of SageObject to avoid infinite recursion. I still think _verify_canonical_coercion_c is the wrong thing to use here, there is no reason that x._sage_() and y._sage_() should have the same parent (e.g. one could be an element of SR, the other a sage Integer), and at this point we should be able to succeed even if they don't have the same parent by (re-)calling the Sage coercion model on the Sage elements. - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
