OK, perhaps we have misunderstood each other. Most likely you are correct in a strict mathematical sense. However, what I needed was a procedure that would return the highest shift from an equation, no matter if the previous shifts are or are not involved in the equation. For example eq1 := y(t+2) = y(t)*u(t)^2; eq2 := y(t+2) = u(t+1)+u(t)^2; eq3 := y(t+2) = y(t+1)+u(t+1); something2(eq1,y); # this should return 2 something2(eq2,y); # this should return 2 as well something2(eq1,u); # this should return 0 something2(eq2,u); # this should return 1 something2(eq2,v); # this should return -infinity something2(eq3,y); # this should return 2 something2(eq3,u); # this should return 1 Next time I will try to speak my mind more clearly. Anyway, thank you for your code, it helped me a lot.

OK, perhaps we have misunderstood each other. Most likely you are correct in a strict mathematical sense. However, what I needed was a procedure that would return the highest shift from an equation, no matter if the previous shifts are or are not involved in the equation. For example eq1 := y(t+2) = y(t)*u(t)^2; eq2 := y(t+2) = u(t+1)+u(t)^2; eq3 := y(t+2) = y(t+1)+u(t+1); something2(eq1,y); # this should return 2 something2(eq2,y); # this should return 2 as well something2(eq1,u); # this should return 0 something2(eq2,u); # this should return 1 something2(eq2,v); # this should return -infinity something2(eq3,y); # this should return 2 something2(eq3,u); # this should return 1 Next time I will try to speak my mind more clearly. Anyway, thank you for your code, it helped me a lot.

While using the procedure above I have come across a small leak in the code. If eq := y(t+2)=u(t)+u(t+1)^2; then something(eq,y) returns 0 instead of 2. I have tried to fix it modifying the code as follows something2 := proc(eq,v) local a, b; a := map(op, map(op, indets(eq, specfunc(anything,v)))); b := max(op(map(select,type,a,numeric))); if nops(a)>0 and b=-infinity then 0; else b; end if; end proc: which seems to work OK. However, if there is some bug in the code, please do let me know. Thank you!

While using the procedure above I have come across a small leak in the code. If eq := y(t+2)=u(t)+u(t+1)^2; then something(eq,y) returns 0 instead of 2. I have tried to fix it modifying the code as follows something2 := proc(eq,v) local a, b; a := map(op, map(op, indets(eq, specfunc(anything,v)))); b := max(op(map(select,type,a,numeric))); if nops(a)>0 and b=-infinity then 0; else b; end if; end proc: which seems to work OK. However, if there is some bug in the code, please do let me know. Thank you!

I am not sure if anybody is interested in this, as for quite some time already it seems that I am discussing here just with myself (since the release of Maple 11 and MTM11 as if Maplesoft has completely forgotten that there might be users who still work with Maple 10 and MTM10)... Anyway, I have come across another example of different behaviour of MTM10 and MATLAB's Symbolic Math Toolbox, concerning the "solve" command. With MATLAB+MTM10 >> p = solve('-sqrt(a)+b,sqrt(a)-sqrt(c)','a,b') p = `struct('a',c,'b',c^(1/2))` or >> p = solve('-sqrt(a)+b,sqrt(a)-sqrt(c)','a,b') p = a: c b: c^(1/2) the first output corresponding to "maple compaton" and the second to "maple compatoff". Although the result of the calculation is OK >> p.a ans = c >> p.b ans = c^(1/2) the structure returned is not, since >> isstruct(p) ans = 0 Pure MATLAB output (i.e. MATLAB+SMT) is as follows: >> p = solve('-sqrt(a)+b,sqrt(a)-sqrt(c)','a,b') p = a: [1x1 sym] b: [1x1 sym] >> p.a ans = c >> p.b ans = c^(1/2) >> isstruct(p) ans = 1 Consequently, of course, all custom applications that rely on the fact that "isstruct" is true for structures returned by "solve" fail. Unfortunately, I have no patch for this yet - but if I manage to cope with it somehow, I will certainly post it here.

