## 6778 Reputation

10 years, 34 days

## MaplePrimes Activity

### These are replies submitted by nm

I understand that the default for y means default. But I need the actual numerical y range used. Using your example

p:=plot(sin(x),x=-1..10):
op(select(type,p,specfunc(VIEW)));

gives

VIEW(-1.0000000000 .. 10.0000000000, DEFAULT, _ATTRIBUTE("source" = "mathdefault"))

WHich does not tell the program what the actual y-range used is. Compare to

lprint(p)

which has that information but in different location:

"originalview" = [-.986250000000000071 .. 9.98625000000000007, -1. .. 1.]]))

The above has the actual numerical values for both x and y used. That is what I want. Not "default" as I can't use "default" in my other plots I am doing (phase diagrams), where it needs the acual values for y range.

Thanks but this gives only the x range. I need to also obtain the y-range used. Is it possible to modify it to obtain the both?

Why is it partial derivative? It only shows in both equation as changing w.r.t. z only.

You have so many mistakes in just writing what you want solved.

1) v shows as function of z only. So why use partial derivatives? Where will you use  v(z,0) =0 ?

2) There is no K1 in the equations

3) There is no alpha3 in the equations

4) There is no thetab in the equations.

5) There is no eta1 in the equations.

Trying to make the symbols that show in your equations latex match the numerical values you give will be a good start.

Would you know why it works with no error with plus but not with minus?

i.e. it works with  1+p.q but not with 1-p.q  ? good improvement.

Hello;

I just always thought of Mathematica Together as similar to Maple's combine, simply because Mathematica has no combine command, only Together command, that is all.

Ok, thanks, normal works, so is numer/denom

I still do not understand why combine does not work as expected. I guess this is just how it was designed.

Hello;

Based on what you said, this is why I always wondered why Maple sometimes changes the implicit solution to explicit one when adding initial conditions, which will cause odetest not to verify the solution then.

Using same ODE I gave, this is Maple's solution

```ode:=sqrt(y(x))+(1+x)*diff(y(x),x)=0:
ic:=y(0) = 1:
sol:=dsolve([ode,ic]);
``` But this does not verify as is

`odetest(sol,[ode,ic])` It will verify, by getting the correct region (in this case when csgn() is -1), But this requires more work from the user to figure that out.

I wonder why Maple did not solve the constant of integration from the general solution (which is implicit, good) and kept the IVP solution implicit? This would cause odetest to verify it as is, with no more post-processing. For the above:

```ode:=sqrt(y(x))+(1+x)*diff(y(x),x)=0:
ic:=y(0) = 1:
sol:=dsolve(ode); #solve with no IC
``` Which is implicit. Now solve for _C1 but keep the solution implicit, something like

```eq:=eval(sol,[y(x)=1,x=0]);
the_constant:=PDEtools:-Solve(eq,_C1);
new_sol := eval(sol,the_constant)
``` Now the IVP solution remained implicit. The difference, is that now odetest verifies it as is

`odetest(new_sol,[ode,ic])` Any insight why dsolve does not do this instead of making the final IVP explicit which makes it harder to odetest it?  I do know that one can force the IVP solution to be implicit using

```sol:=dsolve([ode,ic],'implicit');
``` But why not do this by default in such cases, since it generates solution that will odetest to 0 as is.Notice in this case, the general solution came out implicit on its own, without using the option 'implicit'. But not the IVP solution. There one had to force the solution to show as implicit.

This is what I do not understand why.

Maple 2022.1 on windows 10

Well, then Reduce must have used magic to find out.

As a user, I do not care what methods are used under the cover. If it had to use heuristics, tricks or just math, the point is, as a user there should not be a need for one to spend time doing many trial and error and tricks to find this out.

Maple is simply weak here. No point of definding it. Maple is good also in many other areas, but not in this area.

Thanks, but this approach might work for interactive trial and error by looking at the expression,.

In a program, when the expression can be anything, this is not practical approach to do something like this.

simplification is sometimes "art and craft":

Or one can just use the Reduce command to find where it is zero. No need for trials, art or craft. Just math is needed.

Maple is a little weak in this area.

Unfortunately, your trick did not work on another case I found Here is Maple code.  Would you know of another trick to use? Thanks.

 > restart;
 > r:=sqrt(-x + 1/2 - sqrt(-4*x + 1)/2) + 1/2 - sqrt(-4*x + 1)/2 ; simplify(combine(r)) assuming x<=0; simplify(r) assuming x<=0; simplify(r,symbolic) assuming x<=0; simplify(r,sqrt) assuming x<=0; simplify(expand(r)) assuming x<=0;      > plot(r,x=-5..1) >

Thanks, I did not know about

`frontend(solve,[eq,A],[{`=`}]);`

I do not think I want to replace solve with isolate. I had cases where isolate did not do as well as solve in all case.

But do you recommend then changing solve to use frontend in front of it as you show? I am not sure now what the ramification of doing this. Will solve still work the same as before, but without the auto simplication part? If that is the only difference, then I will switch to using frontend(solve...) but since I never used it before like this, I need to first find out if it will have any negative effects in other cases or not.

You are "misleading" Maple into looking at the ODE as one of the d'Alembert type.

but it is d'Alembert ode. Maple itself says so

```restart;
ode:=diff(y(x),x)=sqrt(1+x+y(x)):
``` Another point, is that surely Maple will not have given a solution using a method if the method is not applicable to the ODE?

Maple ode solver is the best in the industry, and will not just use the wrong method on an ode and give wrong solutions without any checking internally that the method is applicable to the ode.

don't impose the dalembert requirement.

I am not imposing anything. When the advisor gives the types of the ode, then a user can select which method to apply. Without this, Maple internally chooses one.

```restart;
ode:=diff(y(x),x)=sqrt(1+x+y(x)):
dsolve(ode);

sol:=DEtools:-dalembertsol(ode);
sol:=DEtools:-genhomosol(ode);
``` If one tries to tell Maple to use a method not applicable to the ode, it will produce no solutions as expected. But it can't just make up ones.

```ode:=diff(y(x),x)=sqrt(1+x+y(x)):
DEtools:-abelsol(ode)
``` fyi, ,I found a workaround.

 > restart; ode:=diff(y(x),x)=x*(y(x)^2-1)^(2/3); sol:=DEtools:-exactsol(ode); odetest(sol,ode);   >

 1 2 3 4 5 6 7 Last Page 1 of 59