ecterrab

14702 Reputation

24 Badges

20 years, 274 days

MaplePrimes Activity


These are answers submitted by ecterrab

Good catch. It is fixed within the Physics Updates v.1872. To install, as usual, input Physics:-Version(latest).

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

Adjust sum to not have these premature evaluation problems:

Physics:-Setup(redefinesum = true)

[redefinesum = true]

(1)


Now you have:

sum(modp(5, product(2, t = 0 .. modp(q-1, 3))), q = 1 .. 2)

2

(2)


See the Physics:-Library help page, subsection for Physics:-Library:-Add. The problem of premature evaluation is an old one. It is addressed in the Physics context (package) making sum use the Physics:-Library-Add wrapper, which performs the summation using sum but such that the computation is free of these old premature evalution problems. I copy here the mini-help-page for this command from the help page of Physics:-Library. The command can be used as Physics:-Library:-Add, or directly as the sum command after entering Physics:-Setup(redefinesum = true)

Add

 
  

Calling Sequence

  

Physics:-Library:-Add(f, k = m..n)

  

Parameters

  

f    : algebraic expression

  

k    : name; summation index

  

m, n : integers or arbitrary expressions, indicate the summation range

  

Description

  

Add unifies the standard add  and sum  commands into one that uses a more modern handling of arguments, is free of premature evaluation problems, and implements multi-index summation. The functionality and handling of arguments of Add can be plugged directly into the sum command using the option redefinesum of Physics:-Setup.

  

Examples

restart: with(Physics): with(Library):

  

Consider this multi-index summation.

Add(f[i, j], 1 <= i+j and i+j <= n);

Physics:-Library:-Add(f[i, j], i+j <= n, lowerbound = 1)

(1.1)
  

For instance, for n = 2,

eval((1.1), n = 2);

f[0, 1]+f[1, 0]+f[0, 2]+f[1, 1]+f[2, 0]

(1.2)
  

The formula for the integer power of a sum is:

(a+b+c)^n = Add(factorial(n)*a^p*b^q*c^r/(factorial(p)*factorial(q)*factorial(r)), p+q+r = n);

(a+b+c)^n = Physics:-Library:-Add(Physics:-`*`(factorial(n), Physics:-`^`(a, p), Physics:-`^`(b, q), Physics:-`^`(c, r), Physics:-`^`(Physics:-`*`(factorial(p), factorial(q), factorial(r)), -1)), p+q+r = n)

(1.3)

eval((1.3), n = 3);

(a+b+c)^3 = a^3+3*a^2*b+3*a^2*c+3*a*b^2+6*a*b*c+3*a*c^2+b^3+3*b^2*c+3*b*c^2+c^3

(1.4)
  

A more modern handling of its arguments, consider a typical problem where a name, say j, is assigned a value, and j is used as dummy summation variable

a, b, j := 1, 2, 3;

1, 2, 3

(1.5)
  

The value just assigned, j = 3, is not expected to interfere with the summation

Add(f[j], j = a..b);

f[1]+f[2]

(1.6)
  

while for this example, sum interrupts with an error message due to a premature evaluation of the summation index j. Another frequent case: a procedure that returns a value according to the value of the summation index.

g := k -> if k::odd then G[k] else 0 end if;

proc (k) options operator, arrow; if k::odd then G[k] else 0 end if end proc

(1.7)
  

Without giving a value to the summation limit f, the following summation cannot be performed.

Add(g(k), k = 1 .. f);

Physics:-Library:-Add(g(k), k = 1 .. f)

(1.8)
  

For this example, add interrupts with an error message while sum returns 0, again due to a premature evaluation of g(k) before k has a numerical value. Using a more modern handling of arguments Add returns unevaluated instead, as seen above, which permits evaluating the summation at a later moment, for instance attributing a value to f.

eval((1.8), f = 3);

G[1]+G[3]

(1.9)
  

See Also

  

add , sum , Physics[Setup]

 

Download sum-redefined.mw

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

Hi
Unfortunately, it looks like a problem in the Maplecloud repository, I have no idea what that problem could be. In any case, this is a zip with the latest update for Maple 2022.

Physics_Updates.maple_(last_for_2022).zip

Edgardo S. Cheb-Terrab
Physics, Differential Equations, and Mathematical Functions
Maplesoft Emmeritus
Research and Education—passionate about all that.