After some debugging/breakpointing of the MTM-10 files I've found out that to put things right both the sym.m and the $MATLAB/toolbox/maple/subs.m files need to be patched. The patch for the former is here 36_sym10c.txt and the patch for the latter here 36_subs.txt.

Using Maple 10's Maple Toolbox for Matlab, I've come across some bugs of the patch above. And because this discussion here was "dead" for more than a month, I've realised that if I want to get things work I have to cope with it myself. Now that I've fixed some of the bugs I discovered, I've decided to post my patch here, too. Here it is: 36_sym10c.txt And here are the issues it addresses: var_str = '[cos(a) sin(b); sin(a) cos(b)]' % symbolic matrix represented as char var_sym = sym(var_str) This failed with the 36_sym10b.txt patch because the if ~exist(a(x:k-1)) clause returned false (there was a parameter a in the procedure). Consequently, a was not declared as a symbol and the whole command failed. I've changed the condition to if ~exist(a(x:k-1),'builtin')". However, this is still not perfect, because e.g. var_str = '[cos(f(a+b)) sin(b); sin(a) cos(b)]' % symbolic matrix represented as char var_sym = sym(var_str) still fails (although SMT can process it correctly) but at least it is better than it was before. The next modification was motivated by a different behaviour of MTM and SMT. Whereas with SMT >> M = '[1; 0]' M = [1; 0] >> sM = sym(M) sM = 1 0 >> class(sM) ans = sym the result is "sym", with MTM + the previous patch >> class(sM) ans = double the result was "double". This caused errors later, when subsequent commands in custom programs assumed it to be "sym". The remedy was to replace "p = eval(orig_mpl_str_cmd_88324)" in the previous patch with "p = sym(eval(orig_mpl_str_cmd_88324))". Finally, these two changes accounted also for the matrix-case in subs that I reported in the subs thread below (although one additional modification to the subs.m file was necessary, too). So that's it for today. I hope that one day there will be an official Maplesoft patch for MTM-10 that will fix all the problems...

I guess that the main problem with me is that I'm not a mathematician and thus don't call things their proper names... in the declaration of the skew_algebra, for instance, it seems that I should have written that I do need to express "delay-differential equations" (if only I knew they should be called this way) using Ore_algebra or OreTools. Now what's behind it all: I can hardly explain the problem in its full length here so just to give you some idea - there's a research going on, which is connected with nonlinear control theory. It has been proved that nonlinear control systems without a delay can be alternatively expressed using differential forms and univariate Ore polynomials acting as operators on the forms. This I've managed to implement in Maple with OreTools (more or less). However, if time-delayed systems are considered, multivariate Ore polynomials are needed and that's basically the source of my current trouble. It seems that to implement them I should need the declaration which you said is "not linear, and not supported" (why is it not linear, by the way? could you please explain it in a simple way?) And, perhaps, what about the calculation of the GCD above? Is there a mistake somewhere or it cannot be done with Ore_algebra at all? Also, do you think it's possible to extend OreTools to handle two-variate Ore polynomials (I've tried to trace the SetOreRing function but couldn't get into the DifferentialRing module - not yet at least)... Thanks in advance! (for any reply)

I guess that the main problem with me is that I'm not a mathematician and thus don't call things their proper names... in the declaration of the skew_algebra, for instance, it seems that I should have written that I do need to express "delay-differential equations" (if only I knew they should be called this way) using Ore_algebra or OreTools. Now what's behind it all: I can hardly explain the problem in its full length here so just to give you some idea - there's a research going on, which is connected with nonlinear control theory. It has been proved that nonlinear control systems without a delay can be alternatively expressed using differential forms and univariate Ore polynomials acting as operators on the forms. This I've managed to implement in Maple with OreTools (more or less). However, if time-delayed systems are considered, multivariate Ore polynomials are needed and that's basically the source of my current trouble. It seems that to implement them I should need the declaration which you said is "not linear, and not supported" (why is it not linear, by the way? could you please explain it in a simple way?) And, perhaps, what about the calculation of the GCD above? Is there a mistake somewhere or it cannot be done with Ore_algebra at all? Also, do you think it's possible to extend OreTools to handle two-variate Ore polynomials (I've tried to trace the SetOreRing function but couldn't get into the DifferentialRing module - not yet at least)... Thanks in advance! (for any reply)

