Re: octave "Most Wanted" feature

[robert bristow-johnson]

> From: "John W. Eaton" <address@hidden>
> Subject: octave "Most Wanted" feature
> Date: Wed, 29 Nov 2006 03:04:25 -0500
> 
> 
> On 27-Nov-2006, robert bristow-johnson wrote:
> 
> | The proposed system would, of course, continue this constraint and add a
> | new constraint in that index bases for each dimension (the base[]
> | vector) would have to be equal for two arrays to be added.
> 
> I see no need for this restriction.  I think only the number of
> elements should have to agree.

if we add the sequence a_n to b_n, it's a_2 that gets added to b_2, not any 
other a_n.

this is fundamental.  it won't be right if we do it
 
> | The
> | resulting array would have the same shape and base[] vector as the input
> | arrays.
> 
> How about the resulting array has base 1 by default,

i have (even after looking at the Fortran code) no idea why you would want the 
behavior to be like that??

it's like presently having a 2x3 array add to a 3x2 array and the result be a 
1x6 array.  when two mathematrical sequences are added, it's the elements with 
the same subscripts that are added to an elemental result with the same 
subscripts.

> unless declared
> otherwise?  Isn't that what Fortran would do?

i dunno what Fortran would do presently, but this should be better (higher 
level, more meaningful) than Fortran in such a case.  why copy mistakes?

>  The dimensions of an array are a local property.

the Index Origins of dimensions of an array is the same kind of property of it 
that the lengths of the dimensions are.

> 
> | CONCATINATION:
> |
> | This would also be a simple and straight-forward extension of how MATLAB
> | presently concatinates arrays.  When we say:
> |
> | A = [B C];
> 
> Likewise, I think the base of the result should be 1 unless declared
> otherwise.

i see no reason why.  given an n so that A(n) and B(n) are both meaningful,  
they should be the same number.

> | FUNCTIONS THAT RETURN INDICES (min(), max(), find(), sort(), ind2sub(),
> | and any others that I don't know about):
> | It must be internally consistent (and certainly can be made to be).  The
> | indices returned would be exactly like the 1-based indices returned
> | presently in MATLAB except that the base index for the corresponding
> | dimension (that defaults to one) would be added to each index.  That is,
> | just like now in MATLAB, if:
> |
> | [max_value, max_index] = max(A);
> |
> | This must mean that A(max_index) is equal to max_value.
> 
> These are problematic.  I was thinking that the base should be a local
> property, as it is in Fortran.  For example, think of writing a max
> function that just returns the max value.  In Fortran it can be
> something like this:
> 
>    real function madmax (a, n)
>    integer n, i
>    real a(n)
>    madmax = a(1)
>    do i = 2, n
>      if (a(i) .gt. val)
>        madmax = a(i)
>      endif
>    enddo
>    return
>    end
> 
> and you could call it with an array of any size or shape (even a
> multidimensional array, provided that A is full (no leading dimension
> problems) and N is the total number of elements.  But there is trouble
> if we want to return an index that corresponds to the dimensions
> declared in the caller.  If the full dimensions (lower and upper bound
> or base plus number of elements) are passed to a function along with
> the value, then I think we will have a lot of confusion, or a lot of
> work to do.  For example, we will have confusion if all the code that
> currently does something like
> 
>    function f (a)
>      for i = 1:numel (a)
>        a(i)
>      endfor
>    endfunction
> 
> fails to work when called like this:
> 
>    dimension a0 (0:10)
>    f (a0)
> 
> and I think it would be unreasonable to expect users to remember to
> write
> 
>    function f (a)
>      n = numel (a);
>      dimension a(1:n);
>      for i = 1:n
>        a(i)
>      endfor
>    endfunction
>
> (and much work to change all existing functions to work properly if
> this were required).
> 
> My intial reaction is also that it would be unacceptable to have just
> some functions (like min and max) be special and know about the base
> of their arguments (so they could return index values that correspond
> to the base used in the caller) while others ignored that
> information, but imagine that this is possible.  What happens for code
> like this:
> 
>    function idx = f (a)
>      n = numel (a);
>      dimension a (10:n+10);
>      [dummy, idx] = max (a);  ## IDX in the range 10:n+10
>    endfunction
> 
>    a = zeros (10, 1);  ## indices in the range 1:10.
>    idx = f (a)
>    printf ("max of a is: %g\n", a(idx));
> 
> ?

the important behavior is that this is backward compatible and predictable.   
the only sensible behavior is that A(max_index) is equal to max_value when 
[max_value max_index] = max(A).

> Maybe problems like this are why others think that this kind of change
> is not really a good idea for this language?

so far, i cannot understand why you would want these behaviors to be as you 
have stated.  the overriding behavior is, of course, backward compatibility: 
that arrays default with Index Origins of 1 when created, and when the Index 
Origins are equal to one, any Octave operation behaves the same after adding 
this feature as it did before.  then, in the extension, we are free to expand 
the definition, but we must do it in the most logical and meaningful way,.

i misquoted Q. Spencer yesterday, but meant to pick up on what he said. for 
example, there is a way that the DFT could work meaningfully with arrays that 
have origins of other than 0, which would attach exp(j*2*pi*n*k/N) to each term 
of x(n) based on the actual value of "n", not n minus the Index Origin for that 
dimension.  these Index Origins should go with the Octave variable as such a 
variable goes into a function and should be meaningfully used so that the index 
has the same meaning as the corresponding subscript did for x_n in the textbook 
or literature.

--

r b-j                  address@hidden

"Imagination is more important than knowledge."