🚀 go-pugleaf

In article <3um3id$qf1@offas_dike.sbil.co.uk>,
Marc Shepherd <shepherd@debussy.sbi.com> wrote:
>>
>>>Why is "valarray" not an STL container? (Excuse me if this question
>>>has already been answered - I was out of net.contact for a while).
>>
>>STL already has array classes, if you want an STL-compatible array.
>>

>Yes, but many of the interface distinctions between valarray and STL
>containers are gratuitous--i.e., not a necessary consequence of the
>'desired semantics' that Steve refers to.  
>
>IMHO, the interface of 'valarray' *should* be STL-compatible, except
>where doing so would interfere with the 'desired semantics'.  I have
>already submitted an official public comment to this effect.  All classes
>accepted in the standard, it seems to me, should have a consistent design
>style and should appear to have flowed from a common thought process.
>The fact that 'valarray' and 'STL' were designed and proposed by different
>committee members is irrelevant: at this point, it is just one Standard.

	valarray isn't an STL container because its purpose is
quite different. Here's my picture:

	STL is based on the notion that everything can be organised
into sequences: these sequences are represented by pairs of iterators.
There are no trees in STL because a tree isn't a linear sequence.

	Why just sequences? The answer is that that is all that
a single thread of control can handle. Even conceptually parallel
processes must be organised into _some_ sequence for a conventional
computer to use it.

	valarray exists exactly because most CPU's support
SOME kind of parallelism -- whether it be limited to caching,
emulated by threads and tasks, done by vectorisation, 
or multiprocessing. To optimise processing for such systems
requires additional constraints on the software -- valarray
has been carefully designed to embody some constraints which
enable this kind of optimisation.

	Such parallelism is posible for STL code too -- but
only if the compiler carefully analyses the code to determine
if what the programmer coded as a sequence can be done
non-sequentially without changing the semantics.

	With valarray, certain such operations are _guarranteed_
to be vectorisable: the compiler doesn't need to do any work.

	For example adding two valarrays either requires doubling
one of the arrays (if the two arrays are the same array) or adding
component by component -- in either case element by element
operations can be done in parallel. 

	Why?: Because valarray is VALUE ORIENTED. A valarray is
a SINGLE object. Whereas STL is REFERENCE ORIENTED. A pair of
iterators denotes a method of finding elements IN SEQUENCE.

	PS: Yes I know this is an oversimplification.

	PS2: Pete Becker argued strenuously that "string" was a single
object and should NOT be STL'ised. But it has been, and the result
is undoubtedly a loss of optimisation opportunites in favour of
a more flexible interface.

	BTW: you may sensibly ask why C++ does not have
support for non-sequential processing of non-numeric
information. The answer is: the numerical people AGREE to a large
extent on what they need. Special hardware has always 
been built for them.

	Does anyone claim operating system writers 
or GUI programmers agree on ANYTHING??? <grin>

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
	Maxtal Pty Ltd,		    
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21 
        NSW 2037, AUSTRALIA	    Phone: 61-2-566-2189