#5596: [with patch, positive review] refactor coercion to catch fewer exceptions
----------------------+-----------------------------------------------------
Reporter: robertwb | Owner: robertwb
Type: defect | Status: new
Priority: major | Milestone: sage-4.1.2
Component: coercion | Keywords:
Reviewer: | Author:
Merged: |
----------------------+-----------------------------------------------------
Comment(by nthiery):
Replying to [comment:8 robertwb]:
> Replying to [comment:6 nthiery]:
> I'll second Georg's comments, you are as much of an "expert" in this
area as nearly anyone else (except maybe me, but I can't review it
myself...).
Fair enough :-)
> > I am now on my way to run the tests, and see how this patch interact
with the category patches.
>
> I saw some tests failing--looks like easy fixes, I'll try and post a
patch later tonight.
Argl. I am always off by one version. I now have to compile a 4.1.2 alpha4
> > Alternatively, I could possibly suggest to instead check that
self._lmul (say) is
> > not the default "NotImplemented" implementation of Element, before
actually calling it. I guess I am trying to have an analogue of
> > the abstract_method idiom for cpdef methods. Would it be possible to
attach some sort of "abstract method" flag to a cpdef method,
> > that we could test without actually having to execute the method?
>
> This can be done, kind of, if one knows the baseclass where the
"abstract" method is implemented, though it's a bit hackish. I think you
underestimate how fast calling a c(p)def method can be though.
Oh, thanks for pointing this.
No, I am not worried at all about speed, but about semantic and lazyness.
Let's say we are investigating whether there is an action of A on B.
That's (mostly) a mathematical question about the parents A and B. So it's
preferable to "ask them", rather than poking around with some of their
elements (which could have some special property). Part of it comes from
experience with MuPAD telling that lot of trouble can be avoided if a
parent does not construct any element unless asked for explicitly; in
particular, lazyness helps handling cross-dependent parents. At the same
time, a coercion lookup may involve many intermediate parents which will,
or not, play a role in the end.
Now: what do I mean by "ask them". That can be using introspection,
possibly on their element class. Preferably, it would be by having A and B
(or some common boss) declare explicitly the action
to the coercion system. I actually have in my stack of todo's a
preliminary implementation of this, as this is needed for symmetric
functions and friends.
Hmm, that discussion is becoming long. We should move it to sage-devel.
> Yeah, that'd take some thinking, probably best put off 'till later.
Ok. So I put a positive review, pending confirmation that all tests pass
smoothly on 4.1.2 alpha4.
.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/5596#comment:10>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
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-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
