@NOh 
I don't know what you are doing but it works for me and without quoting:

Edgardo S. Cheb-Terrab 
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Alejandro Jakubi 

int(f(x),x);

type(%, 'int(function, name)');

                                             true

type(f(1), 'f(integer)')

                                    true

So, no design problem here. On the contrary, this is one of the fantastic things in the maple system: you can test if an object is a certain function with arguments of certain types. That is also what Andriy was testing. Now if you allow int(function,name) to be executed, you receive function*name, making the type test fail, of course. for that reason you quote it, as in 'int(function,name)' when passing it as a second argument to type. By the way this also works with indexed objects:

type(A[j], 'A[symbol]')

                                        true

and here again: if A is a table such that A[symbol] returns a value, for example '2', then you need to quote it when passing it as second argument to type, or otherwise the type test will not work - you would be testing if A[j] is of type '2'.

For details see the help page ?type,structured. Here I only wanted to clarify that  there is no design problem and this is not related to names that collide with procedures or alike. This has to do only with a way to perform type testing in the Maple system, very useful, and described in the help page mentioned.

Edgardo S. Cheb-Terrab 
Physics, Differential Equations and Mathematical Functions, Maplesoft

@w-Teilchen 

It would be great to see your post (I'd suggest to presente it separated, as a new post, instead of as an answer to this post). I'm looking forward.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Alejandro Jakubi 

The computation shown illustrates precisely how to perform the derivative, whether you call the matrix in the middle by A, by B or by Inverse(A) -- in all cases it is just a matrix. By the way, note also the Physics:-Inverse command, useful when working without indices and not actually with matrices.

Regarding working with linear algebra using tensor notation: I find this natural, specially if you want to compute regardless of the dimension, or taking into account symmetries under permutation of indices, etc.

Regarding working with linear algebra also without tensor notation and not with matrices, depending on what you want to do, using noncommutative variables implemented within the Physics package serves the purpose well. The implementation of Dirac's notation within Physics, for "quantum mechanics vector calculus", is an example.

My 2 cents ...

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Age 

Just to confirm that I tried now your examples using a more recent Physics library, that you can download from the R&D Maplesoft Physics page, and the results come all correct (the ones you expected).

Edgardo S. Cheb-Terrab 
Physics, Maplesoft

@NOh 

This seems to be a different question, although I do not see the images, probably a problem in Mapleprimes website. Could you please upload a worksheet instead so that I give this a look? Thanks.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Age 

I'm out of town in this moment, and unable to check things further, but I suggest you to update your Physics library from the R&D Maplesoft Physics page and try your examples again. I will return to this topic in one week.

Best

Edgardo

@w-Teilchen 

Unfortunately, I didn't have time to look at your post yet, I've been coding the tetrad formalism of General Relativity, it is mostly finished. Your post, together with 2 other posts made here in Mapleprimes that, like yours, I couldn't address faster, are first in the list of things I plan to give a look starting Oct/15.

Edgardo S. Cheb-Terrab 
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Alejandro Jakubi , @rlopez

The problem is in the use of alias, as expressed by nm, or otherwise in the use of 2D input mode versus 1D input mode, as indirectly expressed by you two.

If you use alias, Robert, Typesetting:-Supress is of no use and things happen as mentioned by nm in this post. If on the other hand you do not use alias, AND input in 2D mode, things happen as you mentioned, Robert, and diff(g, t) returns not 0; otherwise if you use 1D input mode as I understand you use, Alejandro, then diff(g, t) returns 0 unless you use alias, in which case we are back to square one: things happen as said by nm. Alternatively, PDEtools:-declare is free of all these nuances, working OK with or without alias, and regardless of using 1D or 2D input - I mentioned it for that reason; but then we do not have the dot to indicate derivatives.

This requires a fix in Typesetting, as suggested by nm.

Edgardo S. Cheb-Terrab 
Physics, Differential Equations and Mathematical Functions, Maplesoft

@nm 

Note that, unfortunately, the steps you would like to see automated are however not possible to be automated. When dsolve returns ODESolStruc it is because the computer algebra system as a whole does not know how to solve the reduced ODE. Therefore, one cannot automate 'returning a final solution' as you suggest in your third and fourth paragraphs.

Likewise, odetest can only test the solution you give to it. Any automatic replacement of your solution or of your ODE by something else would be inappropriate. And the option useInt is an option of dsolve, not odetest, so this too cannot be automated. Think more about: you pass a solution and instead of testing it, odetest, automatically, would first compute another solution using dsolve's option useInt, test this other solution, then return 0. Would you accept that result? I wouldn't. It didn't test the solution I passed to it.

All this points to a relevant thing: computer algebra is of enormous value but you should not think of it as a "complete solution". There is no complete solution. There will always be cases that require your human-skilled approach. Whether you have the skillls to do better than the computer is another story, with which I agree with you, few people have those additional skills, but that doesn't change the facts, there will always be situations where you will need to guide the computer.

Yes, more examples in the help pages are always useful. I will see if I can add some of these of this post to the help page of odetest.

Edgardo S. Cheb-Terrab 
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Markiyan Hirnyk 

Hi Markiyan, y=0 is not a general solution, because it has not the necessary number of arbitrary constants. Therefore is not the solution expected from dsolve according to its help page. The fact that dsolve, in addition, returns essential singular solutions doesn't change that fact. By the way y = 0 is also not an essential singular solution of the ode posted, nor a singular solution of any kind, but just a particular solution that can be obtained taking one of the integration constants equal to 0 in the general solution.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Mac Dude 
I am sorry but the update for Maple 18 does not work in previous releases. 

Edgardo S. Cheb-Terrab 
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Markiyan Hirnyk 

Look closer into ?dsolve,details. In the Section entitled "Arbitrary Constants, General, Particular and Singular ODE solutions", you read: "By default, dsolve computes the general and essentially singular solutions of a nonlinear ODE; the latter are the singular solutions that cannot be obtained from the general solution by specializing the integration constants in any way."

In the same section, you read: "A general solution to an ODE depends on as many arbitrary constants as the differential order, say N. Conversely, any solution depending on N arbitrary constants is a general solution. Depending on N constants here means there is no possible redefinition of the _Cn in terms of other N independent constants that results in a form of the solution with fewer than N constants."

I suppose you missed this section when reading the page, but there is no possible misunderstanding: a solution of the form y(x) = 0, without arbitrary constants for a 2nd order ODE does not match these statements quoted from the help page ?dsolve,details.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Markiyan Hirnyk 

You say "The only closed form solution of the nonlinear ODE under consideration it can find is y(x)=0", but if you read the help page (?dsolve or ?dsolve,details) you see that dsolve is expected to always return a general solution , or otherwise return NULL. So this solution y(x) = 0 is not according to what is written in the help page, and so it is wrong even if mathematically a correct particular solution.

The actual problem was in one of the internal routines for computing solutions to nonlinear 2nd order ODEs in terms of elliptic JacobiSN functions, a condition being tested required an additional simplification, it is fixed now, the fix is available as usual in the Maplesoft R&D webpage for Differential Equations and Mathematical Functions.

Besides that, you could see that dsolve can compute a general solution for this equation if you try the Lie symmetries option, as in

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Hi

I'm rather busy in this moment for several weeks ahead;let's see if I can give this one a look carefully and return useful feedback sooner than that.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft