There are several points where evaluating a DLR function may not give the user what they were expecting.
Here are some examples
iw_mesh = MeshDLRImFreq(beta=100, statistic='Fermion', w_max= 10, eps = 10e-14)
gf_struct =[('up',1), ('dn',1)]
G_iw = BlockGf(mesh=iw_mesh, gf_struct=gf_struct)
G_iw << SemiCircular(1.0)
G_dlr = make_gf_dlr(G_iw["up"])
print(G_dlr(0.0))
print(G_dlr(0))
print(G_dlr(100.0))
print(G_dlr(-100.0))
print(G_dlr(-5.0))
print(G_dlr(95.0))
print(G_dlr(200.0))For example, evaluating G_DLR(float) versus G_DLR(int) gives G(tau) versus G(iomega_(integer index)) which while is a nice functionality, may be confusing for Python users where many things are not type restricted.
In a more physics context, a user (or at least for myself personally) might expect that G_dlr obeys the identity $$G(- \tau) = G(\beta - \tau)$ which DLR does not obey.
I understand anti-periodicity comes with ambiguities at the boundaries, but it seems like the function should in that case just not evaluate for negative values, rather than returning an incorrect value. This could be in line with evaluating for values above $\beta$ but then again here I would think that it should throw an error.
I know I was actually supposed to fix this myself with a PR to evaluate.hpp , but this has a comment
// Do not restrict M here, as this function can be used (in brzone) with simpler objects which do not have the full Mesh concept.
so I am not sure what the preferred fix would be.
There are several points where evaluating a DLR function may not give the user what they were expecting.
Here are some examples
For example, evaluating G_DLR(float) versus G_DLR(int) gives G(tau) versus G(iomega_(integer index)) which while is a nice functionality, may be confusing for Python users where many things are not type restricted.
In a more physics context, a user (or at least for myself personally) might expect that G_dlr obeys the identity $$G(- \tau) = G(\beta - \tau)$ which DLR does not obey.
I understand anti-periodicity comes with ambiguities at the boundaries, but it seems like the function should in that case just not evaluate for negative values, rather than returning an incorrect value. This could be in line with evaluating for values above$\beta$ but then again here I would think that it should throw an error.
I know I was actually supposed to fix this myself with a PR to
evaluate.hpp, but this has a comment// Do not restrict M here, as this function can be used (in brzone) with simpler objects which do not have the full Mesh concept.so I am not sure what the preferred fix would be.