> thanks for working on this topis, it is a nice idea to extract > variables from ODE automatically. I vote also for splitting into two > patches and if you have problems with this, I can try it to split them > by myself. Anyway, the ODE patch depends on the mtype interface and > this interface should be the first one which should got positive > review.
It will be great if you can help to split the patches. > However giving positive review exceeds my skills. I looked at the code > and I have seen that you test (startin gon line 202), if a function > equals this or that function. I think that each time when someone adds > new symbolic function to Sage (hope someone adds Bessel functions as > symbolic functions :), see [1]) or if someone decides to work with > another arccot function than sage.functions.trig.Function_arccot, this > interface becomes broken. Is there any cleaner way how to implement > mtype? I am not clever enough in Pyhton, but I think that a better > solution must exist. The best way to solve this problem is - to implement all different symbolic and python type as different classes with presented hierarchy, but it's lot of work because sage is big project now. This approach was acceptable at the planing satge, but now it is too hard. The second one is what I proposed - implement simple interface which gather all existing classes unify methods and provide symbolic (text) type. If someone adds new function or type - the interface defined it as 'unknown' which means it should be added to the interface or may be it should be accessed some other way. It is impossible to predict what type or class will be added furthe so it is impossible to predict 'unknown' types without changing mtype. Actually there is one way. As Python types are staying stable I recommend to add mtype function to SymbolicExpression class. So mtype interface can check if it is SymbolicExpression and if it is it just call mtype function of it. The benefit is - if someone wants to add new symbolic function (extend Symbolic expression class) than mtype function should be implemented and there is no need to change basic mtype interface. As I wrote It is only good sketch which can be really helpful (as you can see on dsolve exapmple). Now I am concentrated on my articles so unfortunately I can't spend much time on sage. But sketch is clear and I explain all Ideas how it can be extended or reimplemented. Thank You for spend Your time on review Sincerely, Yuri Karadzhov -- 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
