Re: [boost] boost.numeric (and multi_array)

From: Gabriel Dos Reis (Gabriel.Dos-Reis_at_[hidden])
Date: 2001-03-28 07:42:45

Hi,

Jeremy Siek <jsiek_at_[hidden]> writes:

| On 27 Mar 2001, Gabriel Dos Reis wrote:
| Gabrie> | 
| Gabrie> | A[indirect(begin_row_index, end_row_index)]
| Gabrie> |  [indirect(being_col_index, end_col_index)]
| Gabrie> 
| Gabrie> Without expression-templates I suspect that will bring in performance
| Gabrie> lost.  Please, let us not trade syntax for functionalities/semantics.
| 
| Ok... I haven't looked into this issue. What are the various alternatives?

  * define a well-delimited kernel -- no fancy syntax, just keep it as
    simple as possible;

  * for higer-level layers, provide both traditional functions and
    overloaded operators -- nifty syntax is where you don't really
    care about a 5-10% of performance lost.

| Gabrie> What is really wrong with operator()?
| 
| By operator(), do you mean indexing into an array using the notation
| A(i,j,k)? 

Sort of.  The problem with operator[] is that it requires proxy
classes which come with their own set of extra-problems (semantics,
and performance).

| ... If so, it's a bit unsavory because there will be some
| hard coded limit to the number of dimensions you can support

I understand.  But a multidimensional array already has the limit hard
coded in its type.  So the question is how can we statically vary
indexing arity with that of the array dimension.
Perhaps should we have to introduce an index class template...
Doing so will effectively lets one use operator[], but it will break
with C-array indexing syntax.

| ... , and
| it would be nice to avoid the kind of repetitive code you see
| in Blitz++. 

| ... Also, operator[] is what builtin arrays use.

I can understand the desire to keep C-array indexing syntax, but by
definition that syntax doesn't come with the problems we have with
proxy arrays. 
 
We need to abstract over that syntax.

-- Gaby