What would be a better interface of CFT data calculation function?

[Chenqitrg]

Hi Yue, thanks for this! I want to refactor the whole way we are calculating cft data to unify it and make it easier for the user to understand. Right now the cft methods are often type unstable, or return Dict{Any, Any} by design and this really should not be the case.

Do you have any ideas for a unified cft data interface? We could make some sort of CFTdata struct that all of the cft methods return an instance of.

Originally posted by @VictorVanthilt in #120 (comment)

[Chenqitrg]

As mentioned in previous PR, the problem for cft_data of LoopTNR is it returns a Dict{Any, Any} type of dictionary, where the central charge and scaling dimensions are stored together. I am wondering whether there exists a better solution.

Maybe to mimic the eigsolve function in KrylovKit, we may formulate the input parameters and returning data like

central_charge::Float64, scaling_dimensions::DiagonalTensorMap = cft_data(f::Function, V::ProductSpace, shape::Vector{Float64})

[VictorVanthilt]

I propose:

struct CFTData{E, I}
    central_charge::{E}
    scaling_dimensions::TensorKit.SectorVector{E, I}
end

SectorVector can be indexed like normal vectors, and additionally by keys corresponding to different sectors (e.g. Z2Irrep(0))

[Chenqitrg]

I propose:

struct CFTData{E, I}
central_charge::{E}
scaling_dimensions::TensorKit.SectorVector{E, I}
end
SectorVector can be indexed like normal vectors, and additionally by keys corresponding to different sectors (e.g. Z2Irrep(0))

It is really good for me to know the SectorVector data type.

[VictorVanthilt]

Its a TensorKit internal so if we decide to use it we have to tell the user how to use it with a small example.

[Chenqitrg]

Do you guys have any plan about when to solve it?

[Chenqitrg]

Its a TensorKit internal so if we decide to use it we have to tell the user how to use it with a small example.

It seems it has only been added three months ago. No wonder I cannot find it in documentation.