Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hilbert transform and normalization #19

Open
tayral opened this issue Sep 29, 2013 · 7 comments
Open

Hilbert transform and normalization #19

tayral opened this issue Sep 29, 2013 · 7 comments

Comments

@tayral
Copy link
Member

tayral commented Sep 29, 2013

Hi,
The current Hilbert transform assumes that \rho(\epsilon) is a dos object, i.e. that it is normalized. One could want, however, to perform the Hilbert transform of other objects, e.g. objects that are not normalized (for instance to find the Kramers-Kronig conjugate of Re F(\omega) where F(\omega) is analytical...). Moreover, the mathematical definition of a Hilbert transform does not require normalization.
I would thus suggest switching off the __normalize() method in dos/hilbert_transform.py. I tried and it gives correct results.
I also think that \Sigma should be =0 by default.
Best
Thomas

@mferrero
Copy link
Member

OK, we could put an extra flag in the constructor: normalize_dos defaulted to True. This would keep backward compatibility.

@tayral
Copy link
Member Author

tayral commented Oct 4, 2013

On 09/30/2013 11:54 AM, Michel Ferrero wrote:

OK, we could put an extra flag in the constructor: normalize_dos
defaulted to True. This would keep backward compatibility.


Reply to this email directly or view it on GitHub
#19 (comment).

OK. If one wants to set Sigma=None as default (which is the most natural
case for using a Hilbert transform), the following problem pops up: one
does not know the sizes N1 and N2 anymore (they were previously
extracted from N1 and N2). When one writes

HT=HilbertTransform(dos)
g <<= HT(...)

is there a way for HT() to know about g.N1 and g.N2 ?

@mferrero
Copy link
Member

One would have to change the way HilbertTransform works right now and make it a descriptor for the Green's functions. This would actually make some sense. It's easy to do but it won't be possible to do the assignment in 2 steps like above. One would have to write directly something like:

g <<= HilbertTransform(dos, ... other_options ...)

This breaks the API and older scripts won't work. We can do it when we move to TRIQS 1.1.0. @parcollet, @tayral Do we do it?

@Kh89 Kh89 mentioned this issue Jan 22, 2014
@pseth
Copy link
Member

pseth commented Nov 21, 2014

Do we want to do this for v1.2?

@tayral
Copy link
Member Author

tayral commented Nov 22, 2014

In principle there is an easy workaround (by normalizing the density and multiplying by the norm in the end. In any case the doc should be clear about the precondition on the density. I will take a look asap.

@tayral
Copy link
Member Author

tayral commented Jul 22, 2015

How about this old issue? Has the Hilbert transform been rewritten in c++ yet? I still think it would be nice to have a general Hilbert transform without a requirement on the norm of the rho(\omega).

@parcollet
Copy link
Member

Not yet... To be done.

@parcollet parcollet assigned mferrero and unassigned tayral Jul 3, 2017
@parcollet parcollet removed the 1 - Todo label Jul 3, 2017
@parcollet parcollet added this to the 1.5 milestone Jul 3, 2017
@parcollet parcollet removed this from the 1.5 milestone Jan 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants