Did you forget to attach the code?

@acer too easy. Thanks

@Joe Riel 

I tested int warnings on another elliptic expression

https://www.mapleprimes.com/questions/233304-How-To-Find-The-Inverse-Function-Of

This time it behaved as I would have expected (i.e. no supression of warnings after repeated tries). It seems that it depends on the type of integrand. I will leave it like this. Thank you

@acer 

This comes from applying the chain rule to

and then integrating over varphi.

That's a formal step to avoid using differentials. The left hand side integrated is nothing else than the time (as a function of an angle of a pendulum in this case. If varphi_t=varphi_0 the pendulum has made a half period.) It is easy to do this with differentials but Maple does not provide such a caculus (for a good reason).

Alternativley to that I could change variables (in this case I could not apply and equation that relates the variables because this is function varphi(t) that I try do derive).

So far the left hand side does not evaluate to t(varphi_t)-t(-varphi_0) and I am obligied to replaced this confusing term by t manually.

@sursumCorda 
I found an exception from your golden ratio discovery that works as expected

solve(0 <= ln(a/2) + ln(1 + a));

In this case also an additional relation between 0 and 1 does not change the result (as in my last reply to dharr).

solve({0 <= ln(a/2) + ln(1 + a),a>1/2});

So these things seem to come together.

@Joe Riel 

Thank you for the workaround but for what reason warnings disapear (in case of varphi without t)?

Is it a (new?) mechanism that Maple does not issue the same warnings after two times?

Just for your information: Here are related posts where I was more concerned to make warnings apear:

https://www.mapleprimes.com/questions/235722-Why-A-Restart-Is-Needed-To-Get-A-Helpfull

https://www.mapleprimes.com/questions/235770-Why-No-Warning-Is-Returned-With-2D-Input

@dharr Interesting findings!

The logarithmic substitutions for the original statement with ln

solve({a > 0, ln(a) + ln(1 + a) >= 0}, a);

lead to the statement you have given that the semi-algebraic solver solves successfully (and correct IMO).

solve({a>0,a*(a+1)>=1},a);

For me it looks like that the output is not assembled correctly (i.e. < and <= are treated the same way).

Here is another output that looks incorrectly combined in an OR fashion instead of AND

solve({0 <= ln(a) + ln(1 + a), 1 <= a}, a)

 With -1<a we are back to

@sursumCorda

To your question: "But there is no warning message. Why?"

In an other instances warnings on lost solutions are passed to the user (see my reply to mmcdara).

The output of inequal plot looks old. Maybe it bypasses a newer mechansim to handle warnings to the user.

It could be that in your case the warning is suppressed by an "output handler" and not by solve.

However, I still can't see why the solution a = 2/(sqrt(5) + 1) should be treated as a separate solution. For different input the boundary of a domain is included in soluitons with a <=. In my opinion, it appears that solve could be enhanced in this particular case.

@mmcdara your code pasted in 2D

Lost_boundary.mw

@rcorless 

Maybe of interest: Maple can now analytically verify that this is a solution.

I did not know that there is an explict solution appart from a series approach. Does the "magnificent book" give details how that explicit solution can be derived? I would like to understand if and how such a derivation can be reprocuded with Maple.

Reply_HarmonicOscillator-1.mw

@sursumCorda 

The effective use of the empty symbol surprised me. I thought `` makes expression "inert" to simplification. Now a see the opposite: convert/D fully evaluates 

Do you have any explanations (or documentation beyond help(emptysymbol)) for this?

@Carl Love 

Retrospectively I can see it now.

@acer 

Thank you for taking the time to describe this detail of returning an unevaluated eval call in an easy to understand way.

I did assume that the inert functions where returned unevaluated by convert(…, D).

I have attached all possible combinations of defining IC/BCs in common math output notation (i.e., understandable also for non-Maple users) with relevant commands. Maybe it's better practice to define an IC/BC with eval(Diff…) instead of Eval(diff…), which makes convert(...,D) work without eval.  Let's see.

By the way, your foo example is a good addition to eval, Eval, D and more. Evaluating something at a point that is not returned  in a  fully evaluated representation but can (only?) be displayed with eval(...,1) which outputs the internal representation touches essential aspects of Maple worth understanding.

Download Convert_inert_IC_to_D_notation_in_various_combinations.mw

@mmcdara 

Better rendering.

Your code does not return "domains" in the same way with Maple 2023. I cannot make sense of Maples output in both cases.

Replacing < by = combined with allsolutions gives a reasonable expression for the subdomain ranges.

Domains-2_M2023.mw

Yours:

With 2023 nothing is returned for f(1)

@sursumCorda 

Finally I found something which is, combined with your DETools commands, an acceptable way.

Thanks again

Download 236511-How-To-Integrate-This-Ode-And-How-To-1_reply_2.mws