This is an implementation oversight - call it bug if you prefer - Heun functions were introduced in the system after the conversion network got developed. The implementation details are tricky but in short: the setup of the network includes knowledge regarding "from which functions" can a conversion exists. For Bessel functions an update telling, that from HeunB and HeunC that conversion is possible, is missing in Maple12 and before.

To make it more concrete: if that information were in place, the network would have found that through pFq it is possible to convert to BesselI; try this convert(HeunB(alpha,0,0,0,z), compose, hypergeom, BesselI); and you see it working. The problem is fixed in the version of Maple under development

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Conversions to most of these functions are available; it suffices to check whether convert/foo is or not assigned, where foo is any function's name. As you know Maple frequently incorporates new stuff in different areas; it could be different but in practice  the help system is always catching up a bit.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Conversions to most of these functions are available; it suffices to check whether convert/foo is or not assigned, where foo is any function's name. As you know Maple frequently incorporates new stuff in different areas; it could be different but in practice  the help system is always catching up a bit.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi,
I do not have access to the article you mention, but read your summary, the one you posted in your website as http://patrick.toche.free.fr/research/papers/abel2.pdf

Maple has what I believe are the most advanced algorithms for Abel ODE classes of equations. By most advanced I mean both with respect to other computer algebra systems and as found in the literature. By classes I mean not just one Abel ODE but the family generated from it by changing variables using x-> F(x), y(x) -> ((P+Q*y)/(R+S*y))(x);

If compared with a single ODE, the family involves five additional functions and the algorithms can solve the problem for arbitrary values of them. In practice, when these five functions involve mathematical functions, the algorithm be computationally  too expensive and the gcd and zero recognitions computations with math functions are prone to fail.

Bearing that in mind, Abel equation research splits into two different problems:

1) to find an Abel equation which does not belong to a known solvable class - let's call this ODE "a new seed"

2) to develop an algorithmic way to solve the whole Abel class defined around this seed (ie: to determine the values of the functions F, P, Q, R, S so that a given ODE is reduced to the "new seed"

If you have 1), you can claim that have discovered a new solvable seed. If in addition you have 2), you can fairly claim that a new Abel class is now solvable (in both cases you cannot claim that "Abel ODEs were solved").

Now regarding the ODE example you post,in your pdf, y' y - y = f(x), you do not show anything for 2) and also do not show anything for 1). Regarding 1), it is necessary, first of all, to show a verifiable solution (you have not) - that is a solution in explicit or explicit form that either cancels the equation or that can be used to reconstruct the equation using different approaches; then you need to show that this ODE does not belong to one of the already known solvable classes AIL, AIR, or to one of the solvable AIA subclasses, all of them defined in "Cheb-Terrab, E.S., and Roche, A.D. "An Abel ordinary differential equation class generalizing known integrable classes." European Journal of Applied Mathematics. Vol. 14. (2003): 217-229.".  Years have passed since that paper, that actually report results presented in FOCM in the year 2000, and I have not yet found a "new" seed that does not belong to this class, and algorithm (ie: item 2) above) regarding all these solvable classes already exists in Maple.

Note that your ODE is already AIL or AIR for various values of f(x), for instance f(x) = x, 1/x., 1/x^2 ... (not for x^2), .... So here is the simplification I propose you: can you show how you derive a verifiable solution for f(x) = x^2, that is for y' y - y = x^2, using the method you are presenting? if so we have a good starting point regarding 1).

Edgardo S. Cheb-Terrab
Physics, Maplesoft

I recently replied about this topic in a different thread, see http://www.mapleprimes.com/forum/convertrationalvsidentify#comment-17582

Summarizing: dsolve's option "convert_to_exact = ..." now accepts (in the development version) the keyword `identify` in the rhs, and we are considering moving the default used by dsolve in the presence of floats from using convert/rational/exact to using convert/rational.

Edgardo Cheb-Terrab
Physics, Maplesoft

Hi Robert,
Defaults can change and improvements can be made. What dsolve does when floats are around is explained well in ?dsolve,details. Here are some further considerations:

> convert(0.3333333333,rational);

                                 1/3

> convert(0.3333333333,rational,exact);

                             3333333333
                             -----------
                             10000000000

