In article <KANZE.95Aug10105751@slsvhdt.lts.sel.alcatel.de> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
In article <40c8ot$q00@metro.ucc.su.OZ.AU> maxtal@Physics.usyd.edu.au
(John Max Skaller) writes:

|> In article <1995Aug4.165955@opal.tufts.edu>,
|> Jonathan Borden <jkauer@opal.tufts.edu> wrote:
|> >In article <3vo8a7$jde@metro.ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
|> >>  valarray isn't an STL container because its purpose is
|> >> quite different. Here's my picture:

The purpose last time I heard any comment about valarray was to define
a type which could benefit from optimizations of knowing that it does
not have pointers pointing to various places etc.  I don't know the
full story here, except that it seems that fortran has a similiar
capability and it out optimzes C.

In article <1995Aug4.165955@opal.tufts.edu>,
Jonathan Borden <jkauer@opal.tufts.edu> wrote:
>In article <3vo8a7$jde@metro.ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
>>  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.
>
> hmmm... what about maps & sets, the hp implementation (and hence
>many derivatives) code these as red-black trees. In STL there are several
>types of iterators, a sequential iterator is one type, however, random access
>iterators also exist.

 Perhaps I didn't explain well. Random access iterators indeed
exist, as does a container "set". But a random access is a shorthand
for sequential access, and an associative lookup is a shorthand
for a search of a linearly ordered set of elements.

 That is, a set is first and foremost a sequence in which
inserting a new element automatically positions the element in
the "right" place in the sequence, as is a map: these things are "subtypes"
of "sequences", that is, some of the methods can be made faster
(or are even possible) because they maintain stricter invariants
that the most basic linear access requirement. (sequential iteration)


>>  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.
>>
> Since STL in fact supports more than lists and vectors as containers
>this answer does not follow. I'm not sure that STL references types of CPU's
>at all.

 A vector is a sequence, obviously. So is a list.
 The very notion of iteration is inherently a question of
enumerating things: linearity.

--
        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

In article <40c8ot$q00@metro.ucc.su.OZ.AU> maxtal@Physics.usyd.edu.au
(John Max Skaller) writes:

|> In article <1995Aug4.165955@opal.tufts.edu>,
|> Jonathan Borden <jkauer@opal.tufts.edu> wrote:
|> >In article <3vo8a7$jde@metro.ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
|> >>  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.
|> >
|> > hmmm... what about maps & sets, the hp implementation (and hence
|> >many derivatives) code these as red-black trees. In STL there are several
|> >types of iterators, a sequential iterator is one type, however, random access
|> >iterators also exist.

|>  Perhaps I didn't explain well. Random access iterators indeed
|> exist, as does a container "set". But a random access is a shorthand
|> for sequential access, and an associative lookup is a shorthand
|> for a search of a linearly ordered set of elements.

|>  That is, a set is first and foremost a sequence in which
|> inserting a new element automatically positions the element in
|> the "right" place in the sequence, as is a map: these things are "subtypes"
|> of "sequences", that is, some of the methods can be made faster
|> (or are even possible) because they maintain stricter invariants
|> that the most basic linear access requirement. (sequential iteration)

Perhaps you should be more precise, and state that in the STL
implementation...

In my own implementation of sets and maps (done long before STL came
along), they are not sequences, and there is nothing in the concept
that imposes sequenciality on a set.

Formally, the presence of an iterator doesn't impose a linear
ordering, either, although I know of no implementation that would not
result in a (generally arbitrary) linear ordering.  (In my
implementation, for example, running the iterator over the same set
twice will result in visiting the members in the same order.  This is
an artifice of the implementation, however, and is not intrinsic in
the definition of iterator, at least, not in the definition I use.)

|> >>  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.
|> >>
|> > Since STL in fact supports more than lists and vectors as containers
|> >this answer does not follow. I'm not sure that STL references types of CPU's
|> >at all.

|>  A vector is a sequence, obviously. So is a list.
|>  The very notion of iteration is inherently a question of
|> enumerating things: linearity.

I would disagree, at least for the meaning we normally give to
`iterator' in this context.  An iterator does not formally impose an
ordering.  In particular, in my implementation of SetOf (which uses
open hashing), if an element is inserted while an iterator is active,
it is undefined whether the element will be considered before or after
the iterator.

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <3vo8a7$jde@metro.ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
> 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.

 hmmm... what about maps & sets, the hp implementation (and hence
many derivatives) code these as red-black trees. In STL there are several
types of iterators, a sequential iterator is one type, however, random access
iterators also exist.


>
>  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.
>

 Since STL in fact supports more than lists and vectors as containers
this answer does not follow. I'm not sure that STL references types of CPU's
at all.

>  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.
>
 I'm not sure this follows either. Assuming the STL templates are
in-line optimized, the string class is ultimately represented by
a   char*, and a well-designed optimizer shouldn't suffer.

>  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.

 there are different types of non-sequential processing of non-numeric
information. several modern os's allow multithreading/multiprocessing,
and there are several object systems which allow distributed processing.
Admittedly, standard C++ doesn't directly support multithreading ---
however ObjectSpace's STL (for one) does provide generic multithreading support
and concurrency management. Similarly Corba type IDL's provide C++ mappings
to iterfaces (i.e. pure virtual base classes) and Microsoft's COM/OLE is
fairly stongly C++ oriented (again pure virtual base classes). Using
holder & envelope objects STL containers are an effective way to deal with
both multithreading and object interfaces.

jon borden
jabr technology corporation
component medical software

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

bglenden@colobus.aoc (Brian Glendenning) writes:


>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.

valarray was provided to support numeric programming. It mimics
the functionality of arrays in Fortran. The desired semantics are not
compatible with STL.
--
Steve Clamage, stephen.clamage@eng.sun.com

In article ntd@engnews2.Eng.Sun.COM, clamage@Eng.Sun.COM (Steve Clamage) writes:
>bglenden@colobus.aoc (Brian Glendenning) writes:
>
>
>>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.
>
>valarray was provided to support numeric programming. It mimics
>the functionality of arrays in Fortran. The desired semantics are not
>compatible with STL.

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.  A more likely explanation
is that 'valarray' was already accepted in the standard before STL
was adopted.  Since 'valarray' was judged to serve a useful purpose
not already covered by STL, it was left alone.  (By contrast, 'dynarray'
*didn't* serve a purpose not already covered by STL, and so it was
deleted.)

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.

---
Marc Shepherd
Salomon Brothers Inc
shepherd@schubert.sbi.com <<These are my opinions, not my employer's.>>

In article <3ukjva$ntd@engnews2.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve Clamage) writes:

> STL already has array classes, if you want an STL-compatible array.
>
> valarray was provided to support numeric programming. It mimics
> the functionality of arrays in Fortran. The desired semantics are not
> compatible with STL.

How so? Which of the requirements from table 50 could a valarray not
fill? (If it's <, >, etc., does that mean that vector<complex<float>>
is not possible). Why are there gratuitous differences (e.g. size()
vs. length()).

Brian
--
        Brian Glendenning - National Radio Astronomy Observatory
bglenden@nrao.edu              Socorro NM               (505) 835-7347

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).

Brian
--
        Brian Glendenning - National Radio Astronomy Observatory
bglenden@nrao.edu              Socorro NM               (505) 835-7347