## 11354 Reputation

15 years, 87 days

## Matrix input...

@ecterrab Yes Edgardo, I participated in the discussion in MaplePrimes about matrix input a couple of years ago and thought it would be a good idea. I still think it is. I was primarily thinking of its use in the classroom, where e.g. a system of first order odes with constant coefficients theoretically are handled best as a vector equation x'(t) = A.x(t) + b(t) and handled like that in textbooks.
So thank you much for that feature and for your detailed reply.

## Documentation...

@awass In the documentation for dsolve,numeric,ivp you find under Parameters:

"odesys   set or list; ordinary differential equation(s) and initial conditions".
Here odesys refers to the first argument (see Calling Sequence).

Thus there is nothing to make you believe that dsolve/numeric/ivp will except vector equations as input.
It is no different for dsolve/numeric/bvp.

As far as the symbolic use of dsolve is concerned it appears that the situation is the same. But vector equation input is in fact accepted. That it is not as yet documented could be because it may change in future versions or it could be an oversight.
You can use a command with confidence if you follow its documentation. If a feature isn't documented then don't count on it working in the next release.

And by the way, I think the term "inconsistency" isn't quite what we are talking about.
I would rather use a term like "uniformity".
There is nothing inconsistent about dsolve/numeric not accepting vector equation input while dsolve in its symbolic use does. But there is a lack of uniformity. And so what?

## Output...

@awass Yes, vector input works symbolically. But output is not on vector form. Should it be?
Then what about the numerical situation? Surely it wouldn't take much effort to allow for vector input. But to mess with changing existing form of output here probably wouldn't be worth the trouble.

## Consistency?...

@tomleslie Since several people have participated in developing the many parts of Maple's dsolve and over many years, you can expect that kind of input "inconsistency".  Those people probably have different ideas of what is important and what is not or of what is worth doing or not. So for "consistency" you will need a dictatorship foreign to an academic environment, which hopefully Maplesoft provides for its developers.
Now having said all that, I can point out some other "inconsistencies" in this general area.
How about the input difference for pdsolve/numeric and the exact pdsolve?
Or how about these dsolve examples:

```ivp:={diff(x(t),t)=x(t),x(0)=1};
dsolve(ivp); # No variable needed, but allowed
dsolve(ivp,numeric); # No variable needed, but allowed
dsolve(ivp,series); # Error
dsolve(ivp,x(t),series); # Variable needed
dsolve(ivp,method=laplace); # Error
dsolve(ivp,x(t),method=laplace); # Variable needed
```

## Quite right...

@raskr Yes, I taught at DTU. Also I agree with you about the need for changing displayprecision to significant digits instead of decimal places.
I have typesetting = standard as default so when I tried Maple 2017.3 I found out that even that version then uses decimal places. I made a comment to the answer by Tom Leslie about that.

## typesetting=standard...

@tomleslie When displayprecision=4 and typesetting=standard we get 4 decimal places in Maple 2017.3, but with typesetting=extended and displayprecision=4 we get 4 significant digits.

## Re or no Re...

@Carl Love Actually there is no complaint from dsolve/numeric when method=dverk78 and the ode is just

`ode:= diff(y(x),x) = u; # No Re`

The result is -0.555168769092963e-2+8.10096715234306*10^(-41)*I , which has the same real part as you get with Re(u) instead of u.
Methods ck45 and rosenbrock behave as rkf45.
No complaints from lsode or gear. No complaint from classical[rk4] (here without error tolerances of course).
### It appears that method=rkf45 doesn't complain when it can "see" from the start that the problem is complex (imaginary).
Examples:

```restart;
ode:= diff(y(x),x) = 1+3*I; # A very visible I.
res:=dsolve({ode,y(0)=0},numeric,method=rkf45); #No problem
res(1); # Fine
##
g:=proc(x) if not x::numeric then 'procname(_passed)' else 1+3*I end if end proc;
odeg:=diff(y(x),x)=g(x); # I is not revealed at start
resg:=dsolve({odeg,y(0)=0},numeric,known=[g],method=rkf45); # Error
##
## In the following modified version I is visible from the start but is irrelevant if x<=10.
odeg2:=diff(y(x),x) = g(x) + piecewise(x>10,I,0);
resg2:=dsolve({odeg2,y(0)=0},numeric,known=[g],method=rkf45); # OK
resg2(1); # OK
resg2(11); # OK
```

## 2018.1...

@Mariusz Iwaniuk I have no idea. If you are being sarcastic, peace be with you. I shall correct .2 to .1.
Thank you.

## Enable engine security...

@MapleMathMatt You may be right. Mine is unchecked, so everything is allowed.

## My output...

@dharr Since I do have a file at that place and readline works for me, let me give my output from

`FileTools[Status]("F:/test.txt");`

It is
[true, true, false, false, 1533641290, 68]

The two first show that I have read and write permission for that file according to the help for FileTools[Status].

## An example for fun...

@torabi Here is an animation that was made with the speedier version of fdsolve given in FracDiff.mw above:

The animation has 25 frames so it takes a while to make.

```F:=omega*x-y^2;
G:=mu*(z-y);
H:=A*y-B*z+x*y;
params:={omega=-2.667,mu=10,A=27.3,B=1};
FGH:=unapply~(eval([F,G,H],params),t,x,y,z);
solfu:=alpha->if not alpha::numeric then 'procname(_passed)' else fdsolve(FGH,alpha,0..20,[.1,.1,.1],2000) end if;
plots:-animate(plots:-spacecurve,[solfu(alpha)[..,2..4] ],alpha=0.67..1);
```

## A faster version of Rouben's implementat...

@torabi Based on Rouben Rostamian's implementation I made a version that is considerably faster.
You can try it out. It appears to work fine, but I may work a little more on it at a later date.
I may have a look at your latest question later.

FracDiff.mw

## Try N=1000...

@torabi q is just the value of N. Try

T := 20.0;
q := 1000;

and you get this plot:

I also plotted the 3D curve (corrected):

```plots:-spacecurve([seq([sol[i][2],sol[i][3], sol[i][4]], i=0..q)],labels=[x,y,z]);
```

Actually I know nothing about fractional differential equations.

## Again it might be interesting or at least fun to compare with the corresponding ode system:

```odesys:={diff(x(t),t)=F(t,x(t),y(t),z(t)),diff(y(t),t)=G(t,x(t),y(t),z(t)),diff(z(t),t)=H(t,x(t),y(t),z(t))};
ics:={x(0)=.39, y(0)=0.66,z(0)=-.4};
# Using params:
res:=dsolve(eval(odesys,params) union ics,numeric,maxfun=10^6);
plots:-odeplot(res,[x(t),y(t),z(t)],0..20,numpoints=1000);
plots:-odeplot(res,[x(t),y(t),z(t)],100..200,numpoints=10000);
```

## typesetting=standard...

@Carl Love I have typesetting=standard and with that _EXPSEQ(1,-1) doesn't print as 1, -1. It just returns unevaluated.

```restart;
interface(typesetting=standard);
interface(prettyprint) ; # 3
_EXPSEQ(1, -1); # returns unevaluated
```

Maple 2018.1, X86 64 WINDOWS, Jun 8 2018, Build ID 1321769
Standard Worksheet Interface, Maple 2018.1, Windows 10, June 8, 2018 Build ID 1321769

 First 7 8 9 10 11 12 13 Last Page 9 of 196
﻿