Copying an array with different dimensions

[Richard Russell]
[Richard Russell]
in Richard Russell's BBC BASICs
In all modern (32-bit or 64-bit) versions of BBC BASIC you can copy one array into another in one statement as follows:
      dst() = src()
The destination array must be the same data type and the same size as the source array, otherwise a 'Type mismatch' error will result.

However different versions of BASIC interpret 'same size' differently. In BBC BASIC for Windows, BBC BASIC for SDL 2.0 and the BBC BASIC Console Mode editions what matters is the total number of elements. So this is perfectly valid:
      DIM a(99), b(9,9)
      b(4,5) = 123.45
      a() = b()
      PRINT a(45)
Indeed not only is this valid, it can be extremely useful because there are situations when you may want to treat a multidimensional array as if it was a one-dimensional array.

For example you might want to perform a dot-product operation on an array audio%(1023,1) containing 1024 stereo samples, where the second subscript is 0 for the left channel and 1 for the right channel. But to do this the source needs to be one-dimensional with 2048 audio samples, so you can simply copy it into such an array.

Unfortunately some other versions of BBC BASIC interpret 'same size' as meaning 'same dimensions' and will not allow this kind of assignment. I have no idea why, it seems to me to impose an entirely artificial restriction that only serves to make it less flexible.

Comments

  • BigEd
    BigEd
    I believe APL offers a 'reshape' operator to help with this kind of thing. Being generous with the meaning of 'shape' is another way. Is there any way in which being generous here could hide an error (a semantic error, in effect)? That would seem to me the main potential downside.

    I suppose the existing body of code precludes introducing a new syntax. But perhaps a() = DIM b() would be unambiguous and help to signpost the intent?
  • [Richard Russell]
    [Richard Russell]
    BigEd wrote: »
    I believe APL offers a 'reshape' operator to help with this kind of thing.
    What's APL? Some library for use with BBC BASIC?
    Is there any way in which being generous here could hide an error (a semantic error, in effect)? That would seem to me the main potential downside.
    Interpreters, in general (and certainly BBC BASIC), don't tend to perform error checking with the sole purpose of detecting 'programmer' errors - the run-time cost is simply too expensive. As a rule the errors detected at run-time are ones which prevent the interpreter continuing execution, so something has to fail.

    If the source array and the destination array have the same number of elements, they are conceptually the same array (of course that doesn't apply in the case of languages in which, for example, the rows of an array are not contiguous in memory). That equivalence is already enshrined in BBC BASIC in respect of the dot-product operator.

    If you multiply two 1D vectors together, to give a scalar value, the first is a single row and the second a single column. So you should probably represent them both as 2D arrays, declared as DIM first(0,n), second(m,0) but in practice you hardly ever do, because it's inconvenient. Rather you simply declare them as DIM first(n), second(m) and rely on BBC BASIC treating them internally as equivalent.

    It's just one of the many ways in which interpreted languages differ from compiled languages. The latter can do all sorts of syntax and semantics checking at compile-time, with the principal purpose of saving the programmer time and effort by picking up coding errors before you even run the program. But although an interpreted language could do the same checks (at run time) the cost in execution speed is usually far too great, and the programmer just has to be more careful.

    So, not surprisingly, I'm certain that the way my BASICs check for validity when copying arrays is more sensible and more useful.
  • BigEd
    BigEd
    Ah yes, the dot product is an interesting example. Although, I would always have thought of the arguments as vectors, not as degenerate matrices. Anyhow, I'm sure you're right, in the sense that allowing for different shapes to count as the same size is convenient and not problematic.

    (APL is a venerable programming language, with arrays as a first class data type... or indeed, perhaps the only datatype. It's not a language one would learn in a short time, or necessarily want to, but it has a lot of interesting ideas in it. We can learn from it, without learning it.)
  • [Richard Russell]
    [Richard Russell]
    BigEd wrote: »
    Ah yes, the dot product is an interesting example. Although, I would always have thought of the arguments as vectors, not as degenerate matrices.
    Either way the result should be a scalar, but in BBC BASIC you must declare it as an array (1D or 2D) with just one element!

    Then of course there's the dot- (scalar-) product when applied to two 2D matrices, or a 1D vector multiplied by a 2D matrix. In my BASICs the only requirement for the destination scalar/vector/matrix is that it has the correct total number of elements, the 'shape' is irrelevant.

    That's true of the dot-product even in Acorn's BASICs, isn't it? If so, it suggests an inconsistency with simple array copying.

Categories