Clearly stated, wish I could return the favor.
However,
1) Fourier transform is a change of basis, not physical variable -- it
is invertible as a matter of fact, as long as you keep the real and
imaginary parts. Because it is a change of basis, it is much more
analagous to a projection transformation than a transformation of the
physical variable.
There is a change of units, you are right, but that is misleading if
it leads you to think that more than a change of basis has occured. I
suppose if you were really stubborn about it, we could transmit
discrete Fourier transforms, but that seems a little silly. Besides,
the units part of standard_name is the weakest part of the framework
-- relatively little data with the scales I am interested in atm/ocean
is exchanged with time in seconds, for example, despite the
standard_name constraint on time. As it should be.
2) Software that manipulates complex numbers, (including FFT), needs
both the real and imaginary parts -- putting them in separate
variables is a highly artificial reconstruction of the data which has
to be undone in order to proceed with any manipulation that treats it
as complex numbers. Also, the software needs to detect the components
of the complex numbers -- you are making it much more difficult. The
point of metadata is to make the necessary information available
clearly and unambiguously -- having a dimension clearly labelled as
corresponding to real and imaginary is much closer to the information
needed to write software to correctly handle complex data.
3) CF should handle spectral harmonics as well.
Benno
On Tue, Jun 15, 2010 at 3:24 AM, Jonathan Gregory
<j.m.gregory at reading.ac.uk> wrote:
> Dear Benno
>
>> This time you have understood
> Good.
>
>> I believe my proposal is a lot more useful.
>
> Our proposals differ in two ways:
>
> * I suggest the standard name should not be air_pressure, but should include
> a phrase like fourier_transform_of_air_pressure_wrt_time. Basically that's
> because if you do a Fourier transform, it's not the same physical quantity and
> doesn't have the same units as air pressure, so it needs a new standard name.
>
> * I suggest that the imaginary and real components should be in different
> data variables, distinguished by the standard name. That's just the same as
> we do for spatial components of vectors and tensors. When you search a file
> to find the quantity you want, you can identify the real or imaginary part
> by looking at the standard name. I think that's as easy, or easier, than
> finding a dimension for real/imaginary and checking the coordinates.
>
> Cheers
>
> Jonathan
>
>> On Mon, Jun 14, 2010 at 1:42 PM, Jonathan Gregory
>> <j.m.gregory at reading.ac.uk> wrote:
>> > Dear Benno
>> >
>> > You mean C is either "real" or "imaginary"? I think the CF-like way to do
>> > this would be to have two different data variables for it, one for the real
>> > part, one for the imaginary. That's like having different standard names
>> > for spatial components, as we do, rather than dimensions for components.
>> > As for spatial components, where "eastward", "upward", etc. are in the
>> > standard name, here you would put "real" or "imaginary" in the standard name.
>> > The standard name would then be not air_pressure but something like
>> > ?real|imaginary_part_of_fourier_transform_of_air_pressure_wrt_time
>> > I'd suggest.
>> >
>> > I hope I have understood now, but maybe not! Best wishes
>> >
>> > Jonathan
>
--
Dr. M. Benno Blumenthal benno at iri.columbia.edu
International Research Institute for climate and society
The Earth Institute at Columbia University
Lamont Campus, Palisades NY 10964-8000 (845) 680-4450
Received on Wed Jun 16 2010 - 12:08:04 BST
