I can not understand anything you said.

Could you write down the ode you want solved?

@Alfred_F 

Looking at original ode in the form   y'=f(t,y) shows that at y=0  f(t,y) is not defined at t=0.

Therefore existence and uniqueness theorem do not apply. 

But does not this mean that a solution can still exist? Google AI says

if the Picard–Lindelöf theorem fails to guarantee a unique solution, it doesn't necessarily mean a solution doesn't exist; it simply means that the conditions for a unique solution are not met, and other solutions might exist. 

Anyway, the whole point of this question is that odetest verified that the solution satisfies the ode and also the initial condition. So if this solution is wrong, then there is a bug in odetest (and the book is also wrong).

@Rouben Rostamian  

This is the solution the textbook gives. I just used odetest to verify it and it did. Here it is from back of book:

To answer your question, is it not possible to write the solution like this

                          t*y^2(t) = arctan(t)

And now taking the limit of arctan(t) as t->0 gives 0, and taking limit of t*y^2 as t->0 also gives zero. So we are OK now?

If you think this is still wrong solution, then book is wrong and also odetest has bug since it verifies it OK. 

@nm 

ALso Student:-ODEs:-ODESteps() works only on ode's, Burger's equation is pde. If you mean the same one as here

(Stange that Mapleprime will not let me edit my reply above. Clicking on more does not work. Something is wrong with Mapleprimes now. May be software update went wrong).

Unfortunately, I am unable to share the worksheet I made. 

well, you could always copy and paste the code. 

Anyway, if you mean Student:-ODEs:-ODESteps() on Burger's ode, then you are out of luck. ode step by step in Maple in limited to basic differential equations only.

maybe I misunderstood you. Why can't you use the seq command? something like

the_sequence:=seq(n*Pi/8,n=0..16);

plots:-animate(plot, [sin(x + C), x = 0 .. 2*Pi, thickness = 3], 
               C = [the_sequence], 
               background = G, 
               labels = ["", ""]
               )

@ 

Update:

per comment below, need to use this syntax:

           FeynmanIntegral(integrand,[[p__1],[p__2],[p__3]])
 

old answer

I have not used FeynmanIntegral but you can always integrate it one at a time instead of passing a list for the integration variable which FeynmanIntegral does not like the list form for multiple integration.

Something like this

Download feynman_march_9_2025.mw

But notice the messages it generated `Expected denominator with factors quadratic in `*p__2*` representing propagators; received the factor(s)`

That is something to look into.

This has nothing to do with Latex. Maple rewrites things itself, (based on some internal representation it chooses how to arrange terms when it stores things in memory) and that is what you see on the screen.

Latex relfects what you see on the screen, not how you type the expressions.

Example. When you type

R:=exp(x+L*y+r*z)

Maple replies with 

See? your x is no longer the first term as when you typed it in. The Latex is based on the above output (i.e. the internal representation)

This happens with other CAS systems also, not just Maple:

is the output in English when you type "dir C:" in windows command window? if not, then this is windows own configuration issue and nothing to do with Maple. Maple just gives you what the windows command gave.

This looks like a bug in Maple own code somewhere. 

@acer 

Yes, Mint now show 

 These local variables were not declared explicitly:  sol

But unfortunatly, can't use your workaround in actual code, since proc() now is not called, since it is mapped to empty list.

I think now mint is wrong here.

Here is proof:

Maple itself, gives warning that `sol` is implicitly declared local  but mint does not. This is foo.mpl:

foo := proc()
    local C1,y,x;

    proc()
         sol:=y(x)=  C1;
         print("In  anonymous");
    end proc();

end proc:

foo();

This is what mint says

Procedure foo() on lines 1 to 9
  These local variables were never used:  C1, x, y

No mention of sol !

But this is what Maple itself says when I actually run foo.mpl:

>"C:\Program Files\Maple 2024\bin.X86_64_WINDOWS\cmaple.exe" foo.mpl

Warning, (in anonymous procedure within foo) `sol` is implicitly declared local |foo.mpl:5|

> foo();
                                                                                 "In  anonymous"

You see? Maple gave warning. Maple is correct by giving warning that sol is not declared. But this is something that mint should also have done. After all, that is what mint is supposed to do.

Do you think this is a bug in mint then? I have not reported this yet. 

@acer 

The name sol is implicitly declared local within that anonymous procedure

Does this mean semantics of anonymous procedure  is different than named one when it comes to local variables? Because on named proc, mint gives this

foo := proc()
local C1;
local y,x;

    C1:= `tools/genglobal`(_C); 
    sol:=y(x)=  C1; 

end proc;

This is mint output

Procedure foo() on lines 1 to 8
  These global variables start with an _:  _C
  These local variables were used but never assigned a value:  x, y
  These local variables were assigned a value, but otherwise unused:  sol
  These local variables were not declared explicitly:  sol

Notice it says These local variables were not declared explicitly:  sol 

I think this is what I meant, i.e. mint should warn the user, whether this line of code sol:=y(x)= C1; is inside anonymous procedure or outside, about sol not being declared. It would be better to do so.

btw, I always declare local variables that I use, even inside anonymous procedure. But use mint to detect places where I forget to do so.

@mmcdara 

Here is an example, where I just now wanted to check if solution of ode has form    A*ln(y)=B*ln(x)+C, where here C is constant of integration. By hand we rewrite this by raising both sides to exponential giving   y^A=C*x^B. But wanted to do this only of the solution has this pattern with A,B not ln and no other form. Normally A,B will be constants, but ok to be functions, but not has ln.

For me pattern matching was the most logical way to do it. I can't just raise both sides to exponential for other pattern directly, else it will mess up the solution form.

May be there is a way to do this using structured types such as evalidents and such commands, I do not know, if there is, it will probably be more complicated.

So here is a quick proc that does this. Ofcourse, I need to test this more, I just wrote it in 30 minutes. but this is just to give the idea.

Download pattern_matching_use.mw

@acer 

I am ofcourse can't be sure it is cache/memory problems. It is just an educated guess based on earlier problems I had. For example Why-Odetest-Sometimes-Works-And-Sometimes. But will change the wording to say I think it can be cache issue.

I also said in one of the update the following

So there is something else that causes this. If someone can suggest other things to try, that will be great.

The "else" above refers to clearing memory tables and cache.

@aroche 

Could you please look into Bug-Report-Order-Of-Using-Odetest-Changes

I find big problem. With Physics 1840 it works OK. Starting with Physics 1841, it fails. By works and fails, I mean using odetest to verify an ode. 

Please look at the bottom of my question above and you will see two worksheets showing clearly this. The one using Physics 1840 works. No timeout and odetest returns zero. When changing to Physics 1841, with same exact code, now it gives timeout and fails.

All on windows 10, Maple 2024.2

If you like me to try something else, feel free to let me know.