Re: octave "Most Wanted" feature

[robert bristow-johnson]

> ----- Original Message -----
> From: "Przemek Klosowski" <address@hidden>
> To: "robert bristow-johnson" <address@hidden>
> Subject: Re: octave "Most Wanted" feature
> Date: Wed, 29 Nov 2006 18:06:28 -0600
> 
>   >> What would be the point?
> 
>   >     the point is so that the indices can be directly meaningful
>   > to the interpretation of the data that they are associated with.
>   > the point is so that the expressions in Octave (or MATLAB, i wish)
>   > would more closely resemble the mathematical expressions of the
>   > same quantity as expressed in the textbooks and the literature.  i
>   > made two *very* clear examples regarding the DFT and discrete-convolution
> 
> The non-zero offset is but a special case of dimension scales for
> data---scales limited to integer numbers with unit increment.
> Dimension scales for a N-dimensional data array are a set of N vectors
> with the values of some independent variable describing the support of
> the data. For example, a 3-D meteorological temperature dataset would
> have 3 dimension scale vectors describing the latitude, longitude and
> altitude along each edge of the array. Properly, each dimension scale
> should have a 'physical units' attribute, too.
> 
> Since Octave doesn't have this built it, we are doing things like
> 
>        x=[1:.1:2*pi];
>        y=sin(x);
>        plot(x,y);
> 
> With dimension scales, the 'x' vector would be the dimension scale
> property of data 'y', and we would just 'plot(y)'. Note that when
> dimension scales form a linear mesh, they can be represented by Octave
> interval ([start:step:end]) rather than the general case of a
> multi-element vector.
> 
> It seems to me that if you are arguing for high level data structures,
> you should be requesting full-blown dimension scales, not its poor
> cousin the offset.  In your own example, FFT, the data is sampled at
> physical intervals, and the resulting frequencies should be described
> by floating point numbers. As you say, the computers should work for
> you, not the other way around :)

in the past, when i brought this up before to the comp.soft-sys.matlab this was 
suggested in the form that a sampling-rate or sampling-period would also become 
part of the MATLAB (or in the present case, Octave) variable structure.  and it 
was proposed that some decent interpolation would automatically be done when 
someone referred to a non-integer index (after the automatic scaling with the 
sample-rate).  i actually disagree for a political reason and for a technical 
reason.

the technical reason is that actually in DSP, we _really_do_ forget about the 
sampling rate, until such a time that we are actually executing a real-time DSP 
program and are witnessing the effects of it in a reality where we actually 
perceive time in seconds or milliseconds.  but the DSP algorithm is completely 
oblivious to that.  the only thing that the DSP algorithm understands are 
samples: the current sample (z^0), the sample previous to that (z^(-1)), the 
sample previous to that (z^(-2)), etc.  we DSP algorithmists have learned long 
ago that it's easier to think about time in terms that the DSP algorithm does: 
the unit time is the sample period, the sampling frequency is 1 or 2*pi 
radians/sample.  "Nyquist" is "pi" or +/- pi.  -pi < omega < pi, etc.  also, 
time as we perceive it in seconds is a continuous quantity but in 
MATLAB/Octave/whatever environment, all of these function are discrete 
sequences; discrete-time, discrete-space, etc.  i don't see the need for 
attaching a sampling period to each Octave variable and i think it would not be 
useful very often, or hardly ever.  and, of course, there is computational 
overhead to do the scaling and, even more so, the interpolation.  nearly all 
DSP texts express everything in terms of the discrete samples and sequences 
("x[n]" instead of "x(nT)") rather than continuous-time once you get past the 
Nyquist/Shannon sampling and reconstruction theorem.

the political reason is that, to my chagrin, even though we can make this 
perfectly backward compatible, there is resistance to this (as evidenced even 
here) and i don't want to couple in another issue that offers the resistors 
another reason for resistance.  even if i liked this additional property, the 
need to have indices that are zero and negative is much, much greater.  we need 
it so our equations expressed as MATLAB/Octave code looks something like the 
corresponding equations in the textbooks and the literature (or our derivations 
in our own documents) which never assume a needed offset so that all indices 
are positive.

--

r b-j                  address@hidden

"Imagination is more important than knowledge."