Hi
I am not sure I get the whole picture, but here is some feedback. 

with(Physics); Setup(mathematicalnotation = true)


In your image, a and i are Euclidean indices that run from 1 to 3, so you do not need to use spacetime indices that run from 1 to 4. Also no need for the Vectors package (more comments on this at the end).

 

The simplest is then to use su2indices, which run from 1 to 3, and for which KroneckerDelta  is a tensor (actually, the metric regarding those indices, it is explained in its help page). So,

Setup(su2indices = lowercaselatin, coordinates = cartesian)

[coordinatesystems = {X}, su2indices = lowercaselatin]

(1)

Define your unit-vector tensor. For visualization purposes, use this macro

macro(R = `#mover(mi("r"),mo("&and;"))`)``


You can enter your position vector in this way

R[i] = [x, y, z]/sqrt(x^2+y^2+z^2)

`#mover(mi("r"),mo("&and;"))`[i] = [x/(x^2+y^2+z^2)^(1/2), y/(x^2+y^2+z^2)^(1/2), z/(x^2+y^2+z^2)^(1/2)]

(2)

Define(`#mover(mi("r"),mo("&and;"))`[i] = [x/(x^2+y^2+z^2)^(1/2), y/(x^2+y^2+z^2)^(1/2), z/(x^2+y^2+z^2)^(1/2)])

{Physics:-Dgamma[mu], Physics:-Psigma[mu], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], `#mover(mi("r"),mo("&and;"))`[i], Physics:-SpaceTimeVector[mu](X)}

(3)

Now your tensor `V__i,a` as shown in your image (you can change it as you see appropriate). It improves the readability if you use CompactDisplay

CompactDisplay((fA, fB, fC)(r))

fC(r)*`will now be displayed as`*fC

(4)

This is as the image you show

V[i, a] = (1-fA(r))*LeviCivita[a, i, j]*R[j]/(g*r)-fB(r)*(-R[a]*R[i]+KroneckerDelta[i, a])/(g*r)+fC(r)*R[i]*R[a]/(g*r)

V[i, a] = (1-fA(r))*Physics:-LeviCivita[a, i, j]*`#mover(mi("r"),mo("&and;"))`[j]/(g*r)-fB(r)*(-`#mover(mi("r"),mo("&and;"))`[a]*`#mover(mi("r"),mo("&and;"))`[i]+Physics:-KroneckerDelta[a, i])/(g*r)+fC(r)*`#mover(mi("r"),mo("&and;"))`[i]*`#mover(mi("r"),mo("&and;"))`[a]/(g*r)

(5)

Define(V[i, a] = (1-fA(r))*Physics[LeviCivita][a, i, j]*`#mover(mi("r"),mo("&and;"))`[j]/(g*r)-fB(r)*(-`#mover(mi("r"),mo("&and;"))`[a]*`#mover(mi("r"),mo("&and;"))`[i]+Physics[KroneckerDelta][a, i])/(g*r)+fC(r)*`#mover(mi("r"),mo("&and;"))`[i]*`#mover(mi("r"),mo("&and;"))`[a]/(g*r))

{Physics:-Dgamma[mu], Physics:-Psigma[mu], V[i, a], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], `#mover(mi("r"),mo("&and;"))`[i], Physics:-SpaceTimeVector[mu](X)}

(6)

These are the components of `#mover(mi("r"),mo("&and;"))`[i] and of V[i, a] and note there is no distinction between covariant and contravariant because the indices refer to an Euclidean SU2 space. So,  R[]

`#mover(mi("r"),mo("&and;"))`[a] = Array(%id = 36893488158327921108)

(7)

V[]

V[a, b] = Matrix(%id = 36893488151942105436)

(8)

Alternatively, if you do not need to work with the square roots around, it might be simpler to redefine the `#mover(mi("r"),mo("&and;"))`[i] as a function of the coordinates x, y, z as follows and only use the definition (2) in terms of square roots when necessary. So,

R[i] = R[i](x, y, z)

`#mover(mi("r"),mo("&and;"))`[i] = `#mover(mi("r"),mo("&and;"))`[i](x, y, z)

(9)

Define(redo, `#mover(mi("r"),mo("&and;"))`[i] = `#mover(mi("r"),mo("&and;"))`[i](x, y, z))

