Hi

I'm in the midst of some changes in the way D_ and d_ work, that will probably take care of this issue (your 'D') as well - hopefully returning with a solutoin to this thread tomorrow or after tomorrow.

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

These two commands, FindFormula in Mathematica and identify in Maple have some similarities: both receive numbers, and return algebraic exact expressions that, when evaluated numerically, result in the given numbers. These two commands, however, are different in relevant ways.

FindFormula receives a collection of numbers, typically the points of a plot, think a curve from A to B, and returns an algebraic expression that may contain floating point numbers and that when plotted reproduces that curve from A to B. To some point you can indicate the functions you would like to see in the algebraic expression.

In my opinion, this functionality of FindFormula is not more useful than the one for the same purpose found in the Maple CurveFitting package, in that both provide an algebraic expression that matches a given curve. The fact that FindFormula can include 'functions' in the expression, as opposed to the rational expressions used by CurveFitting doesn't make the result more useful, and generally speaking I tend to prefer a rational expression because it has more mathematical properties than non-polynomial / non-rational expressions.

The identify Maple command, on the other hand, aims at something different, that you cannot do with any interpolation or curve fitting command: it receives a single floating point number and returns an exact algebraic expression in terms of algebraic constants that when evaluated numerically matches the given number. For example, identify(2.596684952) returns 3+Pi-2*sqrt(Pi). For me this is really impressive, and useful in various contexts, as opposed to the curve-fitting functionality, present in both Mathematica and Maple, but of use in more specific contexts.

I know, I work for Maplesoft, and then there may be no way I could be entirely neutral, but I am doing my best in that direction, and still don't see the greatness of FindFormula in a context where there exists CurveFitting packages with so much functionality / features and doing actually more (but for the use of rational expressions that actually I tend to prefer as I said above).

So perhaps I am missing something here, but still don't see the big deal in Mathematica 10.3.0 regarding mathematical functions, but for the introduction of MathematicalFunctionData that is equivalent to the Maple FunctionAdvisor (introduced 12 years earlier) only regarding querying databases, but misses the whole set of algorithms that the FunctionAdvisor has for computing results that can never be found in any database (I mean: because there are infinitely many of them).

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

Yes, MathematicalFunctionData, introduced in Mathematica today, is a replica of the FunctionAdvisor introduced in Maple 12 years ago. More important: MathematicalFunctionData works querying a database while the FunctionAdvisor works taking advantage of some very advanced algorithms, not just querying a database.

Maple, for instance, has a full featured conversion network for mathematical expressions, which is independent of, and in addition, to the FunctionAdvisor, and for which Mathematica still has nothing equivalent. Hence, for instance, you can input FunctionAdvisor(specialize, erfc) (or any other function in place of erfc), or even give specific values to the functions's arguments, say as in 'erfc(1, z)', or even erfc(n, z) with assumptions on the function's arguments placed using assuming, and get results just not present in any database, including the conditions on the function's arguments such that the relationship holds.

Likewise, MathematicalFunctionData and the FunctionAdvisor can tell you about the branch cuts of mathematical functions, BUT the FunctionAdvisor can also tell you about the branch cuts of arbitrary algebraic expressions, because it uses algorithms, some of which are still unpublished research. Here again MathematicalFunctionData, or for the case any other Mathematica command, cannot do that type of computation, because it works by querying a database only.

Another item that springs to my mind is symbolic differentiation: both MathematicalFunctionData and the FunctionAdvisor can tell you about the symbolic derivative of a specific mathematical function. But then in Maple you can directly call the differentiation command diff and compute symbolic derivatives of arbitrary algebraic expressions. That is very-very unique and, again, it is based on algorithms, not just a database. Neither MathematicalFunctionData nor any other Mathematica command can do that.

Finally, while MathematicalFunctionData and the FunctionAdvisor can tell you about the differential equation behind a specific mathematical function, Maple has the PDEtools:-dpolyform command that can write the system of partial differential equations behind an arbitrary mathematical expression involving mathematical functions, possibly nested and combined with any kind of algebraic operation, including fractional and symbolic powers. The FunctionAdvisor takes advantage of that, and here again nothing like that exists in Mathematica. In fact this functionality is not possible without DifferentialAlgebra another thing implemented in Maple in 1996, almost 20 years ago, and still not present in Mathematica.

