The main application of this that I envision is examining the power
spectra of individual SCUBA-2 bolometers. If this modification you
describe allows me to write the FFT using the native complex type, and use
kappa commands to calculate new NDFs like:
power = real^2 + imag^2
argument = atan(real/imag)
then I would be happy, as I could then easily plot these real-valued
vectors.
An alternative would be for me to simply write out two separate
(real-valued) components to the NDF (data_real, data_imag), and then I can
definately use kappa commands in the way I described.
thanks,
Ed
> At the moment, using "DATA" as the NDF component name when calling
> ndfMap returns you the real part of the data. What would be nice is if
> NDF/ARY were modified so that you could specify "DATAI" (say) to get
> the imaginary part. Then you could use the existing KAPPA COMP
> parameters to choose whether to see the imaginary part or the real
> part of your data.
>
> David
>
>
> 2008/6/13 Malcolm J. Currie <[log in to unmask]>:
>>>> Kappa will work with complex data, but will convert it to real data by
>>>> throwing away the imaginary part. This may or may not be of any use to
>>>> Ed, depending on what he wants to do.
>>>
>>> I see, thanks. Looking at FIGARO I see there are some commands that might
>>> be helpful, cmplx2i for instance copies the IMAGINARY data to the REAL
>>> part of an ordinary NDF.
>>
>> There's I2CMPLX to go the other way to reassemble after independent
>> processing. It's clunky and open to error to have to make another NDF
>> to process the imaginary part independently, but at least there is a
>> route.
>>
>> Hitherto there's been insufficient (i.e vritually no) demand for
>> processing complex data, although we expected otherwise, hence its
>> inclusion in the NDF design. Also there are historical reasons.
>> Figaro already had some functionality in this area (albeit on DSTs), and
>> complex types weren't available in the IMAGE-format era in the first
>> few years of KAPPA's existence. KAPPA routines consequently don't use
>> NDF_MAPZ and have no checksfor COMPLEX_<numeric_type> (in addition to the
>> regular <numeric_type>) to do appropriate processing. Complex-data
>> processing could be added as needs arose, and in many cases it would not
>> require much effort.
>>
>> Malcolm
>>
>
>
>
> --
> Note my change of e-mail address. Please send e-mail to
> [log in to unmask] from now on.
>
|