1. Use eval() in your expression ( not quite sure why this is necessary in your case)
2. This will cos the loop to run then fail with an index out of bounds error, which seems to occur because you have assigned M[8,6] to be B13(2,3), when in fact B13 is 3*2.
3. I suggest you always uses square-bracket indexing (although I haven't corrected all of these)

Diff2.mw

@aamirkhan 

Don't send pictures of your code - too much retyping for anyone here to be interested.

Upload your worksheet using the big green up-arrow at teh right hand end of the second row of toolbar icons

You are defining functions for the form f(x(t), y(t), t), yet want to be able to differentiate wrt the function x(t). This falls outside the meaning of partial differentiation (or at least it does for me), and is a somewhat unusual thing to want to do. Are you really, really sure you want to do this?? I can think of the odd application mainly calculus of variations, which might crop up in Lagrangian mechanics etc, but it is an unusual operation

Assuming that you do want to perform this operation, then see the attached which gives two methods, using a "simple" example function. Check carefully that the methods I have listed give the answers you would expect for the example I have used.

funcDiff.mw

I did apply the Physics[Diff] approach to construct your C matrix, and it came out identically zero, which I suspect is not what you want, so either

1. There is a problem with the equations used to construct your C matrix, or
2. You don't actually want to differentiate wrt to functions like x(t), theta(t), etc

I have no way of telling.

@aamirkhan 

@Alejandro Jakubi 

The mere fact that this argument keeps resurfacing is indicative of some kind of fundamental problem. I accept that the solution is well beyond my capabilities.

I had never really considered equivalence checking as a huge issue until the OP's previous post kicked it off. I now appreciate that equivalence checking is far more complicated than I had ever previously considered (for which feel free to call me a dumb a*****e).

However based on my readings and (limited) experience, I still feel the following  statements are valid

1. Equivalence checking is very difficult
2. You observe that "verify is extensible by the user while is is not". No problem, I agree completely. However in a specific instance, how do I know which extension is necessary??? I commented earlier that the verify  extensibility is fine when used "interactively", but difficult to use "programmatically", because the required verify/extension requires my "calibrated eyeball", which does not exist in a program situation.
3. What I have described as the programmatic equivalence problem is certainly the hardest case. One has absolutely no foreknowledge of the form of the expressions to be checked, so one has absolutely no idea which verify/extension to apply. As I stated previously one could envisage a procedure which (crudely) tries a whole lot of possibilities and ors the result, because any true almost certainly outweighs any number of falses and FAILS
4. However, given no foreknowledge of the expressions to be checked (the programmatic case), which is the equivalence checker most likely to give the correct result?? Based on the (admittedly limited) range of experiments I have tried, 'is', *seems* to be the best option. This surprised the hell out of me for the reason given in (5) below
5. If 'is' actually is the best option for such a fundamental operation as equivalence checking, why is it hidden halfway down a help page on the Assume capability and so poorly documented - I keep thinking that it can't be that important and I must be missing something fundamental - or maybe not
6. Whilst looking around for equivalence checkers, I did view the MathematicalFunctions:-Is page. It looks like a partial rewrite of the original Assume page - cos it covers Assume, CouldItBe, and Is, with no indication of how these might differ from the "original" Assume, CouldItBe, and Is so I chose to ignore it for the purposes of the present discussion

I have been playing with 'is', 'verify/expand', verify/simplify, evalb since the OPs first post caused the original discussion.

In no way are my "experiments" definitive -  or even partcularly scientific.

verify/simplify and verify/expand can work across all the cases I have tried - my problem is that they would be difficult to uses programmatically, because without my carefully calibrated eyeball, it is difficult to determine which has the better chance of working. When my eyeball is no longer adequate, because expressions are more than a pageful, then figuring out which verify option to try becomes a matter of experiment. Again, a pain to do programatically. I know I could write a procedure to try various combinations and more-or-less OR the results, but this strikes me as ugly.

"is" works on all the cases I have tried - without any guidance from me. It correctly simplifies trig identities, factos/expand polynomials whatever - so I would certainly recommend it as the first stop in a programmatic situation, and probably elsewhere as well. The latter because I haven't yet come up with a case where 'verify/option' succeeds and 'is' fails

However I am bothered by the fact that 'is' doesn't even have its own manual page. It is stuck halway down the Assume page, with little real reference to its capabilities. If indeed it is the best *default" equivalence checker, then I would have expected it to be getting a little more publicity

@Alejandro Jakubi 

I couldn't make sense of your second worksheet and in case you will not be able to solve numerically unless you can give numerical boundary/initial conditions; so I went back to your original problem statement, did a bit of simplification here and there and imposed some (arbitrary) initial conditions - see attached.

syst1.mw

Unfortunately no matter what initial condition I set Maple claims that the solution si singular/complex whatever at the initial point. At this stage I have nothing to suggest other than to ask that youcheck your original equations very carefully for anything which might prevent a numerical solution: I can't determine any obvious singularities. Do these equation model some "physical" system (in which case such singular behaviour would eb very unexpected) or is it an "abstract" mathematical problem

@patient 

I've no wish to restart the argument from your earlier post, even though I learned a lot from it, but FYI if you change the final command in your worksheet to

verify(C45,C54,simplify)

then it returns false

PS: Please tell me that you didn't actually type all of that input

@Carl Love 

@Rouben Rostamian  

The fact that your postscript file is ~70kB is informative.

Rouben (on Linux) and me on Win7 both get file sizes around 2.8MB - no way a 70kB file is going to contain the required info.

I'm running a commercial Maple 2015 license, and I'm guessing (from his posting history here) that Rouben is also running a seriiously unrestriced Maple 2015 license. This points to the observtion I made earlier that the Maple 2015 Student edition is "crippled" when it come to file export/import. Sorry but I have no way to check this.

Like Rouben says you can only comtact Maple Technical Support who ought to be able to tell you whether your problem is related to the "Student" license  issue

Sorry but I don't think I csan be any more help :-(

Good Luck

PS Why do you *need* eps in the first place - have you even tried JPG or GIF?

@Simon_2604 

I'v just tried yuur worksheet again in Maple2015 on Win7.

The only thing I can read it with is AcrobatPro and it takes ages to load.

Adobe reader doesn't support eps, in fact I've just had a look through all the other programs I have on this machine and I can't find any other which will read eps. The are some eps viewer sites on the web (eg epsviewer.com) so I uploadedd it there and could view it there: again painfully slow.

I think you need to determine whether it is the creation of the file or reading the file that is causing the problem: so

What application are you using to view it?

Have you tried an eps viewer website?

Is the file size you get ~2.8MB?

Are you sure the Student edition of Maple allows creation of files this big??

I too doubt that it is a Win7/Win8 issue - two questions

1. Are you using the right click on plot, export as eps method like Rouben and I, or something programmatic like ImageTools[Export]
2. Do you happen to know if the Maple student edition is "crippled" in any way. I'm far too old to have a student edition for anything, but I understand that one common method to distinguish between student/full versions is to restrict the size/type of files which can be written/read. I'm running a commercial single-user licence and have no way of checking student edition capability:-(

@Simon_2604 

@Alejandro Jakubi 

I have never seen/used the verify command before - it seems to be quite well hidden!

However I have just done a quick dirty recoding of my three groups of five problems listed above. Within each group, verify returns three trues and two FAILS, so it never, ever returns false, when the answer is true. In my opinion this is way better than any other method so far!

I guess I now have to figure out whether I can apply this command to the OP's original problem of determining whether or not a matrix is symmetric. All comparison methods so far have shown false - but the one thing this thread has shown is that when Maple returns false from some boolean comparisons, this is not reliable :-(

PS I may never use a simple if statement again

PPS: Why is the level of equivalence checking used by verify not the default for boolean comparisons???

@Rouben Rostamian  

I exported the plot the same way as Rouben except on a Win7 system. The exported plot looks pretty nice in AcrobatPro, although it is painfully slow to load/render compared with jpg.

Since the export seems to work and is viewable on both Win7 and Linux - what system/viewers are giving you a problem??

PS I note with interest that in Maple2015, eps is not listed as valid output format for ImageTools[Export], exactly how are you exporting the plot?

@patient 

Had no luck trying to come with symbolic solutions. Numeric may be your only choice. To help further would need to know the initial value of x (maybe 0?) together with u(x_init), U(x_init), v(x_init) and V(x_init). Derivatives of these four functios evaluated at x_init might also be useful. Are any of these known???

To avoid the possibility of cut/paste error it would be better if the addditional info could be incorporated in a worksheet together with the original equations  to be uploaded here

@Alejandro Jakubi 

All that the zero equivalence problem (and its relations) really states is that it cen be very, very difficult to determine equality between two expressions. In other words a CAS might be expected to return one of true, false or undecided.

The fact is that in the fifteen cases I listed above, the answer is always true. If Maple had thrown errors and returned 15 undecideds, I could live with it. Just means I have to work harder, reformulate the problem, whatever. However Maple did not admit the existence of the "zero equivalence problem", with associated difficulty of solution, because it always managed to return either true or false and was therefore wrong on 9 out of 15 instances.

I accept that the zero equivalence problem exists - Maple apparently doesn't: it prefers to produce the wrong answer. You may not see that as an issue, but I do.

@Carl Love 

Imagine the scenario - I've just done some lengthy computations and produced ~8 expressions.

Suppose that (like the OP), these expressions are too large/complicated to be meaningfully comprehended by human eyeball, so to mimic this, I'm not going to tell you what the 8 expressions are.

However I do want to test the equality of these expressions in certain combinations.

A few clues

1. In all cases, pencil/paper return true
2. In the first group, Maple returns 2/5 true - which 2
3. In the second group, Maple returns 3/5 true - which 3
4. In the third group, Maple returns 1/5 true - which 1

Group1: Maple returns 2/5 as true

if   t1=t3/t2

if   simplify(t1=t3/t2)

if   expand(t1=t3/t2)

if   simplify(expand(t=t3/t2))

if   expand(simplify(t1=t3/t2))

Group2: Maple returns 3/5 as true

if   t4=t2/t3

if   simplify(t4=t2/t3)

if   expand(t4=t2/t3)

if   simplify(expand(t4=t2/t3))

if   expand(simplify(t4=t2/t3))

Group3: Maple returns 1/5 as true

if   t6*t5=t7

if   simplify(t6*t5=t7)

if   expand(t6*t5=t7)

if   simplify(expand(t6*t5=t7))

if   expand(simplify(t6*t5=t7))

If (as I suspect), one of these combinations *always* works, then why doesn't Maple utilise it by default in such Boolean comparisons?

And if you want to know what the expressions t1..t8 actually are, check out

Quiz2.mw