> how to you hope to achieve decent performance?
> If you expect compilers to be written especially for compiling SVMT,
> then worrying about blitz's use of ISO/ANSI language features
> (particularly templates) is, well, counterproductive.
I am NOT excluding expression templates.
Since expression templates do not appear in the application program,
there is no need to specify them or any other optimization technique
in the SVMT class library standard. They are implementation details
which should be left up to the SVMT class library developer.
> In Blitz++, subarrays are "first-class array objects,"
> meaning that anything you can do with an array, you can do with a subarray.
> For instance, if foo is a function which operates on an 2-D array:
>
> void foo(Array<float,2>& A);
>
> I can apply foo to (say) a two-dimensional slice of a 3-D array:
>
> Array<float,3> B(N,N,N); // ...
> foo(B(Range::all(), 5, Range::all())); // apply foo to B(:,5,:)
>
> This is difficult if subarrays are a different type, as in your SVMT
proposal.
> Do you provide an automatic conversion from arrays to subarrays?
SVMT tensor classes are derived from the respective SVMT subtensor classes
so SVMT subtensor classes are also "first-class array objects."
void foo(floatSubMatrix& A);
floatTensor B(N, N, N); // ...
foo(B.t23()[5]); // apply foo to B(:, 5, :)
> The main advantage to reference counting is efficiency.
> Without reference counting you have to resort to making copies
> of whole arrays in some situations, which is very inefficient.
> For example, returning an array by value:
>
> Array<float, 1> foo(void) {
> }
This doesn't appear to be a problem for my GNU compiler.
Or maybe I don't understand which copies you are talking about?
>> The disadvantages, besides a small overhead for reference counting,
>> are less obvious. First, it is difficult for the programmer and impossible
>> for the compiler to distinguish arrays from subarrays.
> The way I would phrase this difference is that programmers don't
> have to care if they are operating on a subarray or a full array;
> they can write one piece of code which works for both cases.
The same is true for SVMT tensor and subtensor objects.
> If for some reason they need to know whether an array is a subarray,
> there are member functions for this.
> I'm not sure what you are getting at when you say that
> it is "impossible for the compiler to distinguish arrays from subarrays."
> Are you implying that there are optimizations
> which SVMT-aware compilers could perform which blitz can't?
You don't need an SVMT - aware compiler to take advantage
of any differences between tensor and subtensor objects.
An SVMT class library developer might decide, for example,
to take advantage of the fact that there is unit stride between
the elements in any row of a vector, matrix or tensor object
by simply overloading some of the functions and operators.
>> Second, there is no way to determine whether
>> the original array is destroyed before all of the subarrays are destroyed
>> which is almost certainly a programming error.
> I'm not sure I understand what you mean here, but there are no problems
> related to the order of destruction of arrays which I know of.
> Can you give an example?
const int n = 7;
Array<double, 1>* p = new Array<double, 1>(n); // 1- D array
Array<double, 1> v = *p; // 1- D
subarray
delete p;
*p = 1.0;
Bob Tisdale