Hello JacquesC! Thank you very much. Now the skew-multiplication is OK. Unfortunately, the same trick does not work when calculating the GCD of Ore polynomials. For example, when I tried to translate with(OreTools): S:=SetOreRing(t,'differential'); a:=OrePoly(1,f(t)); b:=OrePoly(0,f(t)*g(t)); ab:=Multiply(a,b,S); GCD(ab,b,S); from OreTools language to the Ore_algebra one with(Ore_algebra): S:=diff_algebra([x,t],func=[f,g]); a:=f(t)*x+1; b:=f(t)*g(t)*x; ab:=skew_product(a,b,S); skew_gcdex(ab,b,x,S); I ended up with Error, (in Ore_algebra:-skew_gcdex) invalid input: Ore_algebra:-skew_gcdex expects its 1st argument, P, to be of type polynom, but received (f(t)*g(t)+f(t)*diff(f(t),t)*g(t)+f(t)^2*diff(g(t),t))*x+f(t)^2*g(t)*x^2 I guess that the cause here is again the same - Ore_algebra requires integer coefficients (IMHO this limitation is too severe) while mine are functions of time. Or can I modify the code somehow so that I receive the same result as with OreTools? Besides, reading Ore_algebra's help pages, I have come across another unpleasant limitation, namely that the following declaration is forbidden: skew_algebra(diff=[Dx,x],shift=[Sx,x]); Error, (in Ore_algebra:-skew_algebra) indeterminate x may appear in a single commutation only Actually, I would need exactly something like that as I need to work with Ore polynomials in two variables (e.g. x,y), one shift and the other differential, whose coefficients are various functions of time (t), so I would need something like skew_algebra(diff=[x,t],shift=[y,t],func=[f,g,h,sin,cos,...etc.]); Or can I do it in some other way? This Ore_algebra is by far not as user-friendly as OreTools. I was also thinking about the possibility to extend the OreTools package, tried to trace/debug its code but without much success. As a Maple expert, do you think it might be possible to modify the existing OreTools so that they were able to handle two-variate polynomials? Well, that's it for today. Although I could have much more questions related to this Ore-topic, for the time being I hope you (or someone else) will find some time to respond to these...

Hello JacquesC! Thank you very much. Now the skew-multiplication is OK. Unfortunately, the same trick does not work when calculating the GCD of Ore polynomials. For example, when I tried to translate with(OreTools): S:=SetOreRing(t,'differential'); a:=OrePoly(1,f(t)); b:=OrePoly(0,f(t)*g(t)); ab:=Multiply(a,b,S); GCD(ab,b,S); from OreTools language to the Ore_algebra one with(Ore_algebra): S:=diff_algebra([x,t],func=[f,g]); a:=f(t)*x+1; b:=f(t)*g(t)*x; ab:=skew_product(a,b,S); skew_gcdex(ab,b,x,S); I ended up with Error, (in Ore_algebra:-skew_gcdex) invalid input: Ore_algebra:-skew_gcdex expects its 1st argument, P, to be of type polynom, but received (f(t)*g(t)+f(t)*diff(f(t),t)*g(t)+f(t)^2*diff(g(t),t))*x+f(t)^2*g(t)*x^2 I guess that the cause here is again the same - Ore_algebra requires integer coefficients (IMHO this limitation is too severe) while mine are functions of time. Or can I modify the code somehow so that I receive the same result as with OreTools? Besides, reading Ore_algebra's help pages, I have come across another unpleasant limitation, namely that the following declaration is forbidden: skew_algebra(diff=[Dx,x],shift=[Sx,x]); Error, (in Ore_algebra:-skew_algebra) indeterminate x may appear in a single commutation only Actually, I would need exactly something like that as I need to work with Ore polynomials in two variables (e.g. x,y), one shift and the other differential, whose coefficients are various functions of time (t), so I would need something like skew_algebra(diff=[x,t],shift=[y,t],func=[f,g,h,sin,cos,...etc.]); Or can I do it in some other way? This Ore_algebra is by far not as user-friendly as OreTools. I was also thinking about the possibility to extend the OreTools package, tried to trace/debug its code but without much success. As a Maple expert, do you think it might be possible to modify the existing OreTools so that they were able to handle two-variate polynomials? Well, that's it for today. Although I could have much more questions related to this Ore-topic, for the time being I hope you (or someone else) will find some time to respond to these...

