Cadabra Q&A - Recent questions and answers in Bug reports
http://cadabra.science/qa/qa/bug-reports
Powered by Question2AnswerQuestion about eliminate_metric
http://cadabra.science/qa/1784/question-about-eliminate_metric
<p>Hello. I noticed that even when I'm writing the position = independent index properties, the eliminate_metric command can contract the expression indeces inside the partial derivative and outside, as in the following example:</p>
<pre><code>{\mu,\nu,\rho,\sigma,\kappa,\lambda,\eta,\chi#}::Indices(full, position=independent);
{m,n,p,q,r,s,t,u,v,w,x,y,z,m#}::Indices(subspace, position=independent, parent=full);
{\mu,\nu,\rho,\sigma,\kappa,\lambda,\eta,\chi#}::Integer(1..4);
{m,n,p,q,r,s,t,u,v,w,x,y,z,m#}::Integer(1..3);
\partial{#}::PartialDerivative.
\nabla{#}::Derivative.
g_{\mu\nu}::Metric.
g^{\mu\nu}::InverseMetric.
g_{\mu? \nu?}::Symmetric.
g^{\mu? \nu?}::Symmetric.
h_{m n}::Metric.
h^{m n}::InverseMetric.
\delta^{\mu?}_{\nu?}::KroneckerDelta.
\delta_{\mu?}^{\nu?}::KroneckerDelta.
\delta^{m?}_{n?}::KroneckerDelta.
\delta_{m?}^{n?}::KroneckerDelta.
\delta^{\mu?}_{n?}::KroneckerDelta.
\delta_{\mu?}^{n?}::KroneckerDelta.
F_{m n}::AntiSymmetric.
\pi::Depends(\nabla{#}).
def tidy (expr):
converge(expr):
distribute(expr)
product_rule(expr)
canonicalise(expr)
return expr
def expand_nabla(ex):
for nabla in ex[r'\nabla']:
nabla.name=r'\partial'
dindex = nabla.indices().__next__()
for arg in nabla.args():
ret:=0;
for index in arg.free_indices():
t2:= @(arg);
if index.parent_rel==sub:
t1:= -\Gamma^{\rho}_{@(dindex) @(index)};
t2[index]:= _{\rho};
else:
t1:= \Gamma^{@(index)}_{@(dindex) \rho};
t2[index]:= ^{\rho};
ret += Ex(str(nabla.multiplier)) * t1 * t2
nabla += ret
return ex
Gtog:= \Gamma^{\lambda?}_{\mu?\nu?} ->
(1/2) * g^{\lambda?\kappa} (
\partial_{\nu?}{ g_{\kappa\mu?} } + \partial_{\mu?}{ g_{\kappa\nu?} } - \partial_{\kappa}{ g_{\mu?\nu?} } );
box:= g^{\mu \nu} \nabla_{\mu}{\nabla_{\nu}{\pi}};
expand_nabla(_);
substitute(_,Gtog);
tidy(box);
split_index(_, $\mu, m1, 4$, repeat=True)
substitute(_, $\partial_{4}{A??} -> 0$, repeat=True)
substitute(_, $\partial_{4 m?}{A??} -> 0$, repeat=True)
substitute(_, $\partial_{m? 4}{A??} -> 0$, repeat=True)
canonicalise(_);
substitute(_, $g_{4 4} -> \phi**{2}$ )
substitute(_, $g_{m 4} -> \phi**{2} A_{m}$ )
substitute(_, $g_{4 m} -> \phi**{2} A_{m}$ )
substitute(_, $g_{m n} -> h_{m n} + \phi**{2} A_{m} A_{n}$ )
substitute(_, $g^{4 4} -> \phi**{-2} + A_{m} h^{m n} A_{n}$ )
substitute(_, $g^{m 4} -> - h^{m n} A_{n}$ )
substitute(_, $g^{4 m} -> - h^{m n} A_{n}$ )
substitute(_, $g^{m n} -> h^{m n}$ );
tidy(box);
substitute(_, $\partial_{p}{h^{n m}} h_{q m} -> - \partial_{p}{h_{q m}} h^{n m}$ )
collect_factors(_)
sort_product(_)
converge(box):
substitute(_, $h_{m1 m2} h^{m3 m2} -> \delta_{m1}^{m3}$, repeat=True )
eliminate_kronecker(_)
canonicalise(_)
;
substitute(_, $\partial_{n}{A_{m}} -> 1/2*\partial_{n}{A_{m}} + 1/2*F_{n m} + 1/2*\partial_{m}{A_{n}}$ )
distribute(_)
sort_product(_)
canonicalise(_)
rename_dummies(_);
meld(_);
eliminate_metric(_);
eliminate_metric(_);
</code></pre>
<p>And at the end I get:<br>
<img src="https://sun9-40.userapi.com/impg/UZghUKwfJihpLs-VuumoSxX4U3_4wWaPu1gIWw/7VFkPkc0Naw.jpg?size=984x179&quality=96&proxy=1&sign=dd1ae5f8bce563f35199ea74a631de96" alt="result"><br>
This is all very long, but I wanted to show the whole path that leads to the error. In fact, this kind of result is obtained with almost any option when I use eliminate_metric more than once in my program. <br>
Is this some kind of bug or am I doing something wrong?</p>
Bug reportshttp://cadabra.science/qa/1784/question-about-eliminate_metricWed, 28 Oct 2020 14:14:26 +0000Answered: After alt+Up or alt-Down, cursor fails to auto-jump into newly created cell.
http://cadabra.science/qa/1727/after-alt-down-cursor-fails-auto-jump-into-newly-created-cell?show=1749#a1749
<p>Dom has added this as an option; go to <code>Tools</code> then <code>Options</code> and select the relevant option. That's with current master on github.</p>
Bug reportshttp://cadabra.science/qa/1727/after-alt-down-cursor-fails-auto-jump-into-newly-created-cell?show=1749#a1749Sun, 20 Sep 2020 11:57:40 +0000Answered: IPython notebooks example not working
http://cadabra.science/qa/963/ipython-notebooks-example-not-working?show=1731#a1731
<p>My old answer is no longer relevant; the current version (2.3.0 onwards) handles your example just fine.</p>
Bug reportshttp://cadabra.science/qa/963/ipython-notebooks-example-not-working?show=1731#a1731Sun, 30 Aug 2020 16:04:01 +0000Answered: Highlighted text almost invisible.
http://cadabra.science/qa/1552/highlighted-text-almost-invisible?show=1722#a1722
<p>Took a while, but this is now resolved in 2.3.1 on github.</p>
Bug reportshttp://cadabra.science/qa/1552/highlighted-text-almost-invisible?show=1722#a1722Sat, 29 Aug 2020 20:44:27 +0000Answered: Cadabra 2.3 for OpenSUSE Leap 15.1 ?
http://cadabra.science/qa/1713/cadabra-2-3-for-opensuse-leap-15-1?show=1721#a1721
<p>I have built a package of 2.3.1 for Leap 15.0, now available from the download page; can you give that a shot and let me know?</p>
Bug reportshttp://cadabra.science/qa/1713/cadabra-2-3-for-opensuse-leap-15-1?show=1721#a1721Sat, 29 Aug 2020 18:18:17 +0000Answered: LaTeXForm does not work properly(?)
http://cadabra.science/qa/1710/latexform-does-not-work-properly?show=1712#a1712
<p>These more fancy constructions were introduced in 2.3.0; you need to upgrade if you are running an earlier version.</p>
<p>The second example works (but again, only in 2.3.0 and later) if you do</p>
<pre><code>\GG{n??}::LaTeXForm("\stackrel{",n??,"}{G}").
GGtst := \GG{1};
</code></pre>
Bug reportshttp://cadabra.science/qa/1710/latexform-does-not-work-properly?show=1712#a1712Fri, 28 Aug 2020 08:23:01 +0000Answered: \delta^\mu_\mu fails to contract to 4.
http://cadabra.science/qa/1708/delta-mu_-mu-fails-to-contract-to-4?show=1709#a1709
<p>Cadabra does not automatically assume that the dimension of space-time is 4. So you have to declare the range of the indices. If you do</p>
<pre><code>{\mu,\nu}::Indices.
{\mu,\nu}::Integer(0..3).
\delta^{\mu}_{\nu}::KroneckerDelta.
Z := Z = \delta^\mu_\mu;
eliminate_kronecker(Z);
</code></pre>
<p>you get <code>Z=4</code> as expected.</p>
Bug reportshttp://cadabra.science/qa/1708/delta-mu_-mu-fails-to-contract-to-4?show=1709#a1709Thu, 27 Aug 2020 10:23:18 +0000Meld on undistributed input
http://cadabra.science/qa/1689/meld-on-undistributed-input
<p>Hello,</p>
<p>I've found situations where <code>meld</code> returns an incorrect 0, when applied on some undistributed sums, namely</p>
<pre><code>(w_{a} x_{b} y_{c}-w_{c} x_{b} y_{a}) f^{a c}
(w_{a} x_{b} y_{c} z_{d}-w_{c} x_{b} y_{a} z_{d}) f^{a b c}
(w_{a} x_{b} y_{c} z_{d}-w_{c} x_{b} y_{a} z_{d}) f^{a b c d}
</code></pre>
<p>More precisely, the above 3 lines are the output corresponding to the following input:</p>
<pre><code>{a,b,c,d,e#}::Indices(Lorentz,parent=ambient).
f^{a b}::TableauSymmetry(shape=(1,1),indices=(0,1)).
f^{a b c}::TableauSymmetry(shape=(2,1),indices=(0,1,2)).
f^{a b c d}::TableauSymmetry(shape=(2,2),indices=(0,1,2,3)).
fac:=f^{a c}.
fabc:=f^{a b c}.
fabcd:=f^{a b c d};
Dwy:=(w_{a} y_{c} - w_{c} y_{a}).
Dwxy:=(w_{a} x_{b} y_{c} - w_{c} x_{b} y_{a}).
Dwyz:=(w_{a} y_{c} z_{d} - w_{c} y_{a} z_{d}).
Dwxyz:=(w_{a} x_{b} y_{c} z_{d} - w_{c} x_{b} y_{a} z_{d}).
for f in [fac,fabc,fabcd]:
for D in [Dwy,Dwxy,Dwyz,Dwxyz]:
fD=f*D
meld(fD)
if fD==0:
print(f*D)
Df=D*f
meld(Df)
if Df==0:
print(D*f)
</code></pre>
Bug reportshttp://cadabra.science/qa/1689/meld-on-undistributed-inputWed, 15 Jul 2020 15:31:01 +0000Answered: Problem extracting free indices
http://cadabra.science/qa/1676/problem-extracting-free-indices?show=1680#a1680
<p>Well spotted, that's a bug indeed. It's fixed on github now.</p>
Bug reportshttp://cadabra.science/qa/1676/problem-extracting-free-indices?show=1680#a1680Wed, 08 Jul 2020 21:49:24 +0000Answered: Can not define Kronecker delta using Jupyter notebook
http://cadabra.science/qa/1667/can-not-define-kronecker-delta-using-jupyter-notebook?show=1668#a1668
<p>Are you sure you are using a Cadabra kernel, not a standard Python kernel? What does</p>
<pre><code>print(__cdbkernel__.version)
</code></pre>
<p>show when you evaluate it in a cell?</p>
Bug reportshttp://cadabra.science/qa/1667/can-not-define-kronecker-delta-using-jupyter-notebook?show=1668#a1668Wed, 17 Jun 2020 17:06:42 +0000Answered: bugs with sort_product&meld
http://cadabra.science/qa/1647/bugs-with-sort_product%26meld?show=1656#a1656
<p>The <code>meld</code> algorithm does not work with noncommuting/anticommuting objects yet, please wait a little longer.</p>
Bug reportshttp://cadabra.science/qa/1647/bugs-with-sort_product%26meld?show=1656#a1656Thu, 11 Jun 2020 08:13:12 +0000Problem with rename_dummies and sort_product
http://cadabra.science/qa/1649/problem-with-rename_dummies-and-sort_product
<p>Hello,</p>
<p>With the input</p>
<pre><code>{a,b,c#}::Indices("a");
ex:=1/2 X_{a} B^{a b} X_{b} + K^{a} X_{a};
vary(ex,$X_{a}->A_{a}$);
sort_product(ex);
rename_dummies(ex);
{\delta{#},Z{#},X{#},B{#},K{#}}::SortOrder;
ex:=1/2 X_{a} B^{a b} X_{b} + K^{a} X_{a};
vary(ex,$X_{a}->Z_{a}$);
sort_product(ex);
rename_dummies(ex);
\delta{#}::Accent;
ex:=1/2 X_{a} B^{a b} X_{b} + K^{a} X_{a};
vary(ex,$X_{a}->\delta{X_{a}}$);
sort_product(ex);
rename_dummies(ex);
</code></pre>
<p>The output I get is</p>
<pre><code>Attached property Indices(position=free) to {a, b, c#}.
1/2 X_{a} B^{a b} X_{b} + K^{a} X_{a}
1/2 A_{a} B^{a b} X_{b} + 1/2 X_{a} B^{a b} A_{b} + K^{a} A_{a}
1/2 A_{a} B^{a b} X_{b} + 1/2 A_{b} B^{a b} X_{a} + A_{a} K^{a}
1/2 A_{a} B^{a b} X_{b} + 1/2 A_{a} B^{b a} X_{b} + A_{a} K^{a}
Attached property SortOrder to {\delta(#), Z(#), X(#), B(#), K(#)}.
1/2 X_{a} B^{a b} X_{b} + K^{a} X_{a}
1/2 Z_{a} B^{a b} X_{b} + 1/2 X_{a} B^{a b} Z_{b} + K^{a} Z_{a}
1/2 Z_{a} X_{b} B^{a b} + 1/2 Z_{b} X_{a} B^{a b} + Z_{a} K^{a}
1/2 Z_{a} X_{b} B^{a b} + 1/2 Z_{b} X_{a} B^{a b} + Z_{a} K^{a}
Attached property Accent to \delta{#}.
1/2 X_{a} B^{a b} X_{b} + K^{a} X_{a}
1/2 \delta{X_{a}} B^{a b} X_{b} + 1/2 X_{a} B^{a b} \delta{X_{b}} + K^{a} \delta{X_{a}}
1/2 \delta{X_{a}} X_{b} B^{a b} + 1/2 \delta{X_{b}} X_{a} B^{a b} + \delta{X_{a}} K^{a}
1/2 \delta{X_{a}} X_{b} B^{a b} + 1/2 \delta{X_{b}} X_{a} B^{a b} + \delta{X_{a}} K^{a}
</code></pre>
<p>Is this behaviour expected? If yes, is there a way to obtain</p>
<pre><code> 1/2 Z_{a} X_{b} B^{a b} + 1/2 Z_{a} X_{b} B^{b a} + Z_{a} K^{a}
</code></pre>
<p>and</p>
<pre><code> 1/2 \delta{X_{a}} X_{b} B^{a b} + 1/2 \delta{X_{a}} X_{b} B^{b a} + \delta{X_{a}} K^{a}
</code></pre>
<p>instead?</p>
<p>In case it is really a bug, I run Cadabra 2.2.9 (built on April 7) on macOS High Sierra.</p>
Bug reportshttp://cadabra.science/qa/1649/problem-with-rename_dummies-and-sort_productMon, 25 May 2020 11:02:13 +0000Answered: Bug in @unwrap for Cadabra 1.42
http://cadabra.science/qa/761/bug-in-%40unwrap-for-cadabra-1-42?show=1601#a1601
<p>Fixed on github master now (finally...).</p>
Bug reportshttp://cadabra.science/qa/761/bug-in-%40unwrap-for-cadabra-1-42?show=1601#a1601Tue, 07 Apr 2020 19:34:02 +0000Answered: "unwrap" returns 0 if pushing anti-commuting constant past a mixed object
http://cadabra.science/qa/1598/unwrap-returns-pushing-commuting-constant-past-mixed-object?show=1599#a1599
<p>Good one. Internally, when Cadabra cannot figure out how to commute two objects, an internal function somewhere returns '0', instead of '+1' or '-1'. That zero should have made <code>unwrap</code> stop, but instead it just went ahead and then multiplied the resulting unwrapped expression with '0'. </p>
<p>Now fixed in github, can you give it a shot? It will leave that first expression untouched, because it cannot move <code>C</code> through <code>A F + G</code> without flipping that 2nd factor to <code>A F - G</code>, and it will not do that kind of thing. Hope that's ok for now.</p>
Bug reportshttp://cadabra.science/qa/1598/unwrap-returns-pushing-commuting-constant-past-mixed-object?show=1599#a1599Tue, 07 Apr 2020 19:16:24 +0000Bugs with 'sort_product'
http://cadabra.science/qa/1587/bugs-with-sort_product
<p>When I use 'sort_product' in the following code</p>
<pre><code>{\mu,\nu,\rho,sigma}::Indices(vector).
a^{\mu}::SelfNonCommuting.
{a^{\mu},b^{\mu}}::NonCommuting.
\nabla{#}::Derivative.
tr{#}::Trace.
ex:=tr{a^{\mu}\nabla^{\nu}{a^{\mu}}b^{\nu}\nabla^{\rho}{a^{\rho}}};
sort_product(_);
sort_product(_);
</code></pre>
<p>I find that cadabra don't know where to stop. This bug is similar to <a rel="nofollow" href="https://cadabra.science/qa/1434/about-data-structure-in-cadabra">this</a> and <a rel="nofollow" href="https://cadabra.science/qa/729/how-can-i-implement-cyclicity-of-trace">this</a>.</p>
Bug reportshttp://cadabra.science/qa/1587/bugs-with-sort_productFri, 27 Mar 2020 15:49:16 +0000Answered: Issues with 'canonicalise'
http://cadabra.science/qa/1576/issues-with-canonicalise?show=1577#a1577
<p>Well spotted, thanks for reporting this. I have just pushed a fix to github that handles part of the problem (when the content of the trace is a simple tensor, not a sum or product). The problem was (and to some extent still is) that the symmetries did not make it 'out of' the trace. Will post here when a full solution is available.</p>
Bug reportshttp://cadabra.science/qa/1576/issues-with-canonicalise?show=1577#a1577Sat, 21 Mar 2020 21:08:23 +0000Answered: question about untrace&ImaginaryI
http://cadabra.science/qa/1529/question-about-untrace%26imaginaryi?show=1531#a1531
<p>Now fixed in master on github.</p>
Bug reportshttp://cadabra.science/qa/1529/question-about-untrace%26imaginaryi?show=1531#a1531Sat, 28 Dec 2019 12:23:23 +0000Answered: Problems with combine(_)
http://cadabra.science/qa/1264/problems-with-combine-_?show=1430#a1430
<p>I'm pleased to report that the AntiCommuting issue has just been fixed in git. In your expression that is unaffected by combine(_), it sounds like that's just because you didn't put an indexbracket around M.</p>
Bug reportshttp://cadabra.science/qa/1264/problems-with-combine-_?show=1430#a1430Sun, 17 Nov 2019 16:22:49 +0000Answered: epsilon_to_delta function failed to evaluate
http://cadabra.science/qa/1423/epsilon_to_delta-function-failed-to-evaluate?show=1424#a1424
<p>The problem is that you are using indices on the epsilon symbols which are not part of the index set. In your first example, if you add the <code>e</code> index to the set by writing, instead of the first two lines, </p>
<pre><code>{a,b,c,d,e}::Indices.
{a,b,c,d,e}::Integer(1..3).
</code></pre>
<p>then it works. In the second example, you need to add <code>l, u, v</code> in order to make it work.</p>
Bug reportshttp://cadabra.science/qa/1423/epsilon_to_delta-function-failed-to-evaluate?show=1424#a1424Sat, 16 Nov 2019 10:13:51 +0000Answered: Failure of running cadabra on windows.
http://cadabra.science/qa/1259/failure-of-running-cadabra-on-windows?show=1415#a1415
<p>Please try the new 2.2.7f installer for windows, available at</p>
<p><a rel="nofollow" href="https://cadabra.science/packages/windows">https://cadabra.science/packages/windows</a></p>
<p>and let me know if that one is any better.</p>
Bug reportshttp://cadabra.science/qa/1259/failure-of-running-cadabra-on-windows?show=1415#a1415Sun, 10 Nov 2019 11:17:38 +0000Answered: Why the partial derivative example gives wrong answer?
http://cadabra.science/qa/1373/why-the-partial-derivative-example-gives-wrong-answer?show=1374#a1374
<p>The above works fine with the current version on github. If it does not for you,<br>
either upgrade, or say explicitly that the derivative is with respect to $\tau$,</p>
<pre><code> ex:= \partial_{\tau}{ f g};
</code></pre>
<p>or make $f$ depend on <code>\partial</code>:</p>
<pre><code> f::Depends(\partial{#}).
</code></pre>
<p>Otherwise the 'old' version of Cadabra which you use does not know how to figure out that <code>\partial</code> is a $\tau$-derivative. </p>
Bug reportshttp://cadabra.science/qa/1373/why-the-partial-derivative-example-gives-wrong-answer?show=1374#a1374Sun, 13 Oct 2019 13:46:34 +0000Answered: Dotted indices are not substituted correctly
http://cadabra.science/qa/1327/dotted-indices-are-not-substituted-correctly?show=1332#a1332
<p>A fix for this bug is now on the master branch on github. If you encounter related bugs with 'accented' indices (as you hinted at near the end of your post), please post more details. </p>
Bug reportshttp://cadabra.science/qa/1327/dotted-indices-are-not-substituted-correctly?show=1332#a1332Sat, 21 Sep 2019 19:51:39 +0000Answered: Improper handling of fractions
http://cadabra.science/qa/1273/improper-handling-of-fractions?show=1275#a1275
<p>Thanks for reporting this, and for doing the digging! Yes, this is caused by a bug in the ping-pong procedure between Cadabra's internal representation and Sympy. But in fact it goes deeper: it has to do with the fact that Cadabra would not always simplify rational expressions to canonical form.</p>
<p>I have pushed a partial fix for this to the <code>fix/collectcomponents</code> branch on github. Feel free to test (it does do the right thing for your example above, but I have had no time to do more testing and checking). </p>
Bug reportshttp://cadabra.science/qa/1273/improper-handling-of-fractions?show=1275#a1275Tue, 27 Aug 2019 21:58:14 +0000Answered: canonicalise with calagraphic font
http://cadabra.science/qa/1254/canonicalise-with-calagraphic-font?show=1255#a1255
<p>Cadabra has considerable flexibility in defining symbols, but <code>{\cal F}</code> goes a bit too far. What happens here is that this expression gets interpreted as the product of <code>\cal</code> and <code>F</code>, and then this gets indices added to it. Then all hell breaks loose... Granted, some kind of error message would probably have helped you here.</p>
<p>The easiest way around this is to do</p>
<pre><code>calF_{a b}::AntiSymmetric;
calF_{a b}::LaTeXForm("{\cal F}").
</code></pre>
<p>and then</p>
<pre><code>example2:= calF_{a b} calF_{c d} - calF_{a c} calF_{b d} ;
</code></pre>
<p>This will display the way you want because of the <code>LaTeXForm</code> property, and saves some typing as well.</p>
Bug reportshttp://cadabra.science/qa/1254/canonicalise-with-calagraphic-font?show=1255#a1255Fri, 16 Aug 2019 17:08:28 +0000Derivatives depend on index position
http://cadabra.science/qa/1250/derivatives-depend-on-index-position
<p>Hi,</p>
<p>I noticed recently that <br>
- the dependence of an object only includes the given position of the index<br>
and also that<br>
- objects with derivatives cannot change their index-position<br>
if the index position is given as fixed.</p>
<p>For example, the Exp in the following gives zero, because only A with an upper index depends on the derivative:</p>
<pre><code>{\mu,\nu}::Indices(position=fixed);
{\mu,\nu}::Integer(0..3);
\partial{#}::PartialDerivative;
A^\mu::Depends(\partial{#});
Exp:= \partial^{\mu}{A_\nu};
unwrap(_);
</code></pre>
<p>Of course I could just make A dependent on \partial for lowercase indices as well or just for every index position via </p>
<pre><code>A{#}::Depends(...);
</code></pre>
<p>but it still strikes me as odd.</p>
<p>Secondly, once I have defined objects with derivatives, the index position does not change through the use of canonicalise. So for example</p>
<pre><code>Exp:= \partial_{\mu}{A^\mu} - \partial^{\mu}{A_\mu};
canonicalise(_);
</code></pre>
<p>gives not zero as expected. And even if I derive a scalar, its index is fixed, so</p>
<pre><code>Exp:= A^\mu \partial_{\mu}{B} - A_\mu \partial^{\mu}{B};
canonicalise(_);
</code></pre>
<p>does not give zero.</p>
<p>I usually don't want to think about the position of dummy indices. So if it would be possible to give the index positions of derivatives a bit more freedom I would be very grateful!</p>
<p>Cheers,<br>
Karim</p>
Bug reportshttp://cadabra.science/qa/1250/derivatives-depend-on-index-positionFri, 16 Aug 2019 08:29:19 +0000A documentation bug
http://cadabra.science/qa/1242/a-documentation-bug
<p>In the documentation page <a rel="nofollow" href="https://cadabra.science/manual/cdb/core/component.html">component</a>, there is no mention to the fact that one have to import the function</p>
<pre><code>from cdb.core.component import get_component
</code></pre>
<p>At least I have to do it.</p>
Bug reportshttp://cadabra.science/qa/1242/a-documentation-bugTue, 13 Aug 2019 11:02:22 +0000Kronecker $\delta$ for Indices of different dimensions
http://cadabra.science/qa/1240/kronecker-%24-delta%24-for-indices-of-different-dimensions
<p>Hi,<br>
I have $\delta$-symbols involving a color index $a$ that runs from 1 to 3 and a Euclidian index $\mu$ from 1 to 4.</p>
<pre><code>{\mu,\nu}::Indices(Euklid, position=free).
{\mu,\nu}::Integer(1..4).
{a,b}::Indices(Color, position=independent).
{a,b}::Integer(1..3).
\delta_{#}::KroneckerDelta.
</code></pre>
<p>But when I try to contract them like in</p>
<pre><code>ex := \delta_{a \mu} \delta_{a \mu} ;
eliminate_kronecker(ex);
</code></pre>
<p>I get 4 but it should be 3. When I reverse the order of the indices I get the correct number:</p>
<pre><code>ex2 := \delta_{\mu a} \delta_{\mu a} ;
eliminate_kronecker(ex2);
</code></pre>
<p>This gives 3.</p>
<p>I suppose cadabra contracts the first two indices first so in the first case we get</p>
<p>$\delta<em>{a \mu} \delta^{a \mu} = \delta</em>{\mu}^{\mu} = 4$</p>
<p>and in the second it becomes </p>
<p>$\delta<em>{\mu a} \delta^{\mu a} = \delta</em>{a}^{a} = 3$.</p>
<p>Maybe this behavior could be avoided by always first contracting the indices of higher dimension? In the meantime, can somebody think of a workaround? </p>
<p>In the interest of completeness:</p>
<pre><code>ex3 := \delta_{\mu a} \delta_{a \mu} ;
eliminate_kronecker(ex3);
</code></pre>
<p>gives 4 and </p>
<pre><code>ex4 := \delta_{a \mu} \delta_{\mu a} ;
eliminate_kronecker(ex4);
</code></pre>
<p>returns 3.</p>
<p>Thank you</p>
<p>EDIT: Directly after asking I think I found a workaround by adding a substitution to the post_process function that sorts the indices such that the Euclidian one gets contracted first. </p>
<pre><code>def post_process(ex):
substitute( ex, $\delta_{a \mu} = \delta_{\mu a}$ )
</code></pre>
Bug reportshttp://cadabra.science/qa/1240/kronecker-%24-delta%24-for-indices-of-different-dimensionsMon, 12 Aug 2019 08:07:36 +0000Variation of \sqrt terms (bug)
http://cadabra.science/qa/1234/variation-of-sqrt-terms-bug
<p>Hello, I think I have found a bug as shown below;</p>
<p><img src="https://cdn.mathpix.com/snip/images/0FVJQdDBXr-NmbkWn8GXJ59yaXLez_tJ3_K-raMqN2Y.original.fullsize.png" alt="enter image description here"></p>
<p>Have a nice day.</p>
Bug reportshttp://cadabra.science/qa/1234/variation-of-sqrt-terms-bugWed, 07 Aug 2019 09:20:47 +0000Answered: Vanishing Self-Contracted Metric
http://cadabra.science/qa/1207/vanishing-self-contracted-metric?show=1208#a1208
<p>Be careful with index positions. If you want upper and lower indices to mean something different, declare your indices with the <code>position=fixed</code> attribute. So</p>
<pre><code>{\alpha,\beta,\mu,\nu}::Indices(position=fixed);
{\alpha,\beta,\mu,\nu}::Integer(0..3);
\eta^{\mu\nu}::Metric;
\eta_{\mu\nu}::InverseMetric;
\eta_\mu^\nu::KroneckerDelta;
\eta^\mu_\nu::KroneckerDelta;
Exp:= \eta^\mu_\mu \eta^\alpha_\beta A^\beta;
eliminate_metric(_);
eliminate_kronecker(_);
</code></pre>
<p>This gives the expected answer.</p>
Bug reportshttp://cadabra.science/qa/1207/vanishing-self-contracted-metric?show=1208#a1208Mon, 15 Jul 2019 08:45:38 +0000Answered: Kernel crashing
http://cadabra.science/qa/1170/kernel-crashing?show=1182#a1182
<p>You probably either did not terminate an expression line with <code>;</code> or <code>:</code>, or you tried to wrap a Cadabra expression over multiple lines by using <code>\</code>. If it's the latter, just remove that <code>\</code>; Cadabra expressions can wrap over multiple lines without Python's line continuation character.</p>
Bug reportshttp://cadabra.science/qa/1170/kernel-crashing?show=1182#a1182Mon, 10 Jun 2019 09:01:41 +0000Action of sort_product depends on the choice of index
http://cadabra.science/qa/1164/action-of-sort_product-depends-on-the-choice-of-index
<p>Hi everyone, </p>
<p>I encountered the following surprising example while trying to simplify the expression </p>
<pre><code>F^{d}_{a e}* F^{f}_{b f} - F^{f}_{b f}* F^{d}_{a e}
</code></pre>
<p>to zero using the following code</p>
<pre><code>{a, b, c, d, e, f, g#}::Indices(T, position= independent, parent=double);
{F^{d}_{a e}, F^{f}_{b f}}::SortOrder.
Exp:= F^{d}_{a e}* F^{f}_{b f} - F^{f}_{b f}* F^{d}_{a e};
sort_product(_);
sort_sum(_);
canonicalise(_);
rename_dummies(_);
collect_terms(_);
</code></pre>
<p>Strangely, the obtained result is </p>
<pre><code>F^{d}_{a e} F^{c}_{b c}-F^{c}_{b c} F^{d}_{a e}
</code></pre>
<p>i.e. sort_product failed to order the products. </p>
<p>Even stranger, if I replace the index <code>f</code> in the first term by <code>c</code> i.e. if use the code: </p>
<pre><code>{a, b, c, d, e, f, g#}::Indices(T, position= independent, parent=double);
{F^{d}_{a e}, F^{f}_{b f}}::SortOrder.
Exp:= F^{d}_{a e}* F^{c}_{b c} - F^{f}_{b f}* F^{d}_{a e};
sort_product(_);
sort_sum(_);
canonicalise(_);
rename_dummies(_);
collect_terms(_);
</code></pre>
<p>then everything works fine and the output is zero, as it should. </p>
<p>I tested this on both Mac and Ubuntu and the result is the same. </p>
<p>Does anyone have an idea where the bug came from and how to fix it?</p>
<p>Thank you already for any information, </p>
<p>Kevin</p>
Bug reportshttp://cadabra.science/qa/1164/action-of-sort_product-depends-on-the-choice-of-indexThu, 16 May 2019 01:30:28 +0000Answered: Exportaing to LaTeX a Cadabra2 notebook
http://cadabra.science/qa/1152/exportaing-to-latex-a-cadabra2-notebook?show=1161#a1161
<p>Now fixed on github, thanks.</p>
Bug reportshttp://cadabra.science/qa/1152/exportaing-to-latex-a-cadabra2-notebook?show=1161#a1161Wed, 08 May 2019 11:32:56 +0000Answered: import cdb.sympy.solvers hangs the kernel
http://cadabra.science/qa/1142/import-cdb-sympy-solvers-hangs-the-kernel?show=1160#a1160
<p>The new UTF8 parser barfed on a double backslash. Still not quite sure why, but I have corrected that in the <code>core/packages/cdb/sympy/solvers.cnb</code> file and this package should work now again. Update on github master.</p>
Bug reportshttp://cadabra.science/qa/1142/import-cdb-sympy-solvers-hangs-the-kernel?show=1160#a1160Wed, 08 May 2019 11:02:43 +0000Answered: unexpected crash
http://cadabra.science/qa/390/unexpected-crash?show=1133#a1133
<p>In case anyone is still following this thread, this is now fixed on github master (version 2.2.7 or later).</p>
Bug reportshttp://cadabra.science/qa/390/unexpected-crash?show=1133#a1133Thu, 18 Apr 2019 11:56:11 +0000Answered: Inconsistencies in factor_out and factor_in
http://cadabra.science/qa/1126/inconsistencies-in-factor_out-and-factor_in?show=1130#a1130
<p>Let me first address the case which does work with the current version (at least for me):</p>
<pre><code>ex2:= (a + b - c) d + (-a -b + c) d
factor_out(_,$d$);
</code></pre>
<p>correctly factors out $d$. Factoring out composite expressions (like the $a+b-c$) is currently not supported, unfortunately.</p>
<p>All the other cases have to do with factoring out tensors. In general, for that to work, you need to have the indices on the expression you want to factor out be the same on all terms (so sort the expression and <code>rename_dummies</code> first), and it needs to be un-ambiguous (your last example isn't, because the <code>factor_out(_, $g_{a b}$)</code> means 'factor out the g-tensor with two indices', not 'factor out the g-tensor with one index 'a' and one 'b'').</p>
<p>Fixing this has been on the TODO list for some time, but there are only 25 hours in each day unfortunately.</p>
Bug reportshttp://cadabra.science/qa/1126/inconsistencies-in-factor_out-and-factor_in?show=1130#a1130Thu, 18 Apr 2019 09:53:06 +0000Answered: Cadabra crashes on non-ASCII input
http://cadabra.science/qa/1127/cadabra-crashes-on-non-ascii-input?show=1129#a1129
<p>This should now be fixed with the current version on github. There are still a few issues with actually using non-ascii symbols in Cadabra expressions, but the crashes are gone.</p>
Bug reportshttp://cadabra.science/qa/1127/cadabra-crashes-on-non-ascii-input?show=1129#a1129Thu, 18 Apr 2019 09:37:54 +0000Answered: to_lhs produces Python syntax error
http://cadabra.science/qa/1101/to_lhs-produces-python-syntax-error?show=1102#a1102
<p>Thanks for reporting this, you are number 2 today ;-) It's now fixed on github, or if you want to patch it locally: just replace that line with <code>to_rhs(ex, *parts)</code>.</p>
Bug reportshttp://cadabra.science/qa/1101/to_lhs-produces-python-syntax-error?show=1102#a1102Wed, 27 Mar 2019 12:09:34 +0000Answered: Bug in split index cadabra 2.2.6 (build 2031.aa34dcb4e3 dated 2019-03-04)
http://cadabra.science/qa/1044/bug-split-index-cadabra-build-2031-aa34dcb4e3-dated-2019-04?show=1052#a1052
<p>I have pushed a fix for this to github master. Are you able to build from source?</p>
Bug reportshttp://cadabra.science/qa/1044/bug-split-index-cadabra-build-2031-aa34dcb4e3-dated-2019-04?show=1052#a1052Tue, 05 Mar 2019 15:04:28 +0000Answered: Grouping substitution rules makes the kernel unresponsive
http://cadabra.science/qa/1001/grouping-substitution-rules-makes-the-kernel-unresponsive?show=1002#a1002
<p>Those output lines suggest that you used a version which wasn't really meant for production. I am assuming you compiled from source? Can you try pulling the latest version from github, building that and then trying again?</p>
<p>If that does not solve the problem, please email your notebook to info@cadabra.science and I'll have a look. If it worked before it is probably something small.</p>
Bug reportshttp://cadabra.science/qa/1001/grouping-substitution-rules-makes-the-kernel-unresponsive?show=1002#a1002Fri, 14 Dec 2018 11:14:08 +0000Issue with combine algorithm
http://cadabra.science/qa/953/issue-with-combine-algorithm
<p>I am using cadabra 2.2.1 </p>
<p>ex:=A^\alpha B<em>{\alpha};<br>
combine(</em>);</p>
<p>produces the output (BA) which is clearly unexpected while, </p>
<p>ex:=A<em>\alpha B</em>{\alpha};<br>
combine(_);</p>
<p>produces the output (AB) which is expected. I require the combine to work for contractions like Einstein summation. Please help</p>
Bug reportshttp://cadabra.science/qa/953/issue-with-combine-algorithmSat, 13 Oct 2018 13:11:03 +0000Require two calls to canonicalise?
http://cadabra.science/qa/938/require-two-calls-to-canonicalise
<p>Hi Folks,</p>
<p>The following code requires two calls to <code>canonicalise</code> to get the expected output (zero).<br>
Is this expected behaviour? </p>
<pre><code>W^{a}_{b c}::TableauSymmetry(shape={2}, indices={1,2});
{a,b,c,d,e,f,g,h#}::Indices(position=fixed).
foo := v_{a} W^{a}_{b c} - v^{a} W_{a c b};
sort_product (foo);
canonicalise (foo);
canonicalise (foo);
</code></pre>
<p>Cheers,<br>
Leo</p>
Bug reportshttp://cadabra.science/qa/938/require-two-calls-to-canonicaliseFri, 28 Sep 2018 09:51:08 +0000Answered: Generic typesetting LaTex error on Windows 10, Cadabra2.2.1d
http://cadabra.science/qa/930/generic-typesetting-latex-error-on-windows-10-cadabra2-2-1d?show=932#a932
<p>Once that happens, can you open a command line window, navigate to the TMPDIR path, and do</p>
<pre><code>pdflatex [filename]
</code></pre>
<p>where <code>filename</code> is, in the example above, <code>sglw.2.tex</code>. Then send me the resulting error message (if any).</p>
<p>It is possible that MikTeX is installed to not download missing packages, or perhaps the <code>pdflatex</code> command is not in your path, but I can't see that from the error message you quoted.</p>
Bug reportshttp://cadabra.science/qa/930/generic-typesetting-latex-error-on-windows-10-cadabra2-2-1d?show=932#a932Thu, 20 Sep 2018 08:24:30 +0000Answered: Derivatives not inheriting SelfAntiCommuting with canonicalise
http://cadabra.science/qa/908/derivatives-inheriting-selfanticommuting-canonicalise?show=909#a909
<p>This is a bug, thanks for reporting it. The code path for <code>sort_product</code> is different from the one for <code>canonicalise</code>; the latter is more complicated and contains a bug somewhere. <br>
I have opened an issue at <a rel="nofollow" href="https://github.com/kpeeters/cadabra2/issues/113">https://github.com/kpeeters/cadabra2/issues/113</a> .</p>
Bug reportshttp://cadabra.science/qa/908/derivatives-inheriting-selfanticommuting-canonicalise?show=909#a909Fri, 24 Aug 2018 18:01:10 +0000Answered: Bug: Generic TeX error
http://cadabra.science/qa/728/bug-generic-tex-error?show=901#a901
<p>There is now a 2.2.1d installer on the download page; can anyone with issues on Windows please try that one? I think this one should finally do the trick...</p>
<p>It is probably advisable to first remove the installation directory of any previous installs.</p>
Bug reportshttp://cadabra.science/qa/728/bug-generic-tex-error?show=901#a901Mon, 20 Aug 2018 16:08:02 +0000Answered: eliminate_kronecker(_) crashes on double derivatives
http://cadabra.science/qa/841/eliminate_kronecker-_-crashes-on-double-derivatives?show=842#a842
<p>When I run this, it correctly tells me that there is a repeated upper or lower index of fixed type (so there is an error message, but not a crash). If you want this to work with the index positions as they stand, you need to declare the index type as <code>position=free</code>. Fixed type indices of a given name can only occur once in super or subscript position.</p>
Bug reportshttp://cadabra.science/qa/841/eliminate_kronecker-_-crashes-on-double-derivatives?show=842#a842Tue, 31 Jul 2018 09:10:42 +0000Answered: noncomuting objects with derivatives are not conmuting
http://cadabra.science/qa/838/noncomuting-objects-with-derivatives-are-not-conmuting?show=839#a839
<p>Yes, that's a bug, or rather an incompleteness, as I haven't had time to sort out what is the right thing to do for inheritance of non-commutativity that works in all situations. The problem is that the partial derivative does not automatically inherit the commutativity properties of its arguments. </p>
<p>For the time being, you can add</p>
<pre><code>\partial{#}::SelfNonCommuting;
</code></pre>
<p>which enforces that any partial derivative does not commute with any other, or do something more restrictive, e.g.</p>
<pre><code>\partial_{J}{A{#}}::SelfNonCommuting;
</code></pre>
Bug reportshttp://cadabra.science/qa/838/noncomuting-objects-with-derivatives-are-not-conmuting?show=839#a839Thu, 26 Jul 2018 20:48:53 +0000Answered: Substitute and dummy indices manipulation
http://cadabra.science/qa/803/substitute-and-dummy-indices-manipulation?show=815#a815
<p>I can't reproduce that problem here with the version currently in github. The substitution works fine. </p>
Bug reportshttp://cadabra.science/qa/803/substitute-and-dummy-indices-manipulation?show=815#a815Tue, 10 Jul 2018 20:20:05 +0000Answered: odd behaviour with indexbracket
http://cadabra.science/qa/781/odd-behaviour-with-indexbracket?show=782#a782
<p>You may want to upgrade to 2.x, where this works fine. If you can't do that, can you explain what is stopping you? (e.g. some feature which is broken/missing in 2.x but working in 1.x).</p>
Bug reportshttp://cadabra.science/qa/781/odd-behaviour-with-indexbracket?show=782#a782Tue, 12 Jun 2018 09:26:34 +0000Answered: Bug in \sqrt in cadabra v1.x
http://cadabra.science/qa/769/bug-in-sqrt-in-cadabra-v1-x?show=770#a770
<p>Thanks. This works fine in 2.x, indeed seems to be a display problem. I can't tell you if and when I have time to fix this for 1.x. Perhaps time to upgrade?</p>
Bug reportshttp://cadabra.science/qa/769/bug-in-sqrt-in-cadabra-v1-x?show=770#a770Thu, 07 Jun 2018 06:01:00 +0000Answered: keep_weight problem
http://cadabra.science/qa/753/keep_weight-problem?show=754#a754
<p>This was fixed recently (I think the fix went into 2.2.0 but there may be a small improvement to that which is only on github at the moment). In any case, the current github version does this correctly.</p>
Bug reportshttp://cadabra.science/qa/753/keep_weight-problem?show=754#a754Thu, 31 May 2018 16:55:41 +0000