ecterrab

13633 Reputation

24 Badges

18 years, 323 days

MaplePrimes Activity


These are answers submitted by ecterrab

Hi nm

There are two different ideas behind what you see in Maple and in Mathematica. Generally speaking (and there are exceptions here and there), in Maple there is an intentional emphasis in giving you control as much as possible over every step of a computation, while not going 'static'. Among two good examples of that, 1) in Maple you then have inert representations for mostly everything, you can compute with integrals, derivatives, or functions without ever computing the integrals, derivatives of the functions themselves, just taking into account their properties; 2) in Maple, products of powers of the same base - say a^n * a^m - are not automatically combined. In some sense this is equivalent to requesting from you to sometimes guide the system more specifically in this or that direction. On the other hand, in Mathematica, preference is given to perform these computations automatically, assuming that you are not interested in controlling any of these steps.

So, for example, if in Mathematica you enter Exp[x/2]*Exp[-3/2*x] the exponentials are automatically combined. while if you try the same in Maple, exp(x/2)*exp(-3/2*x), these two factors are not combined. But then if you add exp(x/2), in Maple you can factor this sum easily, as in 

> factor(exp(x/2) + exp(x/2)*exp(-3/2*x)));

exp(x/2)*(exp(-3/2*x)+1)

while in Mathematica you get the less convenient result

In[1]:= Factor[Exp[x/2] + Exp[-3*x/2]*Exp[x/2]]

Out[1]= E^-x (1 + E^(x/2)) (1 - E^(x/2) + E^x)

So sometimes it is convenient to combine products of powers of the same base, sometimes not.

The corollary: yes these systems are different in a number of things, there are advantages and disadvantages in both approaches, and depending on the example one approach is more convenient than the other one. Taking that into account, in each system the commands you need to enter to obtain a result are not the same. I cannot claim neutrality as I work for Maplesoft but, anyway, in my opinion I really like the control maple offers over the computations, and I also like options to switch gears and compute in a more automatic mode. In the context of the Physics package, for instance, one new option (so far experimental) lets you 'automatically combine powers of the same base', another will optionally let you compute derivatives with respect to complex variables using Wirtinger operators instead of the standard classical complex analysis, and etc.

Edgardo S. Cheb-Terrab
Physics, Maplesoft


It is implemented in the version of Maple under development. It will be in place in the upcomming DifferentialEquation updates page (a new page equivalent to the one we have for Physics here).

 

So, for example, this is an ODE system in Vector notation

ode := Vector([diff(x(t), t), diff(y(t), t)]) = Vector([2*x(t)+y(t), 3*y(t)-x(t)])

Vector[column](%id = 18446744078727259310) = Vector[column](%id = 18446744078727259430)

(1)

New: dsolve handles the Vector equation; this fixes the oversight mentioned

dsolve(ode)

{x(t) = exp((5/2)*t)*(_C1*sin((1/2)*3^(1/2)*t)+_C2*cos((1/2)*3^(1/2)*t)), y(t) = -(1/2)*exp((5/2)*t)*(_C2*sin((1/2)*3^(1/2)*t)*3^(1/2)-_C1*cos((1/2)*3^(1/2)*t)*3^(1/2)-_C1*sin((1/2)*3^(1/2)*t)-_C2*cos((1/2)*3^(1/2)*t))}

(2)

New: if the DE system is in vector notation, so is it the output of odetest

odetest({x(t) = exp(5/2*t)*(_C1*sin(1/2*3^(1/2)*t)+_C2*cos(1/2*3^(1/2)*t)), y(t) = -1/2*exp(5/2*t)*(_C2*sin(1/2*3^(1/2)*t)*3^(1/2)-_C1*cos(1/2*3^(1/2)*t)*3^(1/2)-_C1*sin(1/2*3^(1/2)*t)-_C2*cos(1/2*3^(1/2)*t))}, ?)

Vector[column](%id = 18446744078727252678)

(3)

New: the variables can also be specified in Vector notation, in which case dsolve's output will also be in Vector notation

V := Vector([x(t), y(t)])

Vector[column](%id = 18446744078727253638)

(4)

sol := dsolve(ode, V)

Vector[column](%id = 18446744078727253638) = Vector[column](%id = 18446744078727246782)

(5)

New: odetest can test this kind of Vector solution and returns in the same notation

odetest(sol, ode)

Vector[column](%id = 18446744078727244486)

(6)

All the same is implemented for pdsolve and pdetest too. Opinions?

Please recall that the above does not work in your copy of 17.02. These changes will be available for download when we install the Maplesoft DifferentialEquation updates page equivalent to the Maplesoft Physics R&D updates page.

Download DESystemInVectorNota.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@nm @Markiyan Hirnyk 

Since Maple 17, dsolve and pdsolve accept a system of equations of type 'Matrix', 'Vector', or more generally 'rtable'. It is an oversight that it doesn't work with equations where both sides have the same dimensions. Likely, both dsolve and pdsolve could accept a Vector as second argument indicating the solving variables. I'll adjust the code.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Kevin

