[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ideas in blitz++

This page is part of the web mail archives of SRFI 25 from before July 7th, 2015. The new archives for SRFI 25 contain all messages, not just those from before July 7th, 2015.



Great SRFI!!

However, if I can suggest to have a look at the library blitz++ : this is a
template library in C++ (a bag of clever macros) which deals with arrays.
They have defined some basic operations and others not so basic to deal with
multi-dimensional arrays.
Some concepts from this library :
  - represent the data as a linear vector
  - store shape information in some "vectors":
      - base vector : store the lower index in each dimension
      - length vector : store number of indices in each dimension
      - step vector : store the step size for each dimension
      - stride vector : store the product of the length of the dimension g
      - permutation vector : store if any permutation
  - a different object to reprensent shapes

Hence, in order to acces the element (array-ref a 3 5 6), we compute :
   i = (3-base[permutation[0]])/step[permutation[0]]*stride[permutation[0]]
+
       (5-base[permutation[1]])/step[permutation[1]]*stride[permutation[1]]
+
       (6-base[permutation[2]])/step[permutation[2]]*stride[permutation[2]]
and give (vector-ref v i).

In the SRFI-25 way of thinking, the analogies are:
	(shape a) = (base[0] (+ base[0] length[0]) ... base[n] (+ base[n]
length[n])) 
      permutation = (0 1 ... n) (no permutation of indices)
	step = (1 1 ... 1) (indices increase only by 1)
      stride = (lentgh[0]*...*length[n-1]*1 lentgh[1]*...*length[n-1]*1 ...
length[n-1]*1 1)  

Some advantages of the representation are:
	- the possibility to transpose arrays with no cost by doing:
	     permutation = (1 0 2) instead of (0 1 2)
      - having steps (may be negative or positive)
	- representing slice (with affine maps) by playing only on
"base","step" and "permutation"
      - shapes are not arrays, indices are not arrays because they both need
more economic and efficient representations

Well, I think it is worth the look. Maybe those ideas are only ideas for
implementations but anyway, this is a srfI !
Moreover, this can be efficiently done (no vector nestings) and can be a
great tool for numeric calculus (speed AND high level language!!!)

Sebastien de Menten