Cadabra Q&A - Recent questions in Bug reports

The mystery of meld

Wed, 19 Nov 2025 15:20:16 +0000

Hello,

Thanks a lot for Cadabra. This is very useful! But I found strange behavior of the algorithm meld.

First, a bug related to prefactor. Consider:

ex:= B^{i} B^{j} S^{m n} D_{i j} D_{m n} + B^{i} B^{j} S^{m n} D_{m n} D_{i j};
S^{i j}::Symmetric;
D_{i j}::Symmetric;

And then if I evaluate meld for the ex, I get prefactor 3/2 instead of 2.

Moreover, if I do not specify the symmetries of S^{i j} and D_{i j} separately, then the algorithm works correctly.

Second, an incorrect interpretation of an index convolution:

\partial{#}::PartialDerivative.
ex1:=  G^{m j} \partial_{i}{A} \partial_{m}{F_{j}} +  G^{m j} \partial_{m}{A} \partial_{i}{F_{j}};
ex2:= D^{m n} \partial_{i}{C} \partial_{m}{Q_{n j}} + D^{m n} \partial_{m}{C} \partial_{i}{Q_{n j}};
meld(ex1);
meld(ex2);

Meld interprets expressions as two identical terms in both cases, although I did not specify any symmetries of objects.

Thanks, Maksim

Strange behavior young_project_product with zoom

Wed, 22 Oct 2025 16:56:49 +0000

Hello, I found a peculiar effect of Young's projection when applied to part of an expression after using zoom. For example:

{a,b,c,d,f,e, m,n,k,l,q,r,s,t,u,v,w,x,y,z,m#, n#}::Indices(values={0..3}, position=independent);

\nabla{#}::Derivative.
h_{m? n?}::Metric.
h^{m? n?}::InverseMetric.
h_{m? n?}::Symmetric.
h^{m? n?}::Symmetric.
F_{a? b?}::AntiSymmetric.
F^{a? b?}::AntiSymmetric.
\nabla_{a}{F_{b c}}::TableauSymmetry(shape={2,1}, indices={0,1,2});
\nabla_{a}{\nabla_{b}{p}}::Symmetric;

and I have some long expression:

expr := 1/2 F_{a b} F_{c d} R \nabla_{e}(p) \nabla_{f}(p) h^{a c} h^{b e} h^{d f}
-F_{a b} F_{c d} \nabla_{e}(\nabla_{f}(p)) \nabla_{m}(\nabla_{n}(p)) h^{a c} h^{b e} h^{d f} h^{m n} 
+ F_{a b} F_{c d} \nabla_{e}(\nabla_{f}(p)) \nabla_{m}(\nabla_{n}(p)) h^{a c} h^{b e} h^{d m} h^{f n}
-F_{a b} F_{c d} R_{e f} \nabla_{m}(p) \nabla_{n}(p) h^{a e} h^{b m} h^{c f} h^{d n}
-2F_{a b} \nabla_{c}(F_{d e}) \nabla_{f}(\nabla_{m}(p)) \nabla_{n}(p) h^{a f} h^{b n} h^{c d} h^{e m} 
+ F_{a b} F_{c d} \nabla_{e}(\nabla_{f}(p)) \nabla_{m}(\nabla_{n}(p)) h^{a e} h^{b m} h^{c f} h^{d n} 
+ F_{a b} \nabla_{c}(F_{d e}) \nabla_{f}(\nabla_{m}(p)) \nabla_{n}(p) h^{a c} h^{b d} h^{e f} h^{m n};

And I want to simplify terms with \nabla{a}{F{b c}}:

zoom(expr, $Q?? \nabla_{a}{F_{b c}}$);
expr2 = take_match($@[expr2]$, $Q?? \nabla_{a}{F_{b c}}$);
canonicalise(young_project_product(expr2));

For expr I get - 4/3 F_{a b} \nabla_{c}(F_{d e}) \nabla_{f}(\nabla_{m}(p)) \nabla_{n}(p) h^{a f} h^{b n} h^{c d} h^{e m} but for expr2 I get

- 8/9 F_{a b} \nabla_{c}(F_{d e}) \nabla_{f}(\nabla_{m}(p)) \nabla_{n}(p) h^{a f} h^{b n} h^{c d} h^{e m}

vary behaves in an odd way

Mon, 06 Oct 2025 10:29:17 +0000

Here is a short example of what I found weird:

ex:= 2(r)**(-2) - B(r); vary(_, $B(r) -> \delta{B}$);

from which I get

2 {r}^{-2} - \delta\left(B\left(r\right)\right)

I tought that it was due to my older version of cadabra, but I just installed the latest version and the answer is the same. If I had in the first term just r, without an exponent, the answer woud be correct.

Thanks, Andrei

plot example on p. 51 of The Cadabra Book require range

Mon, 21 Jul 2025 15:05:29 +0000

A note on p. 52 tell the range is optional. But the example don't work without it.

Also, increasing the number of samples have no effect.

plot(sol, range_=($tau$, 0, 10),samples=5000, title="Damped coupled oscillators");

\dot command not displayed correctly

Mon, 14 Jul 2025 23:37:35 +0000

I'm trying to reproduce the first example on page 37 of The Cadabra Book.

I tried in cadabra2-gtk and jupyter kernel but I got a strange result. Instead of a dot in between I got a comma and a dot over.

In cadabra2-cli this is the output : \dot(A , D) \dot(B , C) which when entered in notebook give me the same wrong result.

Here is the code I'm running :


> {\mu, \nu, \rho, \sigma}::Indices(vector);

> ex:= A\\_\\{\mu\\} B\\_\\{\nu\\} C\\_\\{\nu\\} D\\_\\{\mu\\};

> substitute\(\_\, $A?\_\{\rho\} B?\_\{\rho\} \-\> \dot\{A?\}\{B?\}$\, repeat=True\);

Regex not working

Sat, 12 Jul 2025 21:06:37 +0000

I tried the example on page 37 of the Cadabra Book

ex:= A + B3 + C7;
substitute(_, $A + M? + N? | \regex{M?}{"[A-Z]7"} -> \sin(M? N?\)/N?$);

In jupyter I got this error :

Traceback (most recent call last):
  File "/usr/local/lib/python3.12/dist-packages/cadabra2_jupyter/kernel.py", line 57, in do_execute
    self._execute_python(pycode)
  File "/usr/local/lib/python3.12/dist-packages/cadabra2_jupyter/kernel.py", line 111, in _execute_python
    self._sandbox_context(pycode)
  File "/usr/local/lib/python3.12/dist-packages/cadabra2_jupyter/context.py", line 51, in __call__
    exec(code, self._sandbox)
  File "<string>", line 2
    substitute(_, ""Ex(r'''A + M? + N? | \regex{M?}{"[A-Z]7"} -> \sin(M? N?)/N?''', False)); display(_)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SyntaxError: invalid syntax. Perhaps you forgot a comma?

The command line simply crash :

> ex:= A + B3 + C7; A + B3 + C7 > substitute(_\, $A + M? + N? | \regex{M?}{"[A-Z]7"} -> \sin(M? N?)/N?$);

Terminated by user interrupt.

I'm using Cadabra 2.5.12

execution problems

Tue, 08 Apr 2025 09:22:21 +0000

Hi Kasper, Thanks for the quick update. I've tried to run the latest version of cadabra2 but I get this run time error

Cadabra 2.5.11 (build 3796.22211b1d23 dated 2025-04-08)
Copyright (C) 2001-2025  Kasper Peeters <info@cadabra.science>
Traceback (most recent call last):
  File "<input>", line 1, in <module>
FileNotFoundError: [Errno 2] No such file or directory: '/Users/leo/tmp2//opt/homebrew/opt/python@3.13/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages/cadabra2_defaults.py'

I had no problems compiling the code. Here is what I did

git clone https://github.com/kpeeters/cadabra2
cd cadabra2/
git checkout devel
cmake -DENABLE_MATHEMATICA=OFF -DCMAKE_INSTALL_PREFIX:PATH=/Users/leo/tmp2/ ..
mkdir build
make install

export PATH=/Users/leo/tmp2/bin/:$PATH

I chose to install to ~/tmp2 just for testing. I've done this mant times before and b=nvere had this problem. Any thoughts? Cheers, Leo ps. Santa was very busy over Xmas so no surprise that a few gremlins got into the system :)

cadabra2python seg fault

Mon, 07 Apr 2025 04:21:01 +0000

Hi Kasper,

Just a short note. Running cadabra2python on any non-empty file produces a seg fault.

Cheers, Leo

simple substitute hits wrong target

Mon, 07 Apr 2025 04:09:04 +0000

Greetings,

Here is an interesting case.

This short code

tmp := 2 A B + 3 B C + 4 C D.
substitute (tmp, $A? -> \theta A?$)
collect_factors (tmp)

returns

tmp := 2 \theta^2 A B + 3 \theta^2 B C + 4 \theta^2 C D

while

tmp := 2 A B C + 3 B C D + 4 C D E.
substitute (tmp, $A? -> \theta A?$)
collect_factors (tmp)

returns

tmp := 2 \theta^3 A B C + 3 \theta^3 B C D + 4 \theta^3 C D E

Okay, so far , so good.

However, this code

tmp := 2 A + 3 B + 4 C.
substitute (tmp, $A? -> \theta A?$)

returns

tmp := 4 \theta A + 9 \theta B + 16 \theta C

Notice that the integer coefficients have been squared! That's not correct.

Quite interesting, n'est pas?

Cheers, Leo

curly-braces and lost indices

Mon, 07 Apr 2025 04:06:29 +0000

Greetings,

This short example

{a,b,c,d,e,f#}::Indices.

foo := A^{a} A^{b} g_{a b}.
substitute (foo,$A^{a}->B^{a}$)

does what you'd expect. It returns

foo := B^{a} B^{b} g_{a b}

But the following code

foo := A^{a} A^{b} g_{a b}.
substitute (foo,$A^{a}->{B}^{a}$)

returns

foo := B B g_{a b}

Now that seems wrong to me.

Any thoughts?

My guess is that the curly-braces around B in the second assignment disconnects B from the following indices. Those indices are orphaned and are thus lost in the substitution.

The simple answer is -- Don't use unnecessary curly-braces.

Cheers, Leo

c++lib fails to compile

Tue, 10 Dec 2024 16:24:56 +0000

On my system, c++lib fails to compile properly. I needed to add the line ${CMAKE_CURRENT_SOURCE_DIR}/../core/properties/DerivativeOp.cc and also explicitly add the python include path, i.e. include_directories(/usr/include/python3.10)

I'm not sending a fix because my Python include is obviously system-dependent; probably there is a correct way to do this.

Kronecker delta wrong output in 2D

Tue, 10 Dec 2024 15:45:07 +0000

I'm basically following the eliminate_metric example from the website:

{m, n, p, q, r}::Indices(vector, position=fixed).
{m, n, p, q, r}::Integer(0..9).
g_{m n}::Metric.
g^{m n}::InverseMetric.
g_{m}^{n}::KroneckerDelta.
g^{m}_{n}::KroneckerDelta.
ex:=g_{m p} g^{p m};
eliminate_metric(_);
eliminate_kronecker(_);

but I'm working with doubled coordinates, meaning that my coordinates go from 0 to 2D-1. Therefore, if I change the corresponding part to

{m, n, p, q, r}::Integer(0..2*D-1).

the output is, against all odds and common sense, D. You may be thinking that it won't work with such terms, but I've stumbled upon a bizzare bug; here are some examples of different inputs and outputs:

{m, n, p, q, r}::Integer(0..D).

D+1

{m, n, p, q, r}::Integer(0..2 D + 1).

2D+2

{m, n, p, q, r}::Integer(0..3D-1).

D

{m, n, p, q, r}::Integer(0..2*(D-1)).

2D-1

It seems that when the dimensionality of Kronecker is a multiple of D, it stops working properly. Any ideas on why this is happening? What can be done to fix it?

Canonicalise Kernel crash

Mon, 02 Dec 2024 19:13:19 +0000

Hello everyone.

I am currently calculating a large expression in coordinates and using the canonicalise function to order partial derivatives without using sympy bridge. And I found that an expression of this kind causes the kernel to crash when executing the canonicalise function.

{t, x, y, z, u}::Coordinate.
{a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,v,w#}::Indices(full, values={t,x,y,z,u}, position=independent).
\partial{#}::PartialDerivative.

p::Depends(t).
W_{m?}::Depends(t,x,y,z).

test := Dh \partial_{x}(W_{x}) \partial_{y}(W_{y}) (\partial_{t}(p))**2 (\partial_{t t}(p))**2 (a)**(-4) a2X;

canonicalise(test);

I'm using Cadabra 2.5.8 (build 3421.a815a66da2 dated 2024-10-25) on Ubuntu 22.04.5

update:

I also noticed that if I write

canonicalise($\partial_{x}{W_{x}} \partial_{y}{W_{y} (\partial_{t}{p})**2 (\partial_{t t}{p})$);

I get the following error:

Traceback (most recent call last): File "/usr/local/lib/python3.10/dist-packages/cadabra2_jupyter/kernel.py", line 56, in do_execute self._execute_python(pycode) File "/usr/local/lib/python3.10/dist-packages/cadabra2_jupyter/kernel.py", line 110, in _execute_python self._sandbox_context(pycode) File "/usr/local/lib/python3.10/dist-packages/cadabra2_jupyter/context.py", line 51, in __call__ exec(code, self._sandbox) File "<string>", line 1, in <module> IndexError: vector::_M_range_check: __n (which is 3) >= this->size() (which is 3)

and If if I replace \partial_{t t}{p} with (\partial_{t t}{p})**2 , the kernel dies

canonicalise($\partial_{x}{W_{x}} \partial_{y}{W_{y} (\partial_{t}{p})**2 (\partial_{t t}{p})**2$);

collect_factors / simplify with AntiCommuting objects

Thu, 21 Nov 2024 20:35:21 +0000

This is a weird case and perhaps unlikely to be encountered in normal use, but I'm noting it here.

Consider:

{A,X}::AntiCommuting.
ex := X A X;
sort_product(ex)
collect_factors(ex);

The above produces a negative sign as one might suspect. However:

{A,X}::AntiCommuting.
ex := X A X;
collect_factors(ex);

The above does not. Nor does this:

{A,X}::AntiCommuting.
ex := X A X;
simplify(ex);

sympy(?) errors parsing nested derivatives?

Tue, 01 Oct 2024 06:47:52 +0000

As a warmup exercise before what I really want to do, I'm trying to compute the Laplacian operator in 2D plane polar coordinates. I do this by expressing \partial_{x} and \partial_{y} in terms of \partial_{r} and \partial_{\theta}, and then compute the sum of the squares of these operators.

Of course, operator expressions like \partial_x^2 are quickly regurgitated, so I'm trying the following alternative:

Px:= { px = \cos{\phi} \partial_{r}{f} 
     - \frac{\sin\phi}{r} \partial_{\phi}{f} } ;

Pxx:= { pxx = \cos{\phi} \partial_{r}{px} 
     - \frac{\sin\phi}{r} \partial_{\phi}{px}};

substitute(Pxx,Px);

evaluate(Pxx);

Cadabra gets the substitution correct, but evaluate() gives what looks like a sympy error:

{\color{red}{\begin{verbatim}TypeError: bad operand type for unary -: 'FunctionClass'

{\color{red}{\begin{verbatim}TypeError: bad operand type for unary -: 'FunctionClass'

TypeError: bad operand type for unary -: 'FunctionClass'
At:
  Notebook Cell (Line 0): 
  /tmp/.mount_CadabrIqWtS3/usr/lib/python3.8/dist-packages/sympy/parsing/sympy_parser.py(909): eval_expr
  /tmp/.mount_CadabrIqWtS3/usr/lib/python3.8/dist-packages/sympy/parsing/sympy_parser.py(1090): parse_expr
  Notebook Cell (Line 0):

Btw, I was unable to copy and paste these red error messages out of cadabra easily by the usual highlight-and-click methods. I had to click Edit->Copy and then paste it over here, but it still omitted the first line above (which I ended up typing in by hand).

\partial_\theta causes infinite loop(?) in server

Mon, 30 Sep 2024 08:53:35 +0000

As in my previous questions, I have

f::Depends(r,\theta,\phi, vr, vtheta, vphi);

The following works ok:

exfr:= { fr = \partial_r{f} };

but

exfth:= { fth = \partial_\theta{f} };

makes the server go into some kind of infinite loop (i.e., consumes ~ 99% CPU). So I have to restart the kernel.

Similarly,

exfvth:= { fvth = \partial_vtheta{f} };

causes infinite looping in server.

Enclosing the \theta or vtheta in braces works ok, i.e.,

exfth:= { fth = \partial_{\theta}{f} };

Gtk error messages on startup.

Mon, 30 Sep 2024 03:02:33 +0000

When I run Cadabra_2.5.6_x86_64.AppImage from a terminal I get the following error messages:

Gtk-Message: 12:54:41.239: Failed to load module "canberra-gtk-module" Gtk-Message: 12:54:41.264: Failed to load module "window-decorations-gtk-module" Gtk-Message: 12:54:41.264: Failed to load module "colorreload-gtk-module"

but it seems to keep running, although with fonts that are not my usual choice.

Also, (not necessarily at startup) I get messages on the terminal saying

cadabra-client: connection to server on port 33555 failed

Cycle freeze

Thu, 26 Sep 2024 15:31:48 +0000

Hi!

I often use the following function with a converge loop to simplify expressions:

def tidy (expr):
   converge(expr):
       distribute(expr)
       product_rule(expr)
       sort_product(expr)
       collect_factors(expr)
   return expr

But after today's update of cadabra to the latest version, this loop became infinite. Not for all expressions, but, for example, for this one

{a,b,c,d,f,g,m,n,k,q,r,s,t,u,v,w,x,y,z,m#}::Indices(subspace, position=independent, parent=full);
\partial{#}::PartialDerivative.


expr := ((\phi)**(-2) + A_{a} h^{a b} A_{b}) (\partial_{n}((\phi)**2 A_{m}) + \partial_{m}((\phi)**2 A_{n}));

Also, the problem only occurs if I use this function from a external file

import functions as fun

so, if I use

fun.tidy(expr)

Loop is infinite.

A bug of Accent

Thu, 01 Aug 2024 04:36:53 +0000

For example,

{a,b}::Indices(vector).
\delta{#}::Accent.
ex:=\delta{A^{a b}+B^{a b}}

Result is not right.

LaTeXForm fails in version 2.5.2

Mon, 17 Jun 2024 22:50:17 +0000

Greetings,

This simple statement

Dx{#}::LaTeXForm{"Dx"}.

raises a syntax error

SyntaxError: '{' was never closed

I'm running Cadabra version 2.5.2. build 3043.2a1d62739a.

Also, this version of Cadabra compiles fine under MacOS Sonoma 14.5.

Cheers, Leo

substitute gives incorrect value on scalar expression

Mon, 17 Jun 2024 22:25:46 +0000

Greetings, I'm trying to use the substitute algorithm to set the value of a scalar expression but I'm getting some very odd results. In the following examples I set a variable s to be 1 and the expected result should be zero. But in the first case I get 2. This problem only seems to arise for the single choice of s=1. Cheers, Leo

# ----------------------------------------------------
# fails, should return 0

foo := s - s**3;

substitute (foo, $s = 1$);

# ----------------------------------------------------
# success

foo := s - s*s*s;

substitute (foo, $s = 1$);

# ----------------------------------------------------
# success

foo := s**3 - s;

substitute (foo, $s = 1$);

# ----------------------------------------------------
# success

foo := s - s**3;

substitute (foo, $s = 2$);

# ----------------------------------------------------
# success

foo := s - s**3;

substitute (foo, $s = 1/2$);

location of bracket blocks distribute

Tue, 11 Jun 2024 05:46:21 +0000

Hi Folks,

Here are two instances of the distribute algorithm. Only the first gives the expected result. The only difference in the code is where the opening bracket is placed.

# ----------------------------------------------
# this works as expected

foo := A (
       B + C);

distribute (foo);

# ----------------------------------------------
# this fails to apply the "distribute" algorithm

bah := A
       (B + C);

distribute (bah);

Cheers, Leo

leading scalar expression blocks canonicalise

Tue, 11 Jun 2024 05:35:33 +0000

Hi Troops,

Here is s short Cadabra code

{a,b,c,d,e,f#}::Indices(position=independent).

R_{a b c d}::RiemannTensor.

# this should give zero
foo := (1+s) R_{a b c d} p^{a} p^{b} p^{c} p^{d}.
canonicalise (foo);

# this gives the expected result
bah := s R_{a b c d} p^{a} p^{b} p^{c} p^{d}.
canonicalise (bah);

There are two ouputs foo and bah. Both should be zero (beacuse of the symmetries of the Riemann tensor). But only bah is correctly given as zero. This seems like a bug to me.

Cheers, Leo

imp package was removed from python 3.12

Sat, 18 May 2024 18:30:19 +0000

Hi! I've find out that imp package was removed from python 3.12, and I can't import cdb.core.manip any more because the following error appears: ModuleNotFoundError: No module named 'imp' imp module is deprecated in favour of importlib.

bug of unwrap

Tue, 23 Apr 2024 07:46:59 +0000

For example,

u::Coordinate.
f::Depends(u).
\partial{#}::PartialDerivative.
ex:=\partial_u{u f};
product_rule(_);
unwrap(_);

where $\partial_u(u)=0$, there seems to be a bug here.

bug of stop evaluation

Sun, 21 Apr 2024 11:50:54 +0000

When I use stop evaluation to stop evaluation, but it never works.

bug of function keep_weight

Wed, 17 Apr 2024 09:38:20 +0000

The following code:

{u,v}::Weight(label=field,value=1);
ex:=(u v)**{1/2};
keep_weight(_,$field=1$);

I get the wrong result $0$, while the following code

{u,v}::Weight(label=field,value=1);
ex:=(u v)**{1/2}+u u;
keep_weight(_,$field=1$);

work fine. It seems a bug.

The output is lost in WSL2

Fri, 12 Apr 2024 22:41:16 +0000

In WSL2, I often cannot find where the output is. But sometimes it works. I don't know what happened. I have followed the tutorial.

unwrap of partial derivatives

Tue, 26 Mar 2024 14:37:48 +0000

Hi!

I have a problem with the unwrap() function. When I apply it to multiple partial derivatives, it doesn't always work, for example:

{t, x, y, z}::Coordinate.
\partial{#}::PartialDerivative.
a::Depends(t).

unwrap($\partial_{t t x}{a}$);

I was thinking that partial derivatives by definition in Cadabra commute, in which case, unwrap() should give zero.

meld returns zero where it shouldn't?

Mon, 05 Feb 2024 01:46:56 +0000

I've been trying to make use of meld and I'm finding some potential bugs.

Consider:

X_{a b c}_{d}::TableauSymmetry(shape=(2,1,1), indices=(0,3,1,2)).

This generates a tensor X_{a b c}_{d} which is antisymmetric in abc but with the totally antisymmetric part in abcd removed.

If I evaluate meld on the following three quantities:

meld($ X_{a b d d}$);
meld($ X_{a d b d}$);
meld($ X_{d a b d}$);

I get 0 for the first two and X_{d a b d} for the last. Of course, they should all be nonzero. (For the last, if I then call canonicalise and meld again, I get 0 because it rearranges the indices into the first case.)

Similar behavior occurs with the simpler tensor

X_{a b}_{c}::TableauSymmetry(shape=(2,1), indices=(0,2,1)).

where

meld($ X_{a d d}$);
meld($ X_{d a d}$);

gives 0 for the first but X_{d a d} for the second.

Perhaps I am doing something stupid but I don't quite see what it is.

Operations with fractional powers of negative numbers

Tue, 16 Jan 2024 14:02:49 +0000

Hi! When I try to work with expressions like (-X)^{1/2} or any other fractional degree the expand_power and collect_powers commands cause a kernel crash, for example:

collect_factors($(-X)**{-5/2} X$);

I know that without defining the X sign beforehand, I can't shorten this expression, but kernel crush is too much. That's why I have another question for this bugreport, is it possible to define the sign of X in advance to work with such expressions correctly?

Interaction between 'canonicalise' and vector spinors

Thu, 11 Jan 2024 16:01:22 +0000

I'm trying to do some computations involving bilinears of vector spinors \psi_a and it seems that using canonicalise eliminates terms which shouldn't be zero.

In particular this applies to terms like \psi^a \bar{\psi^b}, as showcased by the following minimal example:

# Setup properties needed
{a, b}::Indices.

\psi^a::SelfAntiCommuting.
{\psi^a, \rho, \chi}::Spinor(dimension=10).
{\psi^a, \rho, \chi}::AntiCommuting.

\bar{#}::DiracBar.

A{#}::AntiSymmetric.

# Non-zero canonicalisation
ex := A_{a b}  \bar{\psi^b} \rho \bar{\psi^a} \chi.
canonicalise(_);

returns -A_{a b} \bar{\psi^a} \rho \bar{\psi^b} \chi as expected, while

# Zero canonicalisation
ex := A_{a b} \bar{\rho} \psi^b\bar{\psi^a} \chi.
canonicalise(_);

returns 0, even though it should not be zero.

Stripping everything else away, also the following canonicalises to zero, even though it should not:

# Zero canonicalisation
ex := A_{a b} \psi^b\bar{\psi^a}.
canonicalise(_);

Did I forget something in the setup of my spinors, or is that a genuine error in canonicalise?

remove_zero_components and components_to_subrule fail with AttributeError

Mon, 08 Jan 2024 09:05:45 +0000

The following two snippets of code are taken from the manual. They both now fail with AttributeError: 'cadabra2.ExNode' object has no attribute 'top'.

Am I doing something wrong?

This is using Cadabra2 2.4.5.2 Ubuntu 22.04

Snippet 1:

from cdb.core.component import *

{x, y, z}::Coordinate.
{i, j}::Indices(values={x, y, z}, position=fixed).
ex := a_{i}a_{j};
evaluate(ex, $a_{x} = k, a_{y} = l, a_{z} = m$)
substitute(ex, $k m -> 0$);
remove_zero_components(ex);

Snippet 2:

from cdb.core.component import *

{x, y, z}::Coordinate.
{i, j}::Indices(values={x, y, z}, position=fixed).
ex := b_{i j} = a_{i}a_{j};
evaluate(ex, $a_{x} = k, a_{y} = l, a_{z} = m$, rhsonly=True);
# substitute(ex, $k m -> 0$);
components_to_subrule(ex);

Negative powers of 0

Tue, 12 Dec 2023 13:10:44 +0000

Hi! I've found out that

substitute($t**{-1}$, $t -> 0$)

equal to 0 in cadabra, and this is the same for any negative power. I think it's a bug.

meld sets to zero when it shouldn't?

Tue, 05 Dec 2023 21:15:09 +0000

Hi, and thanks as always for cdb.

I think I may be missing something, but I can't figure what it might be. Please consider the following two pieces of code; they only differ in that the first uses canonicalise while the second uses meld. However the second gives 0 as the result and I don't see why.

First segment of code:

\partial{#}::PartialDerivative.
{\mu,\nu,μ,ν}::Indices(spacetime,position=fixed).
f::Depends(\partial{#}).
\delta_{\alpha}^{\mu}::KroneckerDelta.
{\alpha,\beta,α,β}::Indices(flat,position=fixed).
e_{\alpha}^{\mu}::Depends(\partial{#}).

{u^{\mu},v^{\mu}, \partial_{\nu}{Q??}, \partial_{\nu}{f}, \partial_{\mu\nu}{f}, e_{\nu}, f, (1/f)}::SortOrder.

ex := \partial_{μ}(e_{β}^{ν}) \partial_{ν}(f) e_{α}^{μ} +
        \partial_{μ ν}(f) e_{α}^{μ} e_{β}^{ν}
        -\partial_{μ}(e_{α}^{ν}) \partial_{ν}(f) e_{β}^{μ}
        -\partial_{μ ν}(f) e_{α}^{ν} e_{β}^{μ}.
ex;
canonicalise(ex);

Second segment of code:

\partial{#}::PartialDerivative.
{\mu,\nu,μ,ν}::Indices(spacetime,position=fixed).
f::Depends(\partial{#}).
\delta_{\alpha}^{\mu}::KroneckerDelta.
{\alpha,\beta,α,β}::Indices(flat,position=fixed).
e_{\alpha}^{\mu}::Depends(\partial{#}).

{u^{\mu},v^{\mu}, \partial_{\nu}{Q??}, \partial_{\nu}{f}, \partial_{\mu\nu}{f}, e_{\nu}, f, (1/f)}::SortOrder.

ex := \partial_{μ}(e_{β}^{ν}) \partial_{ν}(f) e_{α}^{μ} +
        \partial_{μ ν}(f) e_{α}^{μ} e_{β}^{ν}
        -\partial_{μ}(e_{α}^{ν}) \partial_{ν}(f) e_{β}^{μ}
        -\partial_{μ ν}(f) e_{α}^{ν} e_{β}^{μ}.
ex;
meld(ex);

Thank you

GPN

Manually fiddling with multiplier on \sum

Fri, 01 Dec 2023 16:20:34 +0000

There is an interesting bug (?) when one manually fiddles with the multiplier on \sum.

ex := x+y;
ex.top().multiplier=-1

display(ex) and ex.input_form both return x+y. But if I access @(ex), it returns -x-y. tree(ex) clearly sees the -1 on the \sum node.

Presumably the multiplier on sum shouldn't be manually modified by the user, but I found this behaviour interesting.

WeightInherit type=additive thinks operator is \sum

Wed, 29 Nov 2023 16:09:51 +0000

The ::WeightInherit property appears to treat the operator implicitly as a \sum when type=additive.

x::Weight(value=2, label=field).
y::Weight(value=3, label=field).
f{#}::WeightInherit(label=all, type=additive).
ex:= f{x}.
drop_weight(ex, $field=2$);

returns 0, as expected, but

drop_weight(ex, $field=1$);

returns x. (Same for field=3,4,...)

Interestingly,

ex := f{x}{y}.
drop_weight(ex, $field=3$);
ex := f{x}{y}.
drop_weight(ex, $field=2$);

returns first x and then y. Similarly,

ex := f{x}{y}{z}.
drop_weight(ex, $field=3$)

returns f{x}{z}.

So drop_weight is converting f{x} to x but if f has more than one child, it's leaving it as f. Presumably this is because the code implicitly treats f as \sum.

substitute crashes with empty replacement rule

Sun, 26 Nov 2023 05:45:04 +0000

This is a bit pathological, but calling substitute with an empty set of rules causes the kernel to crash.

ex := A+B;
substitute(ex, $ $);

ex := A+B;
substitute(ex, ${ }$);

This is perhaps more a feature request than a bug report, as it might be nicer if we received the usual error message (i.e. "not a replacement rule or equality").

Bug with Ex.matches() for indices in opposite positions

Sun, 26 Nov 2023 04:10:23 +0000

Consider the following:

{a,b,c}::Indices(vector, position=independent).
{i,j,k}::Indices(isospin, position=independent).

bool1 = $\Lambda_{a}$.matches($\Lambda_{i}$);

bool2 = $\Lambda_{a}$.matches($\Lambda^{i}$);

bool1 evaluates to False, while bool2 evaluates to True.

The same behavior occurs if we use position=fixed. However, for position=free, both evaluate to False (as expected). This would seem to be a bug.

Empty expressions fail to match

Mon, 20 Nov 2023 19:20:56 +0000

Any of the following cause the kernel to crash:

Ex('X').matches(Ex(' '));
Ex(' ').matches(Ex(' '));
Ex(' ').matches(Ex('X'));

This is slightly pathological, of course.

Using 2.4.5 (build 2910.ad85a64173).

Problem with substitute and powers

Tue, 31 Oct 2023 22:12:31 +0000

Hello!

When i try to make a substitution in the following expression:

ex:=-a**2 - b**2 - 2 a b;
substitute(_,$b->-a$);

I get 2aa, which is obviously wrong. However, if i run the following commands:

ex:=-a**2 - b**2 - 2 a b;
expand_power(_);
substitute(_,$b->-a$);

I get 0, as should be. What is the problem with the first example?

Substitution after map_sympy(*, 'simplify')

Wed, 25 Oct 2023 12:21:30 +0000

Hello!

I've found some strange thing: If I have an expression with square root in it, and try to substitute it, like

Eq := \sqrt(X);
substitute(Eq, $\sqrt(X) -> A$);

it works and I get A. But if I send it to sympy in the middle, the substitution stops working

Eq := \sqrt(X);
map_sympy(Eq, 'simplify');
substitute(Eq, $\sqrt(X) -> A$);

This particular example is silly, but it illustrates the problem.

InverseMetric is not symmetric?

Mon, 23 Oct 2023 12:28:11 +0000

Hi And as always many thanks for $C_{δβ}$.

Is this a bug or a feature, please?

g^{\mu\nu}::InverseMetric.

if InverseMetric.get($g^{\gamma\kappa}$):
    print('yes')  # <-- actually prints yes
else:
    print('no')

if Symmetric.get($g^{\gamma\kappa}$):
    print('yes')
else:
    print('no')  # <-- actually prints no

Thanks GPN

function evaluate output a wrong order of SelfAntiCommuting objects

Wed, 20 Sep 2023 13:33:27 +0000

Hi, the following codes output a wrong result.

{x,y}::Coordinate;
{a,b,c,d,e,f# }::Indices(vielbein, values={x,y}, position=independent);
{a,b,c,d,e,f# }::Integer(range=0..1)
\gamma_{a}::SelfAntiCommuting.
\omega^{a b}::AntiSymmetric.
ex:=  xxx  =  \gamma_{a} \gamma_{b} \omega^{a b}  ;
evaluate(ex,rhsonly=True,simplify=False);

I obtained

$\gamma_x \gamma_y \omega^{y x} +\gamma_y \gamma_x \omega^{x y}$

The right result should be

$\gamma_x \gamma_y \omega^{x y} +\gamma_y \gamma_x \omega^{y x}$

Any suggestion would be greatly appreciated!

Module "cdb.core.component" cannot be imported

Tue, 29 Aug 2023 06:49:36 +0000

When I import cdb.core.component using

import cdb.core.component as comp

I get the following error:

  File "/Users/hl/Library/Preferences/cadabra_packages/cdb/core/component.py", line 17, in <module>
    from cdb.core._component import get_component
ModuleNotFoundError: No module named 'cdb.core._component'

When I go to the folder containing the file "component.py", I saw that there are 3 functions: "get_component", "remove_zero_components(ex), components_to_subrule(ex)" (this is expected as these are the 3 functions under the 'core.component' module), but the function "get_component" is grayed out (commented out). The code for this also has a strange import:

from cdb.core._component import get_component

which refers to "cdb.core._component" that cannot be found.

I recently updated Cadabra to the latest version and this is the first time I am using 'get_component' so I don't know what is wrong, but the fact that the entire 'get_component' function is grayed out is strange to me. I wish I could attach a screenshot to show this, but I can't find the option to attach an image (only the URL for the image), so I copied and pasted the code from "component.py" here:

import cadabra2
import imp
from cadabra2 import *
from cadabra2_defaults import *
__cdbkernel__ = cadabra2.__cdbkernel__
temp__all__ = dir() + ['temp__all__']

def display(ex):
   pass

from cdb.utils.node import n_children
from cdb.core.manip import get_lhs, get_rhs
from cdb.utils.indices import get_free_indices
from cdb.core._component import get_component

#def get_component(ex, components):
#   """Gets a particular component of an expression"""
#   # Work on a copy of ex
#   ex = ex.top().ex()
#
#   # Replace all free indices with the components
#   free_indices = get_free_indices(ex.top())
#   if components.top().name != r"\comma":
#       tmp = Ex(r'\comma')
#       tmp.top().append_child(components.top())
#       components = tmp
#   assert len(free_indices) == n_children(components.top()), f"Expression contains {len(free_indices)} free indices, but {n_children(components.top())} components supplied"
#   for index, component in zip(free_indices, components.top().children()):
#       node = next(ex[index.top().name], None)
#       changed = True
#       while changed:
#           for node in ex[index.top().name]:
#               if node.parent_rel == parent_rel_t.super or node.parent_rel == parent_rel_t.sub:
#                   pr = node.parent_rel
#                   node.replace(component.ex())
#                   node.parent_rel = pr
#                   break
#           else:
#               changed = False
#
#   # Replace all component nodes with the particular component we are looking for
#   for node in ex[r'\components']:
#       # Sift through \equals nodes finding the one with the right components
#       for candidate in node[r'\equals']:
#           arg = get_lhs(candidate)
#           if arg == components:
#               node = node.replace(get_rhs(candidate))
#               break
#       else:
#           node = node.replace($0$)
#
#   # The components paramater needs to have a head '\comma' node
#   # so let's quickly make sure that's true.
#   if components.head() != r'\comma':
#       bit = $@(components)$
#       components.top().name = r'\comma'
#       components.top().append_child(bit)
#
#   return ex

Thank you in advance for any help.

Autocomplete on Jupyter Notebook acting weird

Tue, 25 Apr 2023 11:04:30 +0000

Whenever I try to use autocompletion on Jupyter notebooks it always autocompletes with "a.echo1" or by appending "ho1" to the last "a.echo1" it autocompleted. Has autcomplete been integrated in the Jupyter kernel yet or is there something wrong with my setup? Thank you

eliminate_metric - avoid partial differential

Wed, 05 Apr 2023 12:06:14 +0000

Hi, I don't know if this is a bug: Does eliminate_metric supposed to move the metric tensor inside partial derivative freely?

I have the following code:

{x1,x2,x3,x4}::Coordinate;
{k,l,m,n,p,q,r,s,t}::Indices(position=fixed,values=[x1,x2,x3,x4]);
g{m n}::Metric;
g^{m n}::InverseMetric;
g{m}^{n}::KroneckerDelta;
g^{m}{n}::KroneckerDelta;
{g{m n},g^{m n}}::Depends(x1,x2,x3,x4);
\nabla{#}::Derivative.
\partial{#}::PartialDerivative.
test := Q^{s}_{r m n} -> g^{s k} \partial{r m}{g{k n}};
eliminate_metric();

The output I get is that the inverse-metric goes inside the derivative and contracts with the metric to form the Kronecker-delta. Is this supposed to happen? Am I supposed to limit the method eliminate_metric to avoid partial-derivatives?

exponents problems

Mon, 13 Feb 2023 14:46:11 +0000

If I try to use collect_factors for an expression that contains exponents, it does not collect them into one exponent, for example:

collect_factors($\exp(-2\sigma-2\kappa) \exp(2\sigma) \exp(2\kappa)$);

these exponents can only be removed by map_sympy(ex, "simplify"), but it can't be used with zoom function, for example. same situation with product_rule.

Incorrect Derivative Free Index Behaviour For User-Defined Symbols

Fri, 27 Jan 2023 05:35:51 +0000

Consider the following example:

\m::LaTeXForm("\mu").
\n::LaTeXForm("\nu").

D{#}::Derivative;
{\m,\n}::Indices(s,position=fixed);
{\mu,\nu}::Indices(p,position=fixed);


{x_\mu}::Coordinate;
ex:=D_{x_\mu}{\theta_\mu};
for i in ex.top().free_indices(): 
   display(i);

{x_\m}::Coordinate;
ex:=D_{x_\m}{\theta_\m};
for i in ex.top().free_indices(): 
   display(i);

One would expect no free indices in both expressions. Indeed, for D{x\mu}{\theta_\mu}, there are no free indices. However, for the expression involving the user-defined LaTeXForm symbols \m, there are free indices.

This creates issues when trying to add two expressions like this together.

Incorrect behaviour of meld?

Mon, 23 Jan 2023 07:43:17 +0000

Hi! I'm trying to do some manipulations in supersymmetry. I'm getting this behaviour from the meld function:

{i, j, k,l,m,n}::Indices(position=fixed).
{i, j, k,l,m,n}::Integer(1..2).
{i, j, k,l,m,n}::AntiCommuting.

ex:=v^i v_i -v_i v^i;
meld(_);

This gives me an output of 0, but this should be $2v^iv_i$ in order to respect the anticommuting nature of the object.

One would also expect

ex:=v^i v_j -v_j v^i;
meld(_);

to give $2v^iv_j$, but rather it doesn't change the expression at all. Neither does canonicalise. I'd assume this is not the expected behaviour based on this question.

Let me know if this is not the case.