Use Array instead of Vector, as in X[~nu] = Array([x0, x1, x2, x3]), and that resolves the problem. The use of Array is explained in the help page ?Physics[Define]. By the way a similar question was posted and answered two week ago here. An example of this kind will be added to the help page.

If you update your Physics package with the current version distributed in the Maplesoft webpage "Maple Physics: Research & Development", you can also use a list, as in X[~nu] = [x0, x1, x2, x3]. Your use of 'Vector' for this purpose is anyway natural, to be allowed in the next Physics update (next week). Regarding the Physics update itself, the zip contains a worksheet illustrating the novelties.

Independent of the different ways of defining a 4-Vector, note that defining a coordinate system automatically defines a related 4-Vector as the one you are trying to define manually. So entering Coordinates(X), or Setup(coordinates = X) also work for your purpose - see ?Physics[Coordinates] for some predefined options you have for the components.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

 

Hi

I'm not sure I understand your question. What you do mean by eliminating the derivatives of of these lambdas or the last sentence that starts with result?

What I see: if you try PDEtools:-casesplit([a,b,c]) you resolve the system: one differential equation involving only lambda3, plus two non-differential equations expression each of lambda2 and lambda1 as functions of lambda3 and its derivatives. And that is all the elimination that is possible for the system [a,b,c]. If you call your result of 'd', then the only solution of the system [a,b,c,d] is the three lambdas equal to 0; for that try PDEtools:-casesplit([a,b,c,d]).

So you cannot eliminate the three derivatives of lambda, only two of them in favor of a third one, and if you add the equation you called 'result' the system [a,b,c] turns into unsolvable (i.e.: a linear system where the only solution is the trivial one, all the unknowns equal to zero).

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Kuka 

Due to a bug in a Typesetting routine when using 2D math input, you are unable to enter contravariant indices by prefixing them with ~ also in Maple 17.02 (note there has been an update, you are still working with Maple 17.00), as you show. One solution is then to change that 2D math input line into 1D math input (press F5).

A more complete solution is for you to update the Physics library from the Maplesoft "Maple Physics: Research & Development" webpage. This update includes a fix to the Typesetting issue you are mentioning, as well as new functionality, and various tweaks and adjustments. By the way: for 4-Vectors, you can now also use just a list instead of an Array, Matrix or procedure. Also relevant for tensor manipulations see the new Library:-SubstituteTensor command, explained in the PhysicsUpdates.mw worksheet distributed together with the updated Physics library

After updating your Physics.mla, you can get the covariant and contravariant components as mentioned in the help page also when you input in 2D.

Note that Physics is updated on this Maplesoft R & D page rather frequently taking into account feedback posted here in Mapleprimes. So if you find something not working properly, or there is functionality that you need and is not there, by posting here there are good chances that the problem is resolved the same week (please tag your post as 'physics' so that I see it right away).

Edgardo S. Cheb-Terrab
Physics, Maplesoft 

Hi,
Assuming your question is: "Given the components of Aijmn and Cijkl, compute the components of Bmnkl that satisfy AijmnBmnkl=Cijkl", an alternative to Torre's suggestion of using DifferentialGeometry, so using Physics and standard tensor indicial notation instead, is as follows:

1) Define the tensors Aijmn and Cijkl(see 4th paragraph of ?Physics,Define to define A and C specifying their components as Arrays).

2) Construct your tensor equation the same way you posted, as in eq := AijmnBmnkl=Cijkl and transform this equation into a system of equations for the components of Bmnkl using Physics:-Library:-TensorComponents(eq), see ?Physics,Library, section for TensorComponents. Call this system of equations sys. The solving variables are the components of B, so vars := Library:-TensorComponents(Bmnkl).

3) Solve the system the usual way, sol_B := solve(sys, vars)

That is all. The advantage of this approach is that it involves algebraic manipulations using the standard Maple commands and tensorial indicial notation so requiring no additional knowledge. If you have any trouble reproducing these steps please post the example concretely - for that purpose you can upload a worksheet with your reply here in Mapleprimes, and we continue from there.

 

Edgardo S. Cheb-Terrab
Physics, Maplesoft

 PS: where you wrote Aijmn to represent the covariant components, in Maple you enter A[i,j,m,n]. Contravariant indices are prefixed by ~, say ~j instead of j.

 

 

Hola Sergio,

 

PDEtools:-declare(f(x, y))

f(x, y)*`will now be displayed as`*f

(1)

diff(f(x, y), x, y) = f(x, y)

diff(diff(f(x, y), x), y) = f(x, y)

(2)

Mark with the mouse, copy and paste:

diff(f(x, y), y, x) = f(x, y)

 

Now, what you want is the old behavior, where you copy and paste "as displayed", i.e. with jet notation. The following is part of developments for the next release but already works in Maple 17.02:

PDEtools:-declare(copyasdisplayed = true)

`Displayed derivatives and declared functions will be copied and pasted

(3)

Try now

diff(f(x, y), x, y) = f(x, y)

diff(diff(f(x, y), x), y) = f(x, y)

(4)

Mark this new output, copy and paste:

f[x, y] = f

Note that if you copy the output of (2) it will continue pasting 'as entered', while the output (4) pasts 'as displayed'.

 

You can switch within a session as much as you want:

PDEtools:-declare(copyasdisplayed = false)

`Displayed derivatives and declared functions will be copied and pasted

