Hi @nm,

Thanks for this report. I agree that this ODE is known to be unsolvable (in terms of known mathematical functions) and therefore dsolve should not waste time trying to solve it. As such, we've added a special case to return NULL for this ODE and others in the same class. The fix is distributed for everybody using Maple 2025 within the Maple Customer Support Updates v.13 or newer:

Download MP240255.mw

Please refer to the announcement of the new Maple Customer Support Updates for more detailed installation and usage instructions.

Austin Roche
Maplesoft

Hi @nm,

Thank you for collecting these reports. The [edit: simplify, symgen, and odetest] bugs have been fixed internally for a while but we have been working on a new system of updates to publish these fixes. The announcement of the new Maple Customer Support Updates was just made today.

The examples you list [edit: except for the int examples] are all fixed with the latest version of the new Maple Customer Support Updates. The fixes are distributed for everybody using Maple 2025 within the Maplesoft Customer Support Updates v.10 or newer.

In order to activate these updates, you can either download them via the Maple Cloud, or simply issue the following command:

  PackageTools:-Install(5137472255164416);

In particular, installing this Cloud package introduces a new Maple library package named SupportTools which allows you to manage the Updates in a more convenient way.

Once installed, you can test that the fixes mentioned above are in place as follows:

Please refer to the announcement of the new Maple Customer Support Updates for more detailed installation and usage instructions.

Austin Roche
Maplesoft

Hi @nm,

After a bit of experimentation, I found two solutions satisfying the IC as follows:

y(x) = x^(2/3)

and

y(x) = ((-1/x)^(1/3)/2 + sqrt(-3*(-1/x)^(2/3))/2)*x

Although the second looks more complicated, it's actually just the complex conjugate of the first (at least for real x).

The algorithm in dsolve which tries to find these solutions starts with the general solution and applies the ICs to try to determine the value of the integration constant. In this case, there is no finite solution for the integration constant from the given general solution which satisfies the ICs. You'd need to redefine it via something like c__1 = -ln(c__2) and then solve for c__2 and then simplify the result and then you'd find that the value of c__2 you need is actually 0 - which doesn't translate to a sensible corresponding value for c__1. There is code in dsolve to deal with these problems, but it seems that in this example it needs a bit of improvement.

Thanks for the report. I will continue to investigate!

Cheers,
   Austin

Hi @ider,

Thank you for this helpful report! This was an old bug but it has been fixed for Maple2025:

Download question_fixed3.mw

Cheers,

    Austin Roche
    Maplesoft

Hi @nm,

Thanks for this report. The bug is fixed and the new solution is simply y(x) = x^(-a).

There were two problems here. Addressing either one of them fixes the problem. I've fixed one of them, as follows. The general solution includes two solutions, but neither of these evalautes to the desired solution satisfying y(1)=1 for a finite value of c__1. However, one can get this particular solution by taking the limit as c__1 goes to infinity:

Download 239927_a.mw

This process of taking an infinite limit is only tried when it's required by the ICs, and in that case there is some work to do to determine exactly which infinite limit is required. In this case there was a limit of the form limit(f(x), x=t*infinity) for some expression t, and it turns out that is not a valid syntax for limit, but adjusting it to limit(eval(f(x), x=t*inf), inf=infinity) was sufficient to work around this issue.

The second potential fix is to just include the missing particular solution (i.e. y = x^(-a)) in the general solution to begin with. There were some problems with that approach but they do not look insumountable, so that could potentially be addressed soon as well.

The fix is distributed for everybody using Maple 2024 within the Maplesoft Physics Updates v.1845 or newer. To install the Updates, open Maple and input Physics:-Version(latest).

Austin Roche
Maplesoft

Hi @nm,

Thanks for this report. There was a recursion error in `trig/normal` which has now been fixed:

> `trig/normal`(((-2472*3^(1/2)-4288)*2^(1/2)+3496*3^(1/2)+6064)*(10+7*2^(1/2))^(1/2)+(6008*6^(1/2)+10408*2^(1/2)-8496*3^(1/2)-14720)*cos(1/24*Pi));
Error, (in trig/normal/sincosargs) too many levels of recursion

The call to odetest should now consistently return 0:

Download trig_normal2.mw

The fix is distributed for everybody using Maple 2024 within the Maplesoft Physics Updates v.1843 or newer. To install the Updates, open Maple and input Physics:-Version(latest).

Austin Roche
Maplesoft

Hi @nm,

Thanks for this report. The problem as mentioned by @ecterrab was a non-idempotency in 'factor': Repeated calls to factor produced unstable results:

poly := 12*I*x^2*KummerM(3/4+1/8*I*2^(1/2),3/2,I*2^(1/2)*x^2)*y+8*I*x*KummerM(3/4+1/8*I*2^(1/2),3/2,I*2^(1/2)*x^2)*x1-8*x*KummerM(3/4+1/8*I*2^(1/2),3/2,I*2^(1/2)*x^2)*x1*2^(1/2)+4*I*KummerM(1/8*I*2^(1/2)+7/4,3/2,I*2^(1/2)*x^2)*y+3*KummerM(3/4+1/8*I*2^(1/2),3/2,I*2^(1/2)*x^2)*2^(1/2)*y-7*KummerM(1/8*I*2^(1/2)+7/4,3/2,I*2^(1/2)*x^2)*2^(1/2)*y:

> factor(%);
I*(12*x^2*KummerM(3/4+1/8*I*2^(1/2),3/2,I*2^(1/2)*x^2)*y+8*I*2^(1/2)*KummerM(3/4+1/8*I*2^(1/2),3/2,I*2^(1/2)*x^2)*x*x1+8*x*KummerM(3/4+1/8*I*2^(1/2),3/2,I*2^(1/2)*x^2)*x1-3*I*2^(1/2)*KummerM(3/4+1/8*I*2^(1/2),3/2,I*2^(1/2)*x^2)*y+7*I*2^(1/2)*KummerM(1/8*I*2^(1/2)+7/4,3/2,I*2^(1/2)*x^2)*y+4*KummerM(1/8*I*2^(1/2)+7/4,3/2,I*2^(1/2)*x^2)*y)

> factor(%);
12*I*x^2*KummerM(3/4+1/8*I*2^(1/2),3/2,I*2^(1/2)*x^2)*y+8*I*x*KummerM(3/4+1/8*I*2^(1/2),3/2,I*2^(1/2)*x^2)*x1-8*x*KummerM(3/4+1/8*I*2^(1/2),3/2,I*2^(1/2)*x^2)*x1*2^(1/2)+4*I*KummerM(1/8*I*2^(1/2)+7/4,3/2,I*2^(1/2)*x^2)*y+3*KummerM(3/4+1/8*I*2^(1/2),3/2,I*2^(1/2)*x^2)*2^(1/2)*y-7*KummerM(1/8*I*2^(1/2)+7/4,3/2,I*2^(1/2)*x^2)*2^(1/2)*y

That problem has now been fixed, and consequently there is now a correct result from dsolve:

Download Kummer_solution.mw

As shown, the result unfortunately still requires simplify to get it down to reasonable size. I'll keep investigating why that is and see if it can be improved.

The fix is distributed for everybody using Maple 2024 within the Maplesoft Physics Updates v.1842 or newer. To install the Updates, open Maple and input Physics:-Version(latest).

Austin Roche
Maplesoft

Hi @nm,

Thanks for this important report. Your analysis was spot on: The Cauchy-Euler solver was attempted despite the ODE not being in that class. The conditions were not being checked properly and that has now been fixed. The new result is an error telling that the ODE is not supported by the Student:-ODEs package:

By the way, regarding the remark by @Alfred_F, dsolve gets an equivalent solution that needs a bit of massaging to get the desired form:

The fix is distributed for everybody using Maple 2024 within the Maplesoft Physics Updates v.1840 or newer. To install the Updates, open Maple and input Physics:-Version(latest).

Austin Roche
Maplesoft

Hi @nm,

Thank you for this helpful report! The bug has been fixed and we now get the expected answer of [0,0] for the result of odetest comparing the solution with the ode and the IC:

Download odetest_with_IC.mw

A note about what was going wrong: In the presence of an IC, implicit solutions in certain forms were wrongly being classified as explicit, and then the explicit tester was being used which was not effective. So in fact the order of the results was not switched! The 0 result was indeed a verification that the IC was satisfied, and the non-0 result was actually a failure to verify that the ODE itself was satisfied. This can be checked by providing a different IC as part of the test, and noticing that in that case both results are now non-0 (note that I am removing the fix to make this test):

Download previous_odetest_with_bad_IC.mw

The fix is distributed for everybody using Maple 2024 within the Maplesoft Physics Updates v.1839 or newer. To install the Updates, open Maple and input Physics:-Version(latest).

Austin Roche
Maplesoft

Hi @nm,

Thanks again for finding this bug. The bug has been fixed and now after finding a polynomial solution via the series method, this particular solution is used to reduce the order and the reduced order ODE can also be solved, leading to the general solution of the original problem.

Download steps.mw
The fix is distributed for everybody using Maple 2024 within the Maplesoft Physics Updates v.1836 or newer. To install the Updates, open Maple and input Physics:-Version(latest).

Austin Roche
Maplesoft

Hi @nm,

This appears to be a problem in the RegularChains library and is currently under investigation.

Thank you for the report!

Austin Roche
Maplesoft

Hi Dmitry,

Thank you very much for this helpful report!

As mentioned by @ecterrab, there was an issue in `simplify/RootOf` that was encountered during the solving process for this problem. This issue has now been fixed, and the ode is now solvable via dsolve, returning a large answer. The answer is verifiable with odetest, and can be simplified to something of a more reasonable size by calling simplify:

Download dsolve_solve_RootOf_issue2.mw

Moreover, it should be noted that the alternative approach mentioned by @dharr actually leads to an even more convenient answer.

The fix is distributed for everybody using Maple 2024.1 within the Maplesoft Physics Updates v.1816 or newer. To install the Updates, open Maple and input Physics:-Version(latest)

Austin Roche
Maplesoft

Hi,

Thank you for finding this bug! It's been fixed, but as mentioned by @Thomas Richard, the ODE is beyond the scope of what the Student package can handle, so the new result is just an error message saying that this ODE is not supported:

Download Physicsv1811.mw

The fix is distributed for everybody using Maple 2024 within the Maplesoft Physics Updates v.1811 or newer. To install the Updates, open Maple and input Physics:-Version(latest)

Austin Roche
Maplesoft

Hi,

Thanks for this report. A fix has been implemented internally and is expected to be avaiable in the next Physics update (edit: it's there already in v.1793, see comment below), as well as in the next full release of Maple.

The new answer is 'true'.

Austin Roche
Software Architect
Mathematical Software
Maplesoft

Hi @nm,

Just to let you know that I've made some changes and now the derivative is being solved for first, so for this example y(x)*y'(x) = 0 the solution is now the simpler y(x) = c as expected:

As usual, the fix is included within the Maplesoft Physics Updates v.1758 or newer. To install the Updates, open Maple and input Physics:-Version(latest)

Austin Roche
Maplesoft