@Carl Love 

Carl, there is only one definition of integrating factor. "Suppose the equation is of the form ode and has an integrating factor mu: then mu*ode is a total derivative, i.e.: mu ode = d/dx F(y(x), x)". This is also the first sentence you read in the help page ?DEtools[intfactor]

You see you can rewrite mu ode as (mu*f)*(ode/f), and so as soon as you change the form of the equation (now it is ode/f), it also changes the integrating factor (now it is mu*f). That explains the results you see in Maple that you posted above in this thread.

The wikipedia and mathworld articles are weak in that all their examples have the highest derivative isolated (equivalent to multiplying ode by some f such that the coefficient of the highest derivative is equal to 1), which is what seems to have confused you. Note that in the equation posted by "nm" the coefficient of the highest derivative is t^2 - t. 

The fact that you can rewrite the integrating factor of a given ODE in infinitely many manners (I mean: without changing ODE) is easy to understand: suppose you have an expression G(y(x), x) that on the solutions y(x) of your ODE becomes a constant. Then d/dx G(y(x),x) = 0 on the solutions y(x) of ODE. But then if mu ODE is a total derivative, so is mu * G(x, y(x)) * ODE because its d/dx is equal to d/dx G * (mu ODE) + G * d/dx(mu ODE) = 0 + G * d/dx(mu ODE) = 0.

In other words: both mu and mu * G(x, y(x)) are integrating factors of ODE. You know, given y(x) (the solution of ODE) we can write infinitely many functions G(x, y(x)) = constant.

In summary: For any ODE you can write integrating factors in infinitely many diffeerent ways. The output of Maple's intfactor is correct. The integrating factor posted by 'nm' is not correct (it is missing a factor). 

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Andriy

Recall there is a difference between `*` and `.`, the latter is used for the scalar product of Bras and Kets and operators, while you can use `*` to represent the operation without computing it. Note also that phi is commutative and you use it as such when performing the product, but afterwards you replace it by a noncommutative object a Ket. That is not a good strategy: the order of the operands gets swapped in this case, normalizing the product taking advantage that 'phi is commutative'.

In summary: before multiplying, enter Setup(op = phi) or Setup(noncommutativeprefix = phi) to state that phi is not commutative, then perform H . phi as you do in your worksheet, then enter eval(H, [phi = Ket(psi, 1, 0, 1, 1, 0, 0), f = 1, `*` = `.`]) (so as you did, but including now the equation `*` = `.`), in order to introduce a Ket replacing phi and perform the scalar product. That resolves your 1st problem.

Regarding your second question: conjugate is present in your H, and split into Re and Im within simplify/conjugate, because in this example that leads to a partial simplification. Although at first sight I would say that partial simplification is just of no value in this case and complicates the expression. Until that is reviewed, I would suggest you replacing conjugate by something else like Conjugate, then perform the scalar product (that is where simplify/conjugate is called), and at the end remove Conjugate reintroducing conjugate. If I tweak simplify/conjugate before that I will let you know but this week I'm rather busy with other stuff.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi

What is what you are finding strange in intfactor's result? It is correct: try mutest(intfactor(ode), ode) and it returns zero. You can test this result manually too. Regarding the integrating factor you show, simplify(exp(int( (t^2+2*t-2)/(t^2-t),t))), it is not correct. Multiplying the ODE by it you do not get an exact equation. Try testing it with DEtools[mutest].

Independent of that, note that the integrating factor can depend on as many variables as the differential order plus 1 (all the derivatives up to the ODE order minus one, plus the unknown y(x) and the independent variable x) and as such you can write an integrating factor for an ODE in infinitely many different manners. Some of that is explained in ?DEtools[intfactor] and in ?DEtools[redode] that computes the ODE reducible by a given integrating factor; see also PDEtools[DeterminingPDE] to compute the PDE system satisfied by it.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 

To avoid having to sort products many times, use the optional argument 'evaluateexpression'. The 'too many levels of recursion' was happening only when assigning to geometrical coordinates (z is part of the cartesian coordinates). When working with Physics:-Vectors, you cannot assign to these coordinates. It is fixed now: if you do not have Vectors loaded, you can assign any of the geometrical coordinates without problem. I just posted a new update in the Maplesoft webpage "Maple Physics: Research & Development" with only this fix.

From your post it remains: 1) why it is not sorting the second A in ABAC - I will revise this in the next iteration, and 2) why do whe have A . A and A * A.

The answer to 2) is debatable. As you say, A * B looks as good as A . B to represent their product, there is indeed no difference whatsoever in meaning between these two constructions, and we could have implemented everything with a single product operator. I still preferred to distinguish between non commutative generic products and scalar products of Kets or Kets and operators. This distinction is useful at least in two ways: using `*` you can express your quantum computations and then replacing by `.`, as in eval(expression, `*` = `.`), you can execute them, also having A . B, you can insert a Projector (see ?Physics:-Projector) in between and have the operation performed exactly as expected. The inconvenience of using `*` and `.` is that for a computer these two constructions are different, and this 'computer language difference' forces us to take care of it within the code or interactively. I will think if there is a way to diminish the inconvenience to a minimum.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

