Cadabra Q&A - Recent questions and answers in Bug reports
http://cadabra.science/qa/qa/bug-reports
Powered by Question2AnswerAnswered: bugs with sort_product&meld
http://cadabra.science/qa/1647/bugs-with-sort_product%26meld?show=1652#a1652
<p>It seems you're interested in manipulating the expression:<br>
$$\epsilon^{\mu \nu \rho \sigma} tr\left(a^{\mu} a^{\nu} b^{\rho} b^{\sigma}\right)+\epsilon^{\mu \nu \rho \sigma} tr\left(a^{\mu} b^{\nu} b^{\rho} a^{\sigma}\right)$$</p>
<p>But you didn't define the trace</p>
<pre><code>tr{#}::Trace.
</code></pre>
<p>Then</p>
<pre><code>{\mu,\nu,\rho,\sigma}::Indices(vector).
\epsilon^{\mu\nu\rho\sigma}::EpsilonTensor.
{a^{\mu},b^{\mu}}::NonCommuting.
{a^{\mu},b^{\mu}}::SelfNonCommuting.
tr{#}::Trace.
ts:=\epsilon^{\mu\nu\rho\sigma} tr{a^{\mu}a^{\nu}b^{\rho}b^{\sigma}}
+\epsilon^{\mu\nu\rho\sigma} tr{a^{\mu}b^{\nu}b^{\rho}a^{\sigma}};
meld(_);
</code></pre>
<p>returns<br>
$$2\epsilon^{\mu \nu \rho \sigma} tr\left(a^{\mu} a^{\nu} b^{\rho} b^{\sigma}\right)$$</p>
Bug reportshttp://cadabra.science/qa/1647/bugs-with-sort_product%26meld?show=1652#a1652Tue, 26 May 2020 09:48:05 +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 +0000Highlighted text almost invisible.
http://cadabra.science/qa/1552/highlighted-text-almost-invisible
<p>Hi Kasper. (Remember me? :-)</p>
<p>I just installed Cadabra2 on openSUSE LEAP 15.1 but immediately encountered the following bug (or is it a feature?).</p>
<p>When attempting to highlight some text (intending to copy or delete it, or whatever), the text seemed to just disappear instead of being highlighted. After a while I realized it's because the highlighted text is actually white on a pale grey background, making it almost invisible.</p>
<p>I tried playing with the "highlight syntax" options, but failed to find anything applicable.<br>
Is there some other preferences setting elsewhere that would fix this? If not, then... how?</p>
<p>Kind regards.</p>
Bug reportshttp://cadabra.science/qa/1552/highlighted-text-almost-invisibleFri, 31 Jan 2020 09:01:21 +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 +0000Answered: IPython notebooks example not working
http://cadabra.science/qa/963/ipython-notebooks-example-not-working?show=964#a964
<p>The <code>param</code> argument should have been optional, but at some point we stripped out the default value for that argument, and since the Cadabra preparser fills it in automatically, no-one noticed. </p>
<p>Until this is fixed, you can use</p>
<pre><code>Symmetric(ex, Ex(''))
</code></pre>
<p>in place of your last line (that is, set <code>param</code> equal to an empty expression).</p>
Bug reportshttp://cadabra.science/qa/963/ipython-notebooks-example-not-working?show=964#a964Thu, 25 Oct 2018 20:36:42 +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 +0000Answered: space dependent inverse
http://cadabra.science/qa/747/space-dependent-inverse?show=748#a748
<p>That is essentially because I used to write a lot of </p>
<pre><code>1/a/b/c
</code></pre>
<p>type of things, and those then at first instance become</p>
<pre><code>\frac{1}{a}{b}{c}
</code></pre>
<p>In general, the parser does not know about the meaning of operators, and so it cannot know whether <code>\frac</code> only takes 2 arguments, or more. </p>
Bug reportshttp://cadabra.science/qa/747/space-dependent-inverse?show=748#a748Mon, 21 May 2018 08:32:35 +0000Answered: Run time error with young_project_tensor
http://cadabra.science/qa/730/run-time-error-with-young_project_tensor?show=732#a732
<p><code>impose_bianchi</code> is superfluous given the Young tableaux algorithms (but of course it should be removed from that manual page). There is a known bug in <code>young_project_tensor</code> with placing of indices (up/down), which is what leads to the exception. For the time being, the best way out is simply to not use <code>canonicalise</code> here, and use <code>young_project_product</code> (which is more efficient and does not crash).</p>
Bug reportshttp://cadabra.science/qa/730/run-time-error-with-young_project_tensor?show=732#a732Thu, 10 May 2018 12:23:37 +0000Answered: take_match and factor_in "do not commute"
http://cadabra.science/qa/718/take_match-and-factor_in-do-not-commute?show=719#a719
<p>It does the right thing with the current version on github. If that's what you were using, please provide a full example which shows the problem (it may be due to e.g. some property declarations for some of the symbols in the expression).</p>
Bug reportshttp://cadabra.science/qa/718/take_match-and-factor_in-do-not-commute?show=719#a719Fri, 04 May 2018 13:11:50 +0000Answered: Odd interaction between ::Weight and ::LaTeXForm
http://cadabra.science/qa/707/odd-interaction-between-weight-and-latexform?show=710#a710
<p>Well spotted. It has nothing to do with <code>LaTeXForm</code> per se, but rather with the fact that a property was defined for <code>B{#}</code>, and lookup of labelled properties (<code>Weight</code> is a labelled property, with in your case <code>eps</code> being the label) containing a bug. </p>
<p>Now fixed in github. Thanks.</p>
Bug reportshttp://cadabra.science/qa/707/odd-interaction-between-weight-and-latexform?show=710#a710Wed, 02 May 2018 18:06:51 +0000Answered: simple bug in @(foo)-@(bah)
http://cadabra.science/qa/674/simple-bug-in-%40-foo-%40-bah?show=675#a675
<p>Now fixed in github.</p>
Bug reportshttp://cadabra.science/qa/674/simple-bug-in-%40-foo-%40-bah?show=675#a675Mon, 16 Apr 2018 12:48:18 +0000Answered: possible issue with "combine" algorithm?
http://cadabra.science/qa/667/possible-issue-with-combine-algorithm?show=670#a670
<p>How was Cadabra supposed to know that this is not what you intended?</p>
Bug reportshttp://cadabra.science/qa/667/possible-issue-with-combine-algorithm?show=670#a670Wed, 11 Apr 2018 08:33:50 +0000Answered: Cadabra 2.2.0 quits without warning on ubuntu 16.04
http://cadabra.science/qa/662/cadabra-2-2-0-quits-without-warning-on-ubuntu-16-04?show=664#a664
<p>I'm assuming this is with the binary package? Can you run <code>cadabra2-gtk</code> from the command line and let me know if that spits out any error?</p>
Bug reportshttp://cadabra.science/qa/662/cadabra-2-2-0-quits-without-warning-on-ubuntu-16-04?show=664#a664Tue, 10 Apr 2018 09:03:39 +0000Answered: LaTeXForm is not working in ubuntu 16.04
http://cadabra.science/qa/621/latexform-is-not-working-in-ubuntu-16-04?show=625#a625
<p>Use a period '.' to end that line, so</p>
<pre><code>\del{#}::LaTeXForm("\partial").
</code></pre>
<p>(I really should fix this; it essentially cannot know how to print <code>\del</code> until it has processed this line, but things get executed in opposite order).</p>
Bug reportshttp://cadabra.science/qa/621/latexform-is-not-working-in-ubuntu-16-04?show=625#a625Wed, 04 Apr 2018 08:47:56 +0000