Regarding FindFormula, it is true, we do not have something like this - fitting a curve against preferred functions, but then Maple has a whole CurveFitting package , that fits curves to rational expressions in a featured way, and also the identify command, which has similarities to FindFormula in that it fits a number to an algebraic expression (ADDED AFTERWARDS: another comment below explains the similarities and differences between FindFormula and identify).

About the residue command: that is not related to the new Mathematica and falls in the class of "a command that exists in the two systems since a long time" - you may want to track the lack of a result (what you posted) as a bug, but I don't see that related to the core of this thread, that is, the new functionality for mathematical functions in the last version of Mathematica.

In summary I do think that MathematicalFunctionData and FindFormula are good steps ahead but in my opinion, taking all together into acount, Mathematica is still concretely behind Maple regarding functionality for mathematical expressions that depend on the properties of the mathematical functions (the paragraphs above).

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

@vv 

The updated library is used by the whole system. It contains in fact all the changes and fixed in the Physics, DE and Mathematical functions that are present in the version of Maple under development.

After you install it, you will obtain the LambertW solution because this update consisted of that, ie: a tweak in the computational flow such that instead of returning a solution as soon as it is found, the code now searches for alternative solutions when it detects that the solution found so far involves a RootOf with an argument nonpolynomial in _Z.

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

I just gave a look at the computational flow and changed it a tiny bit so that in situations like this one the code now prefers to try alteranatives instead of returning a solution that involves a RootOf with an argument that is non-polynomial in _Z, and in that way, in this example, it finds the more tractable solution in terms of Lambert functions.

The update is available to everyone as usual in the Maplesoft R&D webpage for Differential Equations and Mathematical Functions. So we now have, systematically,

@Rouben Rostamian  

I disagree with your arguments, perhaps with the words you choose, while on the other hand I myself introduced the code in dsolve that attempts to return using sin and cos instead of exp when there are pairs of conjugate roots. With what I disagree is with "sometihing went wrong ...", where nothing actually went wrong, and "Maple 11 did this correctly" while there is nothing incorrectly done - at all - in returning exponentials, which in fact are preferred in some contexts (frequently in Physics when working in field theory for instance).

Anyway the reason dsolve was not already returning with sin and cos was an unexpected ordering of the roots returned by solve. I adjusted that and the solution is now expressed using sin and cos as designed originally. The link to the updated library is the same one found in my previous answer in this thread.

Just to not pass a wrong impression: disagreeing is one thing, appreciating your participation and feedback is an entirely different thing. I really appreaciated your comments, Rouben, we all grow with feedback, and that is great.

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

