I'm sorry to say it but the sym.m patch for MTM-10 doesn't work as it should :-( Although it works fine for the example above, it fails if the symbolic expression represented as char contains fucntions like sin, cos, sqrt, exp etc. For instance: >> var_str = '[sqrt(x1); sin(x2)+cos(x3)/exp(x4)]' % symbolic matrix represented as char var_str = [sqrt(x1); sin(x2)+cos(x3)/exp(x4)] >> var_sym = sym(var_str) % now I want to convert it to a symbolic object ??? Error using ==> sym.sym Error using ==> sym.sym `;` unexpected fails because the sym.m code in an effort to extract the symbolic variables (symbols) 'x1', 'x2', 'x3', 'x4' from the expression also extracts 'sqrt', 'qrt', 'rt', 't', 'sin', 'in', 'n', etc. and tries to treat them as symbols in syms(symbols{:}) , which of course yields an error. On the other hand, Matlab's SMT is able to cope with it as expected: >> var_str = '[sqrt(x1); sin(x2)+cos(x3)/exp(x4)]' % symbolic matrix represented as char var_str = [sqrt(x1); sin(x2)+cos(x3)/exp(x4)] >> var_sym = sym(var_str) % now I want to convert it to a symbolic object var_sym = sqrt(x1) sin(x2)+cos(x3)/exp(x4) >> class(var_sym) % and it indeed is a symbolic object now ans = sym Is there a way to fix the bug in the patch? Anyway, the main trouble is that all these are only individual cases - patch one and sooner or later another one will arise. I believe that the best thing to do would be to implement into MTM an universal rule saying that "if a Maple-Matlab command produces an error, let the command be evaluated by the Symbolic Math Toolbox (and print a warning if you like) first and only if that fails as well, interrupt the execution of the programme". Finally, an important question from my point of view - is there a possibility to switch between the MTM-10 and SMT during the execution of a programme? This one thing could save me a lot of trouble...

Btw. Here is another discrepancy between SMT and MTM-10 I've come across. The SMT gives: >> syms a b >> findsym(a+b) ans = a, b >> class(findsym(a+b)) ans = char However, with MTM-10 one gets: >> syms a b >> findsym(a+b) ans = [a, b] >> class(findsym(a+b)) ans = sym I'm not saying that the MTM approach is worse - but still it prevents your m-files that work correctly with SMT from proper operation with MTM.

Thank you for the file. An upgrade to MTM-11 is not a real possibility for me, though - at least not at this moment (it took me a lot of time and effort to persuade my university that Maple 10 and MTM-10 are worth purchasing, so I don't think they'll be willing to pay for the upgrade almost immediately afterwards). Anyway I believe that it's natural to expect that even MTM-10 should work as is declared in its documentation, isn't it? So I think I'll better try playing with the code of the sym.m file myself. If that doesn't help - well, then I'll have to modify hundreds of code lines in my old m-files - or more likely, I'll simply come back to using MATLAB's Symbolic Math Toolbox...

Thank you all for your replies! There are indeed more inconsistencies that I've come across while trying to use my old m-files with the Maple Toolbox for MATLAB. I think I'll write them all down one day so that we can discuss them... By the way, the sym.m patch-file above seems to have zero length...(?) Besides, the patch should work with Maple Toolbox for MATLAB 11, but I have MTM-10. Will there be some patch for version 10 as well? EskiMO P.S. Maybe some explanation for you to understand my position better - I'm myself actually not an experienced Maple user (I started using Maple about a year ago) but I'm a long-term MATLAB user. That's why I view things from MATLAB and not from Maple perspective. I've been using Symbolic Math Toolbox intensively and it has worked fairly well for everything I needed. However, recently I needed to use some (rather exotic) algebraic features, which are not available through SMT. I was advised that Maple Toolbox for MATLAB might be the right solution... well, so far it isn't, at least not exactly - although now I can use the features I needed, my old code doesn't work...