I gave a look at your worksheet: a DE system for x,y,z, this system is exactly solvable, then you solve for x,y,z another system of three functions f, h, k equal to 0. No text. I is not clear to me what you are asking, nor why are you setting f, h and k equal to zero or what would be the relation between that and the system sys where none of f, h or k are equal to zero. I guess that is why you received no feedback. In order to receive more concrete feedback I suggest you repost explaining your problem more clearly. 

Independent of that, there is in Maple a nice package for plotting Poincare sections of dynamical systems - check ?DEtools[poincare] and to see this at work see ?Poincare,examples.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

In Maple 17, also some releases before that, you can use the Physics:-Vectors package. For examples of its use in Vector Analysis problems like the ones you are mentioning, see for instance the 1st section of the help page ?Physics[examples].

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi

This issue got fixed in the latest update of Physics (Sep/26), available for download as usual in the "Maple Physics: Research & Development" updates page. 

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi

The old 'tensor' package is not maintained anymore and is being deprecated: tensors are now implemented in the Physics package, in a more natural way, including covariant derivatives, see ?Physics[D_]. So my suggestion would be for you to try that - if it doesn't work then could you please post the details, e.g. upload a worksheet with them, so that we can help you more concretely.

Edgardo S. Cheb-Terrab
Physics, Maplesoft 

To solve an equation in terms of  Bessel functions, you can indicate the solving method dsolve(ode, [Bessel]) (see ?dsolve[details]). In most cases that would be equivalent to using Frobenius series then rewriting the series in terms of Bessel functions. You can do that with any of the three equations you show. The one solved in terms of sin and cos you can express that solution in terms of Bessels using convert(solution, Bessel, include = all) (see ?convert[to_special_function]).

Regarding Frobenius series solution, you can formulate such a solution around a regular singularity of the quation (check ?DEtools[singularities]). Given the location of such a singularity, you can use ?DEtools[formal_sol] to see the first terms around that location, or also dsolve with its series option, or when a closed form summation solution can be computed you can directly use ?dsolve[formal_solution] as Preben mentioned, optionally indicating the location of the singularity.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Andriy, Carl

Download unabletoreproduce.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 

Note that cc is not a Maple command but just written to address your particular problem: to get all the coefficients in products. You are now passing something that is not a product, the term '+ap[1]'. Just tune your cc accordingly. Here is a cc that meets this new requirement of your problem:

cc := proc (EE)
local ee, P, U;

ee := UnnestProductsInExpression(EE, ':-productsinoutput = P');
P := {seq(P[j] = U[j], j = 1 .. nops(P))};
ee := subs(P, ee);
coeffs(ee, map(rhs, P) union indets(ee, Library:-PhysicsType:-QuantumOperator))
end:

Note also that Library:-PhysicsType is a package, it has many other types that may be of use for you, for instance ExtendedQuantumOperator.

Regarding your second question: look at the operands of phi (as in: op(phi)) and you will understand why is that you are getting only a + b, and how to solve it; one way of doing that is select(type, phi, commutative).

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Andryi
Regarding the problem you posted and getting all the coefficients in one go, a new update of Physics is being posted today, with it:

Download AllCoefficients.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Carl Love 

Note that in the same page ?assuming[details] you are quoting, after these three items you quote, you also read:

Notes: The assuming command does not place assumptions on integration or summation dummy variables in definite integrals and sums, nor in limit or product dummy variables, because all these variables already have their domain restricted by the integration, summation or product range or by the method used to compute a limit. To obtain the simplification of the expression being summed, integrated or subject to a product taking into account the restriction on the values of the dummy variable implicit in the integration/summation/product range, use the simplify command -- see the Examples section of this help page.

The assuming command does not scan Maple programs regarding the potential presence of assumed variables. To compute taking into account assumptions on variables found in the bodies of programs, use assume -- see the Examples section.

These two paragraphs complete the description. Taking them into account, assuming does work according to its design.

Regarding the question by Sergio, the second paragraph quoted above is the answer. There are various reasons for this design, mainly that if you scan procedures, they typically call other procedures that call other ones etc. and you cannot go scanning all the tree, and "I only scan this many levels" would be of no use in various cases one could imagine, and you have the functionality anyway if you use assume alone or in combination with assuming (with or without its option additionally). There is one example in the Examples section illustrating this aspect of the design explicitly.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

A new Physics:-Library:-Add command is included in today's update of Physics, implementing the ideas discussed in this post, so working around the model of evaluation of arguments of sum that sometimes generates unexpected results as discussed for instance in the Mapleprimes posts of August  annihilation/creation operators , Problem-With-A-Function-Within-Sum, and Sum-In-For-Loop. The next upated by the end of the week will include a `print/Add` to have the expected capital Sigma display an related copy & paste.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 

Edgardo S. Cheb-Terrab
Physics, Maplesoft