I just added a note to my previous answer in this thread with a link to a library for Maple 16 that resolves this issue. That update library actually works fine probably in all Maples (I don't have copies of all of them but it should work fine).

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

@Michael_Watson 

I still don't see the expression you want to convert but for which you say that convert doesn't work. Without that I cannot help you more concretely.

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

@Dmitry Lyakhov 

I see now what you meant, but "Example 2)", that illustrates your point, to me only tells about a weakness in our program: up to degree 4, the factorization is always doable and trivial. When rewriting DifferentialGeometry we used factor, it escaped my mind that it sometimes requires the field extension ... that as said it should not be necessary for polynomials of these degrees. This is one thing (that I call "A"), and in fact is easy to improve, besides the fact that you can also use the hint option to workaround with ease this unnecessary limitation.

Independent of that DifferentialGeometry:-LieAlgebra:-Decompose indeed does what you want (what I call "B"), i.e. you get the maximal dimension of an abelian subalgebra directly from its output.

There is a myriad of things to do but I will see if I can address this unnecessary limitation in DifferentialGeometry:-LieAlgebra:-Decompose more or less soon.

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

... I think I know what is going on, I will be posting a fix today in the Maplesoft R&D Differential Equations webpage.

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

@Dmitry Lyakhov 

Without further details, I don't have something to add: my understanding is that DifferentialGeometry:-LieAlgebras:-Decompose gives you what you are asking, in that it decomposes a given Lie Algebra into a sum of idencomposable Lie algebras, and the number of them is the maximal dimension you are asking; did you give a look at the Examples section of its help page? If yes, could you please post a worksheet with the concrete problem that you think it cannot be tackled with this command?

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

@Carl Love 

in "arctan(y" you have an open parenthesis; in that case you can keep the comma in the denominator, only. When the parenthesis are closed, in my opinion there is no point in keeping the comma in the denominator - I agree with Christopher2222, and even if that were necessary in some obscure case, it would suffice to provide a way - say with an extra key pressed, for instance as in Ctrl + comma, or whatever that would server the same purpose.

Besides, if I were to design this from scratch I'd probably follow the same rules you have in 1D, so that it would be intuitive, as opposed to "you have to learn two dialects" regarding precedence. Then for instance not just a comma but also a "+" would automatically jump out of the denominator if there are no open parenthesis.

Anyway ... 

Edgardo Cheb-Terrab
Physics, DifferentialEquations and MathematicalFunctions, Maplesoft

@Michael_Watson 

This is about something else, the presentation of your worksheets in Mapleprimes. As you can see in this thread, your worksheet overflows to the sides. So, to read a single line, you need to scroll horizontally to the right, then to read the beginning of the next line you scroll to the left and so on. Your worksheet has no text but you see this need to scroll when trying to read the formulas.

So how could you avoid this need to scrool? Open Maple's preferences, go to "Export" and where you read Math linebreaking width, set it to 6.5 (the default is 8, which is what causes the overflow to the sides), then click on "Apply Globally" and you are done: next time you post, everything will appear presented within margins.

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

@Carl Love 

What I implemented is the standard multi-index notation for sums. Your question is now clear in this third iteration, and no, you cannot set different lower limits for each of the symbols entering the multi-index notation in a sum. By the way that is not standard in  multi-index notation, where the lower limits are always determined by the value of the right-hand-side of the multi-index sum. More important, I do not recall ever seeing the need of setting the lower value for each of these symbols entering the left-hand side of a multi-index sum notation, in all my career. Of course that is not a "solid" argument against that though. Do you have a couple of interesting examples that would motivate allowing for someting like that?

If not, for me at this point what we have is fantastic functionality working for this. Multi-index notation for sums together with the novelties for symbolic sequences, nth order symbolic differentiation, and some other stuff I posted recently here in Mapleprimes all these things are adding interesting layers of abstraction to the capabilities of the Maple symbolic algebra engine, allowing for more and more advanced mathematics and mathematical-physics methods to be implemented. Sort of "very good enough" :) I'm really happy with each of these developments.

By the way, correcting something I said in a previous reply in this thread: when you Physics:-Setup(redefinesum = true), the redefined sum already handles well, and since Maple 18, the notation "1 <= a+b = c" even when that automatically evaluates to false outside the context of sum. What requires delay evaluation quotes is Sum, not sum. Sum, as all symbols used to represent inert functions, has nothing assigned to it. On the other hand, the redefined sum has the first and second arguments of type 'uneval', so that the evaluation is controlled, avoiding in this way all those "premature evaluation" problems that pervade our old (the not redefined) sum.

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

@Carl Love 

Carl, in this other post you ask: "I want the inner sum to be done for all pairs of positive integers (j,k) such that j+k = m-1. ".  It works the same way, but for the detail that in Maple 1 <= j+k = m-1 automatically evaluates to false. So the first workaround is to quote that, as in '1 <= j+k = m-1', but still you cannot do it in two steps because in the middle this will again automatically evaluate to false. One way is then 

> value(Sum(Sum(2^m*(D@@k)(f)*(D@@j)(f), ‘1 <= j+k = m-1'), m = 1 .. 5))

The other way is to adjust the code a bit to accomodate this input without having to delay its evaluation - at first sight I'd say this is pretty easy to do. I will give a look.

EDIT I see you also asked about the typesetting. No, I didn't change the GUI. I only adjusted the typesetting rule for sum and with that automatically also the one for Sum (now that the typesetting for inert functions is derived from the rule from the active functions). There is no documentation for this though, as changing the typesetting code is not meant to be done by everybody. I do have an old project, however, of a mapplet allowing one to change the typesetting of everything ... It is not difficult. But I have had no time yet for this.

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