Julian C. Cummings wrote:
>
> Arch Robison wrote:
>
> >
> > Certainly, removing aliasing from a language that supports abstract data types
> > is impossible, because by definition an abstract data type is a black box inside.
> > Knowing whether two black box's internal guts cause aliasing requires knowing
> > their guts.
>
> Yes, and this is a critical issue if we want to take advantage of something like
> the "restrict" keyword in the context of expression templates. I believe it can
> be done as long as
>
> a) The user is willing to put up with "special" types that imply that the data
> that they control is not aliased.
>
> b) These special types allow their guts to be sufficiently exposed (e.g., loops
> can be written on the contained data using raw data pointers, which can then
> be labeled as restricted).
This was exactly the rationale behind valarray, and we all know what an
overwhelming success *that* has been. :-(
The only interesting question remaining is whether valarray has failed
because it is badly designed, or because the underlying concept (of a
special type with controlled aliasing) is fundamentally flawed. I am
sufficiently skeptical of my own ability that I won't rule out the
former, but my feeling is that the latter is (also?) true.
At the very least, valarray suffered from my appalling ignorance of the
true economics of language standards and the tools market. The
economic incentives to implement it "right" (whatever that really
means) just don't exist. The open question is whether *any* special
alias-controlled class can be designed that will overcome this
barrier. My feeling is that this cannot be done, for these reasons:
1. The scientific/engineering market will continue to diminish in
relative importance. (In pure economic terms, I would argue that the
importance of this market is actually overinflated at the moment. Look
at the bath Intel took when it tried to get into the supercomputer
business.) N.B. the use of the qualifier "relative."
2. The benefits of array syntax just don't justify the cost. IMO, STL
has shown that loops can be beautiful after all.
3. Programmers will increasingly find that arrays are not always the
optimum data structure for their programs. This will render the debate
over array syntax and array classes moot in many cases.
I find it curious that this entire thread began with the question, "How
do C++ and Fortran compare for numerical programming?" It always seems
to come around to array performance. I suggest this reflects a curious
case of tunnel vision.
Kent "Frankenstein" Budge
(Original author of valarray)
--------------------- Object Oriented Numerics List --------------------------
* To subscribe/unsubscribe: use the handy web form at
http://oonumerics.org/oon/
* If this doesn't work, please send a note to owner-oon-list@oonumerics.org
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:11 EST