So: shall dsolve use convert/rational/exact? (This is the current default.) Or shall it use convert/rational? I am inclined to change the default to use convert/rational (without the keyword 'exact'). I can see two motivations for that: a float in Maple has its meaning linked to the value of Digits (that is what the interpretation used by convert to rational when not using the keyword 'exact') and the solutions returned by dsolve are basically always simpler, not just in in your example. Opinions?

The second issue is the implementation (already done in the version under development), taking advantage of the existing dsolve's option 'convert_to_exact', allowing it  to assume the value 'identify', in which case `identify` is used to transform the floats into exact numbers. This has the advantage that whenever floats are used to represent exact non-rational quantities (e.g. 3.14 to represent Pi) the solution returned will match the user's intention more accurately. So we now have

> dsolve(de, convert_to_exact = identify);

 y(x) = _C1*(7^(1/2)*x^2-1)^(1/2)+_C2*(7^(1/2)*x^2-1)^(1/2) *ln((7^(1/4)*x+1)/(7^(1/4)*x-1))

Someone may also suggest that this should be the default (so far I do not think so, but opinions are welcome).

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi
The problem noticed has not one origin but two, and both are more subtle than the diff@int input presented. These problems are now fixed in all the sectors and the fix is scheduled to appear in the first Maple patch to be made available. In this moment (at the company) the output is

> diff(int((A(B(q,r))), r = lb..ub), q);

                    ub
                   /
                  |                  /d         \
                  |    D(A)(B(q, r)) |-- B(q, r)| dr
                  |                  \dq        /
                 /
                   lb

> PDEtools:-dchange(r=RootOf(t2-B(q,_Z)), diff(B(q,r),q), t2=B(q,r), [t2],known=all);

                  D[1](B)(q, RootOf(t2 - B(q, _Z)))

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi
The problem noticed has not one origin but two, and both are more subtle than the diff@int input presented. These problems are now fixed in all the sectors and the fix is scheduled to appear in the first Maple patch to be made available. In this moment (at the company) the output is

> diff(int((A(B(q,r))), r = lb..ub), q);

                    ub
                   /
                  |                  /d         \
                  |    D(A)(B(q, r)) |-- B(q, r)| dr
                  |                  \dq        /
                 /
                   lb

> PDEtools:-dchange(r=RootOf(t2-B(q,_Z)), diff(B(q,r),q), t2=B(q,r), [t2],known=all);

                  D[1](B)(q, RootOf(t2 - B(q, _Z)))

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Britzel,
Your input integral has a wrong parenthesis but after fixing it I can reproduce the problem you mention. The Physics package is new in Maple, and not all parts of the system interact with it as expected. In this example, some internal int subroutines replace the unit vectors by some dummies and then the Physics:-Component command complains about that. That is easy to fix but then int does not know how to integrate a Physics:-Component function; that is also easy - just to say that all in all we need two fixes. These two fixes will probably be in place in the next 12.0x release of Maple. If the fix ends posted elsewhere I'll let you know as well.

And yes, you are right, generally speaking, according to the design of the Physics package, what you want to do is expected to be as easy as replacing the Sum by the Int function and correspondingly adapting discrete indices in the worked example for the inertia tensor shown in ?Physics,examples..

Regards

Edgardo S. Cheb-Terrab
Ph.D Theoretical Physics,
Research Fellow, Maplesoft

Hi Britzel,
Your input integral has a wrong parenthesis but after fixing it I can reproduce the problem you mention. The Physics package is new in Maple, and not all parts of the system interact with it as expected. In this example, some internal int subroutines replace the unit vectors by some dummies and then the Physics:-Component command complains about that. That is easy to fix but then int does not know how to integrate a Physics:-Component function; that is also easy - just to say that all in all we need two fixes. These two fixes will probably be in place in the next 12.0x release of Maple. If the fix ends posted elsewhere I'll let you know as well.

And yes, you are right, generally speaking, according to the design of the Physics package, what you want to do is expected to be as easy as replacing the Sum by the Int function and correspondingly adapting discrete indices in the worked example for the inertia tensor shown in ?Physics,examples..

Regards

Edgardo S. Cheb-Terrab
Ph.D Theoretical Physics,
Research Fellow, Maplesoft

Hi,
Incidentally this same problem got reported as a bug by people from the Technion. The bug is in the integration routine for Dirac functions. The bogus int routine got fixed for Maple 12, where the result for this ODE IVP is

 > DE17:=diff(y(t),t$2)+y(t)=Dirac(t-Pi)+Dirac(t-2*Pi)+Dirac(t-3*Pi);
