I think Robert Marik is the best person to reply to this
issue. I guess he is busy now but I hope he will reply in a
fairly soon and give his opinion.
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to
> For more options, visit this group at
> URL: http://www.sagemath.org
> To unsubscribe from this group, send email to
> sage-devel+unsubscribegooglegroups.com or reply to this email with the words
> "REMOVE ME" as the subject.
You should implement the change and post a patch to
for review. That's how Sage development happens. Hundreds of people
have done this. It's like notices a problem in a wikipedia article,
and fixing it.
But I still have questions:
1. Is there an easy way to check if some class belongs to package in
2. Where should I check in my new developed function?
Thank you for your work.
> But I still have questions:
> 1. Is there an easy way to check if some class belongs to package in
> 2. Where should I check in my new developed function?
Have you read the developers giude?
On 22 bře, 14:26, YURi KARADZhOV <yuri.karadz...@gmail.com> wrote:
> I played around with sage and found some problems with desolve command.
> To solve ode diff(y(x),x)+a*y(x)+b*x+c we should first define variables and
> x = var('x')
> a,b,c=var('a b c')
> but than unless it is obvious that the dependent variable is x and
> independent is y we should write such command
Thanks for working on this problem, it would be nice to declare a,b,c
as constants, but I guess that it is not possible in Sage now. Any
idea how to extend Sage in this way?
> which is really annoying. And what is worse - we get a wrong answer
> -((a*x - 1)*b*e^(a*x)/a^2 + c*e^(a*x)/a - c)*e^(-a*x)
> but the right answer is
> -((a*x - 1)*b*e^(a*x)/a^2 + c*e^(a*x)/a - _C1)*e^(-a*x)
The problem is that
returns c, but should return some more resonable free variable, say
I am not sure if this will work for DE's involving term like y'(a*x
+b). But if you find a secure method how to find dependent and
independent variables from derivative, you can also fix bug
Another related question: if we use topoly_solve=True in solve
command, we get free variabkles, say z2 and z4, if we run the same
command for the second time, we get other variables, say z_5 and z_7.
Should we have similar behavior with free variables from desolve
command? I think that it is better to get the same answer avery time
when I solve the same equation.
Thanks for working on this.
See also http://trac.sagemath.org/sage_trac/ticket/6882 for similar
problems with %i and %e.
Neither Maple nor Maxima can solve the differential equation involving
function of symbolic expression y=function('y',a*x+b) It's not a
problem to determine what is differential function and what is it's
argument. But to solve such equation we should:
1. declare new variable t=a*x+b
2. express x in term of t x=(t-b)/a
3. substitute it into our equation and solve it
4. return to the old variable
All of this steps are able to be automatic. So I think they should be
implemented in desolve.
> Another related question: if we use topoly_solve=True in solve
> command, we get free variabkles, say z2 and z4, if we run the same
> command for the second time, we get other variables, say z_5 and z_7.
> Should we have similar behavior with free variables from desolve
> command? I think that it is better to get the same answer avery time
> when I solve the same equation.
Hmm.. It IS interesting question, but let's think why should we want
constants to be the same or different.
-If the constants are the same: it helps us to compare results we
obtain, but on the other hand it is hard to compute expression
depending on different general solution of the equation.
e.g. y'+y+1 have general solution c*exp(-x)-1
but if we want to find difference of two general solution we should
1. find all integration constants (which is unpleasant operation) - c
2. create new one - b
3. subs them into solution and find the difference which is (c-b)*exp(-
-If the constants are different: it is really easy to compute any
expression of general solutions of equation. And what is better it is
also really easy to compare two solutions being the same. If sol1-sol2
is constant then solutions sol1 and sol2 are equal (the same)
So in my opinion it is better to make difference in constants cause
it's much more convenient to deal with.
> See also http://trac.sagemath.org/sage_trac/ticket/6882 for similar
> problems with %i and %e.
So.. an easy way is to use second way I proposed before. But the right
way is to implement native desolve command in sage. I wonder is there
any Lie algebra support in sage? Cause it will help a lot.
P.S.; I think of sage as a symbolic tool and find it kinda lame. So I
tried to improve it and make it more "symbolic sage" rather then
"native python". Actually it is possible to use mixins and be "native
python" and "symbolic sage" at the same time. But I don't need such
functionality, so I ask for opinions.
What is done - I implemented some sort of topology on existing types
(simple wraps) which is more like Maple ones. I post the code and the
article after a while to explain all good and bad sides of such
approach. I will need some help to finished my topology, cause I'm
sure it is not cover all the types.
P.P.S.: I don't understand diff function. It change the
differentiation order which is sometime is bad. It should be improved
sol1-sol2 should depends on difference ci1-ci2 of course, but it is
still easier to implement
The same can be done with systems I guess and of course with bug
Anyone who are interested in can do it in similar way (look through
to get help)
My opinion is - it is necessary to create native sage module to solve
some new and easy to solve bugs:
sage: x,t=var('x t')
(c - e^x)*e^(-x)
NotImplementedError Traceback (most recent call
<ipython console> in <module>()
desolve(de, dvar, ics, ivar, show_method, contrib_ode)
375 raise NotImplementedError, "Maxima was unable
to solve this ODE."
--> 377 raise NotImplementedError, "Maxima was unable to
solve this ODE. Consider to set option contrib_ode to True."
379 if show_method:
NotImplementedError: Maxima was unable to solve this ODE. Consider to
set option contrib_ode to True.
In second case answer is the same, but c = function('c',t)
P.S.: Please look at http://groups.google.com/group/sage-devel/browse_thread/thread/f2ba2198dc5b79ed
I added new file sage/symbolic/mtype.py - which is symbolic module.
(it was marked as ? instead of M in patch log)
I think patch does not create new files. I'll try to figure it out and
fix the patch.
P.S.: If you have any ideas what should I do - please help me to save
Did you use hg_sage.add? It is explained here:
> P.S.: If you have any ideas what should I do - please help me to save
> some time.
No I didn't. Thank you for your help. I almost ready with patch.
Thank you for taking the time to fix the problems you see in the
I suggest that you provide two different patches instead of bundling
all your changes together. One for the desolve fixes, and another one
for your mtype interface.
Note that each trac ticket should be on one issue only .
This way, your fixes for the desolve function can go through the review
process quickly. I suppose the mtype interface will need to be
discussed longer. (I'll comment on it when I have more time.)
Unfortunately I can't afford to separate patches. The problem is - my
1Gb memory computer give me allocate memory errors and the clone
process stops. Even if it is succed - it takes about 20 minutes. So it
is pain for me to do another patch. Actually I use symbolic module to
deal with desolve problems so you need all functionality. If you are
able to make different patches - I can send you whatever file you ask
P.S.: patch is in the trac
I forgot to make intersection in first patch. Changes are in the
It helps us to solve
(c - integrate(e^x*D[0, 1](g)(t, x), x))*e^(-x)
without specifying of independent variable.
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
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 ) 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.
Thank you for working on this
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 ) 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
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