search

jjhelmus / nmrglue

A module for working with NMR data in Python
BSD 3-Clause "New" or "Revised" License
211 stars 86 forks source link

question re proc_lp.lp_1d #55

Closed mgeorgiadis closed 7 years ago

mgeorgiadis commented 7 years ago

I've got something very similar to a 1-D FID in a numpy float32 array, and I was trying to use the proc_lp.lp_1d function to perform a forward linear prediction on the data. When I run the function, I get the following error attached in the image. As you can see, I also tried casting the array to a 'complex64' and that didn't fix the problem either. How do I get around this error? image

jjhelmus commented 7 years ago

nmrglue's linear prediction routines require complex input and you are passing real-only data. You could try converting your data to a complex dtype using:

test = test.astype('complex64')

Even with the change I would not expect good results. LP models models a FID as a decaying sinusoidal which oscillated between the real and imaginary channels. If the imaginary channel is all zero I would expect that such a model would have difficulties.

mgeorgiadis commented 7 years ago

Hi,

Thanks for the reply! As I mentioned in my post, I actually did try to cast it as a complex64, and still got the error, so I'm not sure whats going on there. If I bypass the bad_root finding routine, I'm able to get it to run. I know that for NMR, LP is based around it being a complex value, but I've found that LP is also used for speech modeling, which is real-valued.

jjhelmus commented 7 years ago

I actually did try to cast it as a complex64

The commented out line you posted did not save the cast values, see the line I proposed.

but I've found that LP is also used for speech modeling, which is real-valued.

This is true but the setup of the problems are very different. I would not expect a NMR based LP routine to be well suited for speech modeling but you are welcome to try.

mgeorgiadis commented 7 years ago

Ah good to know, didn't know that you couldn't manipulate a numpy arrays state with the "." like you can for a python list. That fixed it!

Yeah I just wanted to check out how it works, and if I get something promising, then I can try implementing a more focused package.