> Y:=dsolve({DE17,y(0)=0,D(y)(0)=0},y(t));

  Y := y = -(Heaviside(t - 3 Pi) - Heaviside(t - 2 Pi) + Heaviside(t - Pi)) sin(t)

> odetest(Y, [DE17, y(0)=0, D(y)(0)=0]);   # note you can test the initial conditions too

                              [0, 0, 0]

Regarding the bug in int, here is the input, related to this ODE IVP posted, that returns wrong in Maple 11:

> ee := cos(x)*(Dirac(x-Pi)+Dirac(x-2*Pi)+Dirac(x-3*Pi));
> int(%, x);  # Maple 12 Beta output

    -Heaviside(x - 3 Pi) + Heaviside(x - 2 Pi) - Heaviside(x - Pi)

> simplify(diff(%, x) - ee);  # this does not return 0 in Maple 11

                                  0

Edgardo S. Cheb-Terrab
Ph.D Theoretical Physics, Maplesoft

Hi Jacques, I did know about trigsubs. One of the key ideas in the design of the FunctionAdvisor was to "provide centralized access to a large amout of mathematical knowledge already found (buried and spread) in the library" - another one was to make that information more complete with time. For trig functions, the main source of info used is indeed trigsubs. Here is the relevant detail: >print(MathematicalFunctions:-FunctionInfo["tan"]["identities"]); proc(F) local z; z := op(F); op(map(u -> if u <> F then F = u fi, trigsubs(F))), F^2 = 'sec'(z)^2 - 1 end BTW the FunctionAdvisor was a very interesting/challenging (unfinished) project. Some detais are in the related paper presented in the Maple summer workshop of 2002 (the paper is linked at http://lie.uwaterloo.ca/publications.html). Edgardo S. Cheb-Terrab Ph.D Theoretical Physics, Research Fellow, Maplesoft

Hi Jacques, I did know about trigsubs. One of the key ideas in the design of the FunctionAdvisor was to "provide centralized access to a large amout of mathematical knowledge already found (buried and spread) in the library" - another one was to make that information more complete with time. For trig functions, the main source of info used is indeed trigsubs. Here is the relevant detail: >print(MathematicalFunctions:-FunctionInfo["tan"]["identities"]); proc(F) local z; z := op(F); op(map(u -> if u <> F then F = u fi, trigsubs(F))), F^2 = 'sec'(z)^2 - 1 end BTW the FunctionAdvisor was a very interesting/challenging (unfinished) project. Some detais are in the related paper presented in the Maple summer workshop of 2002 (the paper is linked at http://lie.uwaterloo.ca/publications.html). Edgardo S. Cheb-Terrab Ph.D Theoretical Physics, Research Fellow, Maplesoft

Hi John, Please see the second paragraph of yesterday's reply, entitled "Re: the notation for tensors in Maple". Recalling, while in the current version of Physics you can only do abstract tensor algebra in flat spacetimes, that is about to change, to include tensor algebra in curved spacetimes and some of the functionality you have in packages like the old "tensor" or GR-Tensor. At that point you will not need to use two packages unless you want to do something much more specialized, for which the core DifferentialGeometry package is expected to be of help. Regarding your comment about distinguishing between space and time, as mentioned in yesterday's email: the ability to perform abstract tensor algebra in 4D and at the same time in the 3D (space part, so splitting the 3D tensors into a time component and a 3D tensor) is expected to be in place soon. Edgardo S. Cheb-Terrab Ph.D Theoretical Physics, Research Fellow, Maplesoft

Hi John, Please see the second paragraph of yesterday's reply, entitled "Re: the notation for tensors in Maple". Recalling, while in the current version of Physics you can only do abstract tensor algebra in flat spacetimes, that is about to change, to include tensor algebra in curved spacetimes and some of the functionality you have in packages like the old "tensor" or GR-Tensor. At that point you will not need to use two packages unless you want to do something much more specialized, for which the core DifferentialGeometry package is expected to be of help. Regarding your comment about distinguishing between space and time, as mentioned in yesterday's email: the ability to perform abstract tensor algebra in 4D and at the same time in the 3D (space part, so splitting the 3D tensors into a time component and a 3D tensor) is expected to be in place soon. Edgardo S. Cheb-Terrab Ph.D Theoretical Physics, Research Fellow, Maplesoft