Maple help pages keep getting worst with each release.

I want all input to be displayed using Maple 1D notation, so I can copy the example to my worksheet since I only use worksheet and not document (2D) mode.

So even though the first thing I do when I open help it to turn off the 

                     view->Display examples with 2D

So it is no longer checked, I still see many pages using 2D math for input. 

Here is one example ?D  page

If I copy one such input to my worksheet now it looks like this

eveything in 2D becomes ?? when I copy it.

So one can only look but not copy?

Is there any other option to make sure, really make sure, all examples have 1D as input?

The problem is that it is all not consistent. Some examples have a mix of 2D and 1D as the above page. Some are in 2D and some are in 1D.

And this is all on the same help page!

Does no one inside Maplesoft even look at their own help pages?
 

At school the teacher always said that if we have second order ode and only one initial conditions (say y'(0)=0 or y(0)=0) then the solution should have one constant of integration in it.

And if we have no initial conditions, then the solution should have 2 constants of integrations in it.

And if we have two initial conditions, then the solution should have zero constants of integrations in it.

In this example, Maple is given second order ode with one IC. But the solution it gives when asked to solve it explicit, has no constant of integration in it at all. 

When asked to solve it using implicit, then the constant of integration shows up. 

Both solutions actually verify to be fully correct using odetest. So it looks like the solution as explicit is particular solution and not a general solution.

Why is that? Why it did not give general solution when asked to solve the ode as explicit?

Download why_missing_constant_of_integration_august_25_2024.mw

I've modified my call to coulditbe() to always use assuming real to prevent false positives.

Now I find it gives internal error Error, (in type/complex) too many levels of recursion which can not even be trapped when the thing I am checking happened to have complex I in it. (This is done in code).

So I modied the code to only do this check if there is no complex in the expression being checked.

But I think Maple should not generate such error in first place. This indicates some internal problem in Maple, correct?

Here is worksheet. (ps. updated, wrong worksheet for somereason was uploaded).

Download internal_error_too_many_Levels_from_coulditbe_august_23_2024.mw

This ode has solution when solving for the IC by hand. But Maple gives new error I did not see before when asking it to solve the ode with IC. 

No error if asked to solve the ODE without the IC.

Is this new error in dsolve? I have no earlier Maple versions to check. Below is worksheet. Solving for the IC by hand gives the solution which odetest verified.

Download internal_error_when_unable_to_find_solution_august_22_2024.mw

I was looking at coulditbe  to see if I can use it to check if odetest result can be zero or not.

But I am finding very strange results. It gives false positive too many times.

Here is an expression in x only. Plotting this it is clear it is never zero for any x value. Also asking Maple to solve this expression=0 for x, it finds no solution.  Yet, when I say coulditbe(e=0) it says true. also is(e=0) returns false.

How could this be possible?  How did coulditbe determine there is some x which makes this expression zero? Is there a way to make sure this function do not give false positive in this example? do I need to add some assumptions may be? 

Should I use is(e=0) instead of coulditbe(e=0) if  the is is more reliable?  have not used these commands much before and was looking for better ways to check if the residual from odetest can be verified it is zero or not.

I also added _EnvTry:='hard'; but it made no difference.  It still gives true.

Maple 2024.1 on windows.

Download coulditbe_question.mw

Update

I just found out that by adding  assume(x::real); before the call to coulditbe or by adding assuming, then it no longer returns true, but now returns FAIL.

This is much better. At least not a false positive.

So it looks like it was assuming x (and any other parameter than can be in the expression) can be complex and for some complex x, this expression can be zero.

So I will add this assumption now. So I think this will work. But need to test it more.

coulditbe(e=0) assuming x::real;

            FAIL