Yesterday I hoped that the patch above fixed everything related to subs... Unfortunately, today I've found out that subs still fails if the 1st argument is a symbolic matrix represented as char: using Matlab + MTM 10: >> subs('[cos(a) sin(b); sin(a) cos(b)]',{'a','b'},{'c','d'}) ??? Error using ==> subs Error, incorrect syntax in parse: missing operator or `;` (12) using Matlab only (i.e. SMT): >> subs('[cos(a) sin(b); sin(a) cos(b)]',{'a','b'},{'c','d'}) ans = [ cos(c), sin(d)] [ sin(c), cos(d)] In order to remedy this somehow I tried to compare the @sym/subs.m files of the MTM and SMT. However, I've found out that the SMT's @sym/subs.m code is a bit longer than I expected and right now I don't have enough time to go through it thoroughly... besides, as before, I prefer an official patch (actually, in this case I'm not even sure which file should be fixed - subs.m or sym.m ?).

Thank you for the patch! Works as expected. Still, I think that to put the thing right completely, it is necessary to patch the subs.m in the $MATLAB/toolbox/maple/@sym directory as well, otherwise the substitution doesn't work when the 1st argument is of the sym type. Consider the following code (using Matlab + MTM10): >> var_str='cos(a)+sin(b)' var_str = cos(a)+sin(b) >> var_sym=sym(var_str) var_sym = cos(a) + sin(b) >> subs(var_str,{'a','b'},{'x(1)','x(2)'}) ans = cos(x(1)) + sin(x(2)) >> subs(var_sym,{'a','b'},{'x(1)','x(2)'}) ans = cos(a) + sin(b) However, the last command using SMT: >> subs(var_sym,{'a','b'},{'x(1)','x(2)'}) ans = cos(x(1))+sin(x(2)) I tried a bit of playing with the code (put some breakpoints, etc.) and found out that when the 1st argument of subs is of the sym type already, the $MATLAB/toolbox/maple/@sym/subs.m is called so I did the same trick with this file (i.e. copied the code you added to the $MATLAB/toolbox/maple/subs.m). Now it seems that everything's OK - however I would like to have this modification approved - could you please post an official patch for @sym/subs.m ? (not necessarily the one I describe here)

Another example of a command which gives different results when run in Matlab+MTM10 and solo-Matlab, respectively. In Matlab (using Symbolic Math Toolbox): >> subs('cos(a)+sin(b)',{'a','b'},{'alpha',2}) ans = cos(alpha)+sin(2) In Matlab + Maple Toolbox 10: >> subs('cos(a)+sin(b)',{'a','b'},{'alpha',2}) ans = cos(a) + sin(b) I'm not sure if it is a bug or if the different behaviour is intentional(?) I also tried to execute "maple compaton" before the subs command, but it didn't help (I got the same result) Btw. Does the "maple compaton" option include all the partial options i.e. "maple findsymon", "maple string", etc. or are these options independent one of the other?

Thank you for the patch. Works as expected. It's a pity, though, that there's no way to switch from MTM to SMT and back during a single session. Well - nothing can be perfect... Of course, I will continue to bother you with new MTM/SMT "puzzles" :-) Right now I've come across a thing connected with Matlab's "subs" command - see the example below (I've created a separate thread).