One thing that bugs me slightly as the 1.0 release is coming up is the PiecewiseLegendrePoly and PiecewiseLegendreFT classes.
If, at any point in the future, we want to switch to a different set of functions, for instance, if we manage to find something that is close in analytic structure to the IR functions, then we will have to increment the major version.
So, the question is whether we should introduce abstract TauFunction and MatsubaraFunction types that forms base types for PiecewiseLegendrePoly and PiecewiseLegendreFT, respectively, have the documentation/type hints refer to those types and then rename poly to _poly?
What do you think? Not hugely important, but maybe something to think about ...
@Samuel3008 this of course would be something that would need mirroring in the SparseIR.jl repo...
One thing that bugs me slightly as the 1.0 release is coming up is the
PiecewiseLegendrePoly
andPiecewiseLegendreFT
classes.If, at any point in the future, we want to switch to a different set of functions, for instance, if we manage to find something that is close in analytic structure to the IR functions, then we will have to increment the major version.
So, the question is whether we should introduce abstract
TauFunction
andMatsubaraFunction
types that forms base types forPiecewiseLegendrePoly
andPiecewiseLegendreFT
, respectively, have the documentation/type hints refer to those types and then renamepoly
to_poly
?What do you think? Not hugely important, but maybe something to think about ... @Samuel3008 this of course would be something that would need mirroring in the
SparseIR.jl
repo...