[#3986] Re: Principle of least effort -- another Ruby virtue. — Andrew Hunt <andy@...>

> Principle of Least Effort.

14 messages 2000/07/14

[#4043] What are you using Ruby for? — Dave Thomas <Dave@...>

16 messages 2000/07/16

[#4139] Facilitating Ruby self-propagation with the rig-it autopolymorph application. — Conrad Schneiker <schneik@...>

Hi,

11 messages 2000/07/20

[ruby-talk:04202] new operators for numerical computation (from comp.lang.python)

From: Conrad Schneiker <schneik@...>
Date: 2000-07-25 08:26:32 UTC
List: ruby-talk #4202
Hi,

Konrad Hinsen wrote (on comp.lang.python):

> However, higher-rank arrays are often used with a different
> interpretation: arrays of vectors or matrices. For example, I might
> have a rotation matrix at each time step of some simulation, or a
> polarizability tensor for each particle. For these cases it makes
> sense to extend the meaning of the infix operators to higher-rank
> arrays.
>
> The cleanest concept (in my opinion) is the one implemented in J,
> where an array has (conceptually) a "data rank" and a "value rank",
> the sum of the two being the rank, i.e. the number of indices. For
> example, an array of rank 3 could be interpreted as a list of matrices
> (data rank 1, value rank 2), as a matrix of vectors (data rank 2,
> value rank 1), or as a 3-d array of scalars (data rank 3, value rank
> 0). In J the data and value ranks are not properties of the arrays,
> but of the operators, whose value rank can be modified. In the early
> days of NumPy development, I proposed this model for NumPy as well,
> but there was no majority for it. And I agree that there are not so
> many practical cases where this mechanism is necessary. However,
> it nicely illustrates how one would extend vector and matrix operations
> to higher-dimensional data.

--
Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)



In This Thread

Prev Next