@acer 
Thank you. I realised in the meantime that a change in sign only shifts the phase portrait by pi with the implication that
for x->infinity the limiting value for the angle will become _Z*2*pi (_Z depending on the ICs). 

@sand 
You mention conservation of energy. The consequence is that only one initial condition is needed. The other IC can be deduced from it. The need of only one IC to find a solution for a second oder ODE is something I was never happy with. Now I have a satisfying explanation.
I assume that the difference in the solutions can be resolved by adding here an integration constant that takes an appropriate initial velocity into account.

ode_2 := map(int, ode_1, x);

This should remove _C1 from your solution.

By the way: Including laws of physics is not required. I googled a bit. Treating the system as a hamiltonian system and seeking a scalar function $H(y,y\_dot)$ that is constant along the trajectories of the flow in phase space leads to the same result as conservation of energy.
What makes this "finding" (for me) interesting is its implication on partial solutions of ODEs and testing them.
The existance of such scalar functions restricts possible solutions and in the context of 

@nm question of testing odes could provide conclusive answers. I have to think about it.

Maybe the archtitect of odetest @ecterrab can tell if it would make sense to make odetest even more powerfull in this sense. Maybe it is already.

@sand15 
I am getting an error here with Maple 2025

I did expect to see multiples of pi, not fractions. 

In eq(1) there is a sign missing. I am not sure if than makes a difference on the results

@TechnicalSupport 

After your response I could sort out the misunderstanding with support and transferred the Maple.ini files. 

As you might have seen, my original mail was in my mother tongue to a support address that I have used for years. I did expect a reply from staff that I have known for years. The reply from a new person was most likely machine translated (as my original mail was probably also machine translated). The process of back-and-forth translation is not perfect and might have contributed to my impression that I was talking to a bot. What adds to this impression is the almost too perfect and polite wording of the replies. On my side, I am AI fatigued, which has also contributed to the wrong suspicion.

Anyway, thank you for clarifying. This is important. 

@acer 

Thanks for clarifying! 

@Paul 

If I understand correctly Mathpix (and not OpenAI) is performing the document import.

Thank you for the clarification

@aroche 

Done already. Thank you for following up!

@sand15 @nm @dharr @vv

If the approach of applying limit per default on eval in case infinity occurs is the way to deal with incorrect output, then eval could be modified to first check for the values infinity, +infinity and -infinity and then applying limit. Such a modification would remove the potential loss of computational efficiency in case of complex expressions.

Maybe a workaround for nm: Define eval local and then re-define eval with a procedure that checks for infinities and in case applies limit. This might reduce efforts adapting exiting code.

Concerning the above discussion about evaluation I consulted the help system for Maples defintion of evaluation but could not find anything. That is rather good news because a potential modification of eval is not bound by a strict definition (yet).

@nm Here is a removable singularity that at least throws an error.

(x^2 - 1)/(x-1);
eval(normal(%),x=1);
eval(%%,x=1);
                              2    
                             x  - 1
                             ------
                             x - 1 

                               2

Error, numeric exception: division by zero

Maple is consistend in its behaviour and definitions. See ?Definition,removable

The case with infinity is somehow unlucky because it evaluates to something wrong. Ideally Maple should check for removable singularities and inform the user that there is an equivalent form. Doing so could lead to reduced performance if expressions are complex.

There is no external tracking of support tickets. I’m quite certain of that, because if there was, those things are usually mentioned in the automated reply as soon as a support request is received by email.

Did a "Technical Support Analyst" (Mr./Mrs. Nur) replied to your question?

@acer 

Thanks for letting me know. I do not think this feature of simplify adds value. Keeping inert fuctions and simplification at the same time will be difficult.

@acer 

You said: I wonder how it might ever learn that %sqrt is an inert form?

It should. It's a question of training data and money spend for training. Gemini knows it already

Looks like that the agent has to go back to agent school ,-)

@acer 

Very instructive! Thank you

By the way, the AI assistant has proposed a "safer, clearer alternative" of your code...which does not work ;-) because "%" is interpreted incorrectly.

Java_Printing.pdf

@acer 

I am only interested in sqrt(2)/2

@acer 

Sorry, I got confused by AI. I will delete sheet from the title,
This was my original prompt

(I hoped that the AI assistant is smart enough to assume that this question relates to the Maple version in which the question was posed.)

Then I was asked to specify which version.

Thank you for your clear and precise answer!

@acer 

I will do this. It's still a bit unclear what is going on: Since I did not import preferences I did expect to loose my favorites but somehow they are back and working. (My selection of palettes in Maple 2025 was not restored.)