{Physics:-Dgamma[mu], Physics:-Psigma[mu], V[i, a], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], `#mover(mi("r"),mo("&and;"))`[i], Physics:-SpaceTimeVector[mu](X)}

(10)

CompactDisplay(R(x, y, z))

`#mover(mi("r"),mo("&and;"))`(x, y, z)*`will now be displayed as`*`#mover(mi("r"),mo("&and;"))`

(11)

To use this new definition (9), you need to redo the definition of V[i, a] done in (5)

Define(redo, V[i, a] = (1-fA(r))*Physics[LeviCivita][a, i, j]*`#mover(mi("r"),mo("&and;"))`[j]/(g*r)-fB(r)*(-`#mover(mi("r"),mo("&and;"))`[a]*`#mover(mi("r"),mo("&and;"))`[i]+Physics[KroneckerDelta][a, i])/(g*r)+fC(r)*`#mover(mi("r"),mo("&and;"))`[i]*`#mover(mi("r"),mo("&and;"))`[a]/(g*r))

{Physics:-Dgamma[mu], Physics:-Psigma[mu], V[i, a], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], `#mover(mi("r"),mo("&and;"))`[i], Physics:-SpaceTimeVector[mu](X)}

(12)

Now you have

R[]

`#mover(mi("r"),mo("&and;"))`[a] = Array(%id = 36893488158265443860)

(13)

where all of them are functions of x, y, z. To see that, use show

show

`#mover(mi("r"),mo("&and;"))`[a] = Array(%id = 36893488158265443860)

(14)

And for V[a, b]

V[]

V[a, b] = Matrix(%id = 36893488158296509364)

(15)

A comment on the use of Vectors: currently, you can define a unit vector that is also a tensor. For example: after loading Vectors, everything that starts and ends with an underscore is a unit vector

with(Vectors)

_u_

_u_

(16)

Use the `.` multiplication operator instead of `*` to mean scalar product of vectors

%.%

1

(17)

Then you can define a unit vector as a tensor; I here use 1D input here to make it clear what is what I am entering

_u_[j] = [_u__1_, _u__2_, _u__3_]

_u_[j] = [_u__1_, _u__2_, _u__3_]

(18)

Define(_u_[j] = [_u__1_, _u__2_, _u__3_])

{Physics:-Dgamma[mu], Physics:-Psigma[mu], V[i, a], _u_[j], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], `#mover(mi("r"),mo("&and;"))`[i], Physics:-SpaceTimeVector[mu](X)}

(19)

Now you have

_u_[]

_u_[a] = Array(%id = 36893488158327943524)

(20)

_u_[1]._u_[1]

1

(21)

_u_[1]._u_[2]

Physics:-Vectors:-`.`(_u__1_, _u__2_)

(22)

NULL

_u_[a] = Array(%id = 36893488158327943524)

(23)

_u_[a]._u_[b]

Physics:-Vectors:-`.`(_u_[a], _u_[b])

(24)

eval(Physics[Vectors][`.`](_u_[a], _u_[b]), [a = 1, b = 1])

1

(25)

eval(Physics[Vectors][`.`](_u_[a], _u_[b]), [a = 1, b = 2])

Physics:-Vectors:-`.`(_u__1_, _u__2_)

(26)

But then we have a problem with your expression: the first term,

(1 - fA(r))*1/g*1/r*LeviCivita[a, i, j]*_r_[j]

(1-fA(r))*Physics:-LeviCivita[a, i, j]*_r_[j]/(g*r)

(27)

The above is a vector (see Identify )

Identify((1-fA(r))*Physics[LeviCivita][a, i, j]*_r_[j]/(g*r))

5

(28)

But neither the second nor the third term is a vector, they are scalars:

fB(r)*1/g*1/r*(KroneckerDelta[i, a] - (_r_[i] . _r_[a]))

fB(r)*(Physics:-KroneckerDelta[a, i]-Physics:-Vectors:-`.`(_r_[i], _r_[a]))/(g*r)

(29)

Identify(fB(r)*(Physics[KroneckerDelta][a, i]-Physics[Vectors][`.`](_r_[i], _r_[a]))/(g*r))

0

(30)

fC(r)*1/g*1/r*(_r_[i] . _r_[a])

