Cadabra Q&A - Recent questions and answers in Bug reports
http://cadabra.science/qa/qa/bug-reports
Powered by Question2AnswerAnswered: Strange substitution behavior in Cadabra v1
http://cadabra.science/qa/2044/strange-substitution-behavior-in-cadabra-v1?show=2045#a2045
<p>A lot of fixes where made in <code>substitute</code> for v2, and I remember at least one issue in which the presence of <code>LaTeXForm</code> messed with the substitution. So I am not entirely surprised that it works in v2 now. I'll consider it closed for now, but if you find anything remotely similar in v2, please let me know.</p>
Bug reportshttp://cadabra.science/qa/2044/strange-substitution-behavior-in-cadabra-v1?show=2045#a2045Fri, 01 Oct 2021 17:35:34 +0000Answered: Substitute Affected by Unrelated Expression Definition
http://cadabra.science/qa/2027/substitute-affected-by-unrelated-expression-definition?show=2042#a2042
<p>Hi Simon,</p>
<p>I'm not getting the behaviour you describe. Am I doing something wrong?</p>
<p><img src="https://ibb.co/sPTzKtT" alt="enter image description here"></p>
Bug reportshttp://cadabra.science/qa/2027/substitute-affected-by-unrelated-expression-definition?show=2042#a2042Fri, 24 Sep 2021 10:11:51 +0000Answered: component_to_subrule function
http://cadabra.science/qa/2008/component_to_subrule-function?show=2009#a2009
<p>This is a recent addition; make sure you are running a current version of Cadabra.</p>
Bug reportshttp://cadabra.science/qa/2008/component_to_subrule-function?show=2009#a2009Wed, 30 Jun 2021 20:57:39 +0000Bug with isolate function
http://cadabra.science/qa/2007/bug-with-isolate-function
<p>Hello!<br>
Then I try to solve linear equation like</p>
<pre><code>import cdb.core.manip as man
expr:= G - 2*F * X =0;
man.isolate(expr, $F$);
</code></pre>
<p>I get something like that<br>
<img src="https://sun9-1.userapi.com/impg/N5JkB_247NPa-RQCJFUDIjZ5Dm-ZtX93oyzBjA/tEej2DE_67o.jpg?size=436x235&quality=96&sign=6f3b1c2cead815519843d9fb7cf73483&type=album" alt="enter image description here"></p>
<p>I think it's not ok. It's a bug, or I'm doing something wrong?</p>
Bug reportshttp://cadabra.science/qa/2007/bug-with-isolate-functionTue, 01 Jun 2021 16:08:34 +0000Answered: Failure of running cadabra on windows.
http://cadabra.science/qa/1259/failure-of-running-cadabra-on-windows?show=1998#a1998
<p>Windows is no longer supported, I do not have the time for it anymore. Volunteers welcome to bring this back to life.</p>
Bug reportshttp://cadabra.science/qa/1259/failure-of-running-cadabra-on-windows?show=1998#a1998Tue, 13 Apr 2021 16:31:26 +0000Answered: Problem with combine
http://cadabra.science/qa/1834/problem-with-combine?show=1992#a1992
<p>I can confirm the behaviour of your code. </p>
<p><strong>Just a comment:</strong> It seems that <code>combine</code> privilege the position of the indices (lower like a covariant and upper like contravariant) over the <code>property</code> of the objects. </p>
<p><img src="https://ibb.co/BVCM67P" alt="cadabra_combine"></p>
Bug reportshttp://cadabra.science/qa/1834/problem-with-combine?show=1992#a1992Wed, 07 Apr 2021 10:35:56 +0000Answered: Canonicalizing with independent indices mixes up raised/lowered
http://cadabra.science/qa/1968/canonicalizing-independent-indices-mixes-raised-lowered?show=1991#a1991
<p>The algorithm does funny things if you declare indices <code>independent</code> but then not stick to Einstein conventions of having only one upper and one lower index. In your example, the <code>b</code> index appears as subscript twice. It tried to keep those two <code>b</code>s as lower indices, but as a result, it had to raise the index on <code>X</code>.</p>
<p>I would classifyl this as undefined behaviour, though perhaps a warning would have been appropriate. I don't think I will spend time on 'fixing' this, especially because it isn't even clear what the right fix should do.</p>
Bug reportshttp://cadabra.science/qa/1968/canonicalizing-independent-indices-mixes-raised-lowered?show=1991#a1991Sun, 04 Apr 2021 20:41:36 +0000Answered: Maximum column width for input
http://cadabra.science/qa/1958/maximum-column-width-for-input?show=1964#a1964
<p>Can you run <code>cadabra2-gtk</code> from inside <code>gdb</code> and get me a backtrace when this happens? I suspect it crashes in gtk itself.</p>
Bug reportshttp://cadabra.science/qa/1958/maximum-column-width-for-input?show=1964#a1964Sat, 06 Mar 2021 21:31:06 +0000Answered: Bug in expand_delta
http://cadabra.science/qa/1952/bug-in-expand_delta?show=1955#a1955
<p>This only seems to happen when the delta appears at the very top of the expression (so not in a product or sum). Now fixed on github, thanks for reporting.</p>
Bug reportshttp://cadabra.science/qa/1952/bug-in-expand_delta?show=1955#a1955Wed, 03 Mar 2021 21:28:26 +0000Answered: Evaluate function kernel crash
http://cadabra.science/qa/1926/evaluate-function-kernel-crash?show=1936#a1936
<p>You have defined both <code>x</code> and <code>y</code> as <code>Indices</code>, but also as <code>Coordinate</code>. This makes the definition of that <code>box</code> ambiguous,</p>
<pre><code>box := h^{a b} (\partial_{a b}{p} - \Gamma^{y}_{a b}\partial_{y}{p});
</code></pre>
<p>as it contains a <code>y</code> which could either be an index or a fixed index value. The checks in Cadabra to catch this kind of problem are not strong enough to prevent the crash.</p>
<p>If you drop <code>x</code> and <code>y</code> from your index set and write e.g. <code>c</code> in the definition of <code>box</code> all seems well.</p>
<p>Also note that you really need a space (or star) between <code>h^{a b}</code> and the bracket that follows, otherwise it gets interpreted as <code>h^{a b}</code> with an argument, not as two factors.</p>
Bug reportshttp://cadabra.science/qa/1926/evaluate-function-kernel-crash?show=1936#a1936Fri, 12 Feb 2021 21:08:56 +0000Answered: Meld function
http://cadabra.science/qa/1888/meld-function?show=1914#a1914
<p>This has been fixed in 2.3.6.4.</p>
Bug reportshttp://cadabra.science/qa/1888/meld-function?show=1914#a1914Sat, 23 Jan 2021 21:49:05 +0000Answered: Coordinate indices mess up diagonal tensor?
http://cadabra.science/qa/1911/coordinate-indices-mess-up-diagonal-tensor?show=1912#a1912
<p>Cadabra used to only handle <code>Diagonal</code> with numerical indices. I have just pushed a fix (2.3.6.5) which also handles symbolic indices like in your first example.</p>
Bug reportshttp://cadabra.science/qa/1911/coordinate-indices-mess-up-diagonal-tensor?show=1912#a1912Sat, 23 Jan 2021 21:45:19 +0000Answered: Tab for autocomplete crashes Cadabra
http://cadabra.science/qa/1909/tab-for-autocomplete-crashes-cadabra?show=1910#a1910
<p>This was fixed in 2.3.6 but I forgot to generate new packages; now available.</p>
Bug reportshttp://cadabra.science/qa/1909/tab-for-autocomplete-crashes-cadabra?show=1910#a1910Sun, 17 Jan 2021 12:46:50 +0000Answered: Only one window can be opened
http://cadabra.science/qa/1868/only-one-window-can-be-opened?show=1869#a1869
<p>You should be able to start <code>cadabra2-gtk</code> multiple times; that certainly works on Ubuntu 18.04 on bare metal. Using <code>File / New</code> is not intended to open an extra window (essentially, every instance of <code>cadabra2-gtk</code> has one kernel, and if you want more than one kernel you just start a new instance).</p>
<p>Or are you talking about the Jupyter kernel?</p>
Bug reportshttp://cadabra.science/qa/1868/only-one-window-can-be-opened?show=1869#a1869Sun, 13 Dec 2020 11:39:49 +0000Question 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: 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 +0000