(5)

diff(f(x, y), x, y) = f(x, y)

diff(diff(f(x, y), x), y) = f(x, y)

(6)

Mark (6), copy and paste

diff(f(x, y), y, x) = f(x, y)

 

Independent of that, you can always use PDEtools:-ToJet and PDEtools:-FromJet, optionally using different kinds of jet notation, then mark, copy and paste, and the pasted object is always 'as displayed'.

Download DeclareCopyAndPast.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

PS: for some reason some of the output of the uploaded mw appear with "?". In the attached mw things are displayed correctly.

Hi

The simplification of hypergeometric functions is a complicated problem, although computer algebra systems nowadays have powerful algorithms to reduce to a special case involving more famlilar functions *when that is possible*. Of course it is not always possible. Calling your hypergeometric function of pFq, the convert(pFq, StandardFunctions) mentioned by Carl is one way of trying a simpler expression.

There is something more general though: FunctionAdvisor(specialize, pFq). That will give you not only what convert/StandardFunctions can give you but also the different specializations for the parameters within pFq (for instance, your t ) such that the pFq could be rewritten in terms of other functions of all available kinds.

With your example, that is pFq = hypergeom([1/t, 1/t], [(t+1)/t], z), for specialized values of t (these specializations may or not be what you need) I see various equivalent mathematical representations of pFq involving one or many of ChebyshevT, ChebyshevU, GAMMA, HeunC, HeunG, HeunGPrime, JacobiP, LerchPhi, MeijerG, Psi, arccos, arccosh, arccsc, arccsch, arcsec, arcsech, arcsin, arcsinh, arctan, ln, sin.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 

Note first that conjugate does not split into Re and Im. It is simplify that, under certain circumstances, splits into Re and Im; and I am saying that your example in this thread shows a case where the splitting is mostly undesired, not really a simplification.

But there are other cases where this splitting into Re and Im by simplify are, generally speaking, understood as a simplification: when occurrences of z and conjugate(z) in an expression can be combined into 1)  only Re(z) in the expression, or 2) only Im(z), or 3) only Re(z)*Im(z) plus reducing the degree of occurrences of conjugate(z). The cases 1) and 2) are more or less natural simplifications. Case 3) is trickier, here is an example:

> conjugate(z)^2 - z^2;

> simplify(%, conjugate);
                                  -4 I Re(z) Im(z)

This output looks to me simpler than the input conjugate(z)^2 - z^2. On top of these considerations, Maple always performed this "simplification" above, regardless of whether some people may prefer to see conjugate(z)^2 - z^2. In a situation like this, changing previous behavior is inconvenient, makes things that worked in previous releases to stop working in the next one.

On the other hand, as said, some 'simpilfications' are really not simplifications - at all - for basically any reasonable person. In situations like these it is of course OK to change the behavior, it becomes an improvement. Your example is in this class, and also I rewrote simplify/conjugate recently. I'm still busy with other stuff but will see soon how the rewritten simplify/conjugate can be tweaked a bit more to do a better job with examples like yours, while keeping previous desired behavior (items 1), 2) and 3) above) working.

Edgardo S. Cheb-Terrab
Physics, Maplesoft


Hi Lpearce

The relevant page to look at is ? Physics,Define , starting with the fourth paragraph. Accordingly, to define a tensor including its components you can use an Array. Suppose you want to define the contravariant components as [p, 0, 0, p]

with(Physics):

Define(P1[`~mu`] = Array([p, 0, 0, p]))

`Defined objects with tensor properties`

 

{Physics:-Dgamma[mu], P1[`~mu`], Physics:-Psigma[mu], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-KroneckerDelta[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu]}

(1)

If you prefer to define the covariant components with these values, use mu instead of ~mu in the definition. After that you can see the components in two ways: using TensorArray , or giving numerical values to the index, as in

TensorArray(P1[`~mu`])

Array(%id = 18446744078226538494)

(2)

Or for the covariant components:

TensorArray(P1[mu])

Array(%id = 18446744078226540054)

(3)

You retrieve its components when the index has numerical values, for instance this is the covariant P1[1]

P1[1]

-p

(4)

You can compute with P1 as a tensor with symbolic indices, as in

P1[mu] <> P1[`~mu`]

P1[mu] <> P1[`~mu`]

(5)

This is the contraction

P1[mu]^2

P1[mu]*P1[`~mu`]

(6)

You can perform the summation over the repeated indices using SumOverRepeatedIndices

SumOverRepeatedIndices(P1[mu]*P1[`~mu`])

0

(7)

Related to your question, note also that neither simplify nor Physics:-Simplify will automatically perform this summation over repeated indices, which depending on the case (not the one you are presenting) may result in an undesired enlargment of the algebraic expression instead of a simplification.


Download 4Vectors.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@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

First 48 49 50 51 52 53 54 Page 50 of 56