fC(r)*Physics:-Vectors:-`.`(_r_[i], _r_[a])/(g*r)

(31)

Identify(fC(r)*Physics[Vectors][`.`](_r_[i], _r_[a])/(g*r))

0

(32)

So, this expression is invalid because you are adding a vector with a scalar,

V[i, a] = (1 - fA(r))*1/g*1/r*LeviCivita[a, i, j]*_r_[j] - fB(r)*1/g*1/r*(KroneckerDelta[i, a] - (_r_[i] . _r_[a])) + fC(r)*1/g*1/r*(_r_[i] . _r_[a])

Error, (in Physics:-Vectors:-+) wrong sum of a vector with the scalar -fB(r)/g/r*(Physics:-KroneckerDelta[a,i]-(_r_[i] . _r_[a])) |lib/Physics/Vectors/src/operations.mm:87|

 

``


 

Download V_Tensor_(reviewed).mw

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


Download FeynmanIntegral.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions
Research and Education, passionate about all that

Hi @nm
First, your expectation is not correct: determining the general form of a symmetry for a first-order ODE is as difficult as solving the ODE itself. I almost had my first paper in the area rejected because of that truth, which however can be a prejudice in practice ... So what is all this hype about symgen, then? It scans for simpler forms, something that can be done systematically. For this problem, the internal heuristic algorithm searching for a polynomial symmetry estimates degree = 2, not enough.

Unfortunately, the help page ?symgen says 'dgun' instead of '`ODEtools/dgun`', or else _Env_symgen_dgun. Both set the upper bound for the polynomial or rational forms of a symmetry, useful when the internal algorithm doesn't help.

Independent of that, Hydon's book says, as you show, "... [this ode] is not easily solved by any standard method". So much for that ... Maple's dsolve solves it almost instantly, regardless of you setting the value of `ODEtools/dgun`. This is an Abel type equation with nonconstant invariant, belonging to the AIR class (try a higher value of infolevel for dsolve), so it can systematically be transformed into a 2nd order linear ODE admitting computable hypergeometric functions, and from there,

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft (Emeritus), Canada
Research & Education, passionate about all that

Originally, the Updates contained only changes to the Physics package, and, by chance, I tightened the update of the "date of a version" to saving the Physics package. The project, however, quickly evolved into Updates that could involve changes to any part of the Maple library, but the update of the version's date still only happened when Physics was saved. Since the recent versions of the Updates involved changes that didn't require saving Physics, the version date didn't change. In the latest one (from today) the version's date reappears correct.

Best wishes for 2025!

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

Change_of_variables_x_to_g(x).mw

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

As explained in a comment, this was a problem related to recent fixes in Typesetting, introduced in v.1835. This change now resolves that problem. To install the corrected version, as usual, input Physics:-Version(latest);

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

Thanks for the report; this one is fixed. To install the fix in Maple 2024, as usual, input Physics:-Version(latest);

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


Download Different_Hilbert_spaces.mw

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

I also don't like unnecessary brackets. I touched the Typesetting so that, at least for this example, we do not have unnecessary brackets anymore. To install, as usual, input Physics:-Version(latest). Now, the Typesetting code is tricky; could you please help posting here:

  • More cases of unnecessary brackets.
  • Any case you think the brackets are missing, so the opposite situation.

Thanks

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

To have the fix installed, open Maple and input Physics:-Version(latest);

Now, clearly, "no output at all", was a bug. I don't know what you actually meant by "Did Maple always behave this way for Laplace?"

On your comparison with Maple competitors, Mathematica or any other one, I'd like to make a point clearly: neither it produces shame nor urgency. Actually, when I read these strange comparisons (like a bug with a no-bug), I personally dislike the communication style. For me, it is just not constructive or purposeless, making me automatically lower the issue's priority. Fixing issues on the fly, as is the case of the Maplesoft Physics Updates project, has the underlying idea of collaboration and excitement, say, the opposite of such adversarial comparisons of inequivalent things.

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

Section 7 of ?Physics,Tensors is called Inert Tensors. Regarding a tensor definition, e.g. for Ricci or any other one, also the ones you define using defining equations, to see the definition even when the tensor has all of its components equal to zero, use the 'definition' keyword to index the tensor, e.g. input Ricci[definition].

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

1 2 3 4 5 6 7 Last Page 2 of 60