There are two main issues. First from software design point of view, it is not good idea to couple two separate functionalities into one function. dsolve() should just solve an ode and nothing else. odetest() should just check that a solution verifies the ode.

Even if it is optional for dsolve to test its solution before, I do not think it will be good to combine them. Too much complexity. Also, dsolve in the process of solving an ode, could need to solve auxillary ode's. Does it need to internally call odetest on each one of these?

But it is very easy to make your own **my_dsolve()** function which first calls dsolve, then calls odetest to verify maple solution.

This is what I do. Here is a basic algorithm how this can be done

my_dsolve:=proc(ode, IC, any other options.....)
maple_solution:= dsolve( [ode,IC], any other options given ,..);
if maple_solution not null then
#might need map here if more than one solution
the_residual := map(X->odetest(X,[ode,IC]),[maple_solution]);
if all the_residual entries are zero's then
RETURN(maple_solution);
else
RETURN(FAIL); #or return solution but with warning message. You decide.
end if;
else
RETURN( maple_solution); #nothing to verify. No solution
end if;
end proc;

The second and more important issue is that odetest() is not always guaranteed to work.

It can hang on hard solutions, and so now dsolve have to deal with this new problem. How much timeoutput to use? How does it know how much to wait? It also means dsolve will now take minutes to return a solution instead of seconds.

It also would mean it will not return solutions to ode's which it does now return a solution because it could not verify the solution (even though the solution could most likely be correct). I do not think people will be happy with this change.

odetest can also return false negative. i.e. it can return FAIL on solutions which is correct. see examples below.

It is also possible that assumptions are need to verify the solution is correct or not. Sometimes I have to try 20 different assumptions to find one which makes odetest give zero.

But anything you do, do not use coulditbe() on result on odetest. This can easily give false positive. i.e. saying the residual can be zero, but the solution is wrong. But coulditbe() checks if the residual can be zero at just one point.

Here are 10 examples showing the type of problems. I have hundreds more like this.

So making dsolve() do odetest() and return solution only if odetest verifies the solution is probably not something Maplesoft will want to do.

I think it is better that Maplesoft work more on improving odetest() itself and make it more robust but keep dsolve and odetest functions separate.

The problem of showing a solution verifies an ode is mathematically not an easy one. It is easy one for simple odes and simple solutions. But not so on much more complicated cases.

At school, the teacher says to just plug into the ode the solution, and then see if we get zero on both sides of the equation. But in real life this is not always easy to check if something is zero or not.

Worksheet attached

Download on_odetest_sept_12_2024.mw