`number` behaves weirdly with spinless fermion operator

[thudjx]

The MWE goes like:

snegspinlessfermionoperators[d];
bs = {d[CR, 1]};
matrixrepresentationop[number[d[1]], bs] 
matrixrepresentationop[nc[d[CR, 1], d[AN, 1]], bs] 

which returns

{{0}}
{{1}}

It seems that the expression generated by number function behaves differently from by the nc. Do I miss something here?

[rokzitko]

By default `number[d[1]]` actually returns `nc[d[0,1,0], d[1,1,0]] + nc[d[0,1,1],d[1,1,1]]`, that is a sum over both spin components (last argument, 0 and 1), while 1 in the middle is a site index. This explains the difference.

…

On 8 Mar 2023, at 07:11, Jason ***@***.***> wrote: The MWE goes like: snegspinlessfermionoperators[d]; bs = {d[CR, 1]}; matrixrepresentationop[number[d[1]], bs] // MatrixForm matrixrepresentationop[nc[d[CR, 1], d[AN, 1]], bs] // MatrixForm which returns {{0}} {{1}} It seems that the expression generated by number function behaves differently from by the nc. Do I miss something here? — Reply to this email directly, view it on GitHub <#5>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG57NBCPIJFYZU5BGMBOGODW3APHTANCNFSM6AAAAAAVTLYFUE>. You are receiving this because you are subscribed to this thread.

[thudjx]

I have found that number of a spinless fermion operator is substituted according to the rule, which means the returned operator is in fact has spin component(0) at tail of the index list, which is not shown. A similar case is here:
.
This clearifies my question. But I am not sure this is a good idea to represent a spinless fermion, cause we can easily have a two component index list:

The last postion of the index list has some kind of arbitrarity. When it is 0, this position is interpreted as spin and is hidden in the output; while when it is not 0, this position is a solid index and has to be shown.

[rokzitko]

Sorry, I missed the fact that this was about spinless operators. Yes, in this case these are assumed to be "spin 0" objects, thus a 0 is appended.
I agree, that was a bad design choice (made many years ago..). The best fix is probably to make this silent suppression of trailing index 0 configurable in SnegPPoperator.