proposals

[Karl Meerbergen-2]

Dear List,

I am hesitating between two conceptual systems for glas.
None of them is ideal, but we have to make a choice and perhaps someone
comes up with a better idea.

The idea is to use Concept C++, but also provide a working system for a
C++ compiler.

I have the following concepts (among others)

Expression
ScalarExpression: e.g. double
VectorExpression: e.g. result_type of add(vector,vector)
DenseVectorExpression: e.g. dense_vector<double>

and
Collection
ScalarCollection: e.g. double
VectorCollection
DenseVectorCollection: e.g. dense_vector<double>

The Expression and Collection concepts are set up in a tree fashion. For
each Expression, there is a corresponding Collection (one-one
correspondance).

The root is Expression/Collection with two children:
* ScalarExpression/ScalarCollection
* VectorExpression/VectorCollection

VectorExpression/vectorCollection has one child:
* DenseVectorExpression/DenseVectorCollection

The difference between expression and collection lies in that an
expression is not mutable.

OK. So far the basics. Using Concept C++, these can be used to dispatch
an expression like

assign( v, add( x, y ) )

to the most suitable implementation, following the tree structure of
expression and collection. I do not give the details here.

For the C++ compiler, this is more tricky:
I see two possibilities:

A) Use meta programming to examine an expression.
For each type, we can ask questions about where we are in the concept
tree. In the above example,

concept_tag< dense_vector<double> >::type == dense_vector_collection_tag

concept_tag< double >::type == scalar_collection_tag

For the dispatching, it might be useful to know which type of expression
we are working with, e.g.

which_kind< vector_expression_tag, dense_vector<double> >::type ==
dense_vector_expression_tag

which_kind< collection_tag, dense_vector_<double> >::type ==
vector_collection_tag

The which_kind meta function selects the concept that is a child in the
concept tree.


B) Use Bartan-Nackman trick

For each concept, we provide a type, e.g.

template <typename E>
struct dense_vector_expression
: vector_expression<E>
{
...
} ;


All GLAS types inherit from a concept type that can be used in
dispatching, e.g.

template <typename T>
class dense_vector
: public dense_vector_collection< vector<T> >
, public dense_vector_expression< vector<T> >
{
 ...
} ;

This system is very close to the concept c++ concept system and
therefore I like it very much, but the disadvantage is that built-in
types do not have this mechanism: e.g.

class double
: public scalar_expression<double>
, public scalar_collection<double>
{
 ...
} ;

So, we should define glas::double, glas::complex, glas::int etc.


System B is relatively easy to put together. With system A, the GLAS
user can use his own classes in GLAS whithout having to use the Barton
and Nackman trick for his own classes, and built-in types perfectly fit
into the system. If we choose A, we should use this also with Concept
C++, otherwise we have two completely different systems, which is overkill.

I hope my explanation is clear. It is rather technical matter.

Thanks for your reactions.

Karl

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[Karl.Meerbergen.vcf]

---

begin:vcard
fn:Karl Meerbergen
n:Meerbergen;Karl
org:Katholieke Universiteit Leuven;Department of Computer Science
adr:;;Celestijnenlaan 200A;Heverlee (Leuven);;B-3001;Belgium
email;internet:Karl.Meerbergen@...
tel;work:[phone]
tel;fax:[phone]
tel;cell:[phone]
url:http:://www.cs.kuleuven.be/~karlm
version:2.1
end:vcard

---

_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas

[Gunter Winkler]

Hi Karl,

On Monday 05 February 2007 11:02, Karl Meerbergen wrote:
> A) Use meta programming to examine an expression.
> For each type, we can ask questions about where we are in the concept
> tree. In the above example,

> B) Use Bartan-Nackman trick

Before I start: Is there an automatic tool, that can convert code for
conceptc++ to concept-free c++ code? (Such that conceptc++ works as a kind of
preprocessor for g++?)

About your proposals: I generally don't like the Barton-Nackman trick (CRTP).
This caused always headache when I tried to figure out the right combinations
of parameters for my functions. A good example of this is the various
dispatch mechanisms of ublas, which are hard to follow. So I would always
prefer a solution which is readable.
Thus I prefer a (single) dispatch with some meta-programming and function
parameters that show what they are:

(correct me, if I am wrong) the CRTP versions would look like:
do_something(vector_expression<V> & v, scalar_expression<S> & s, ...,
dense_tag, ...);
do_something(vector_expression<V> & v, scalar_expression<S> & s, ...,
unknown_tag, ...);

the A) version just would look like
do_something(V & v, S & s,
  is_convertible< concept_tag<V>::type, dense_vector_expression_tag >,
  is_convertible< concept_tag<V>::type, scalar_expression_tag > );
...

IMO the possibility to easily add custom class and custom algorithms for
expression is quite important.
Finally, the best solution would be to only need the concepts ...

mfg
Gunter



_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas

[Pieter Collins]

Karl Meerbergen wrote:

> For the C++ compiler, this is more tricky: I see two possibilities:
> A) Use meta programming to examine an expression.
> B) Use Bartan-Nackman trick
>     All GLAS types inherit from a concept type that can be used in
> dispatching.

I think it's very important to allow the use of user scalar types which
do not inherit from glas concept types, so I much prefer A) over B).

A possible alternative might be to use B) but to "assume" types which do
not inherit from a glas type are scalars.

Pieter

_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas

[Toon Knapen]

Karl Meerbergen wrote:

> This system is very close to the concept c++ concept system and
> therefore I like it very much, but the disadvantage is that built-in
> types do not have this mechanism: e.g.
>
> class double
> : public scalar_expression<double>
> , public scalar_collection<double>
> {
> ...
> } ;
>
> So, we should define glas::double, glas::complex, glas::int etc.

Or an alternative would be to use meta-programming tricks to recognize
the built-in types.



> If we choose A, we should use this also with Concept
> C++, otherwise we have two completely different systems, which is overkill.



I'm all for portability. However if using concepts makes life _much_
easier and since we can expect concepts to end up in the standard,
relying on concepts is only a drawback in the short term.

toon
_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas

[Karl Meerbergen-2]

Hi,

Thanks for the comments on my last e-mail. In the meantime, I did some
coding for a backend system using relatively simple ideas using the
conceptual tree for expressions/collections. I assume this system can
still be simplified.

I also experimented alot with conceptgcc. Although the compiler is
improving every SVN release, I am still unable to get a complicated
piece of code compiled. I see two reasons: my limited experience with
concept c++ and instabilities in the compiler (usually a compilation
ends with segmentation fault).

I would like to suggest to forget about concept C++ for now, and develop
using C++ only, but keeping the concepts in mind. The danger is this
could make the use of concept c++ in a later stage more difficult.

I will explain some ideas a document. You can expect this some time in
April. Then, we can decide how to continue.

Best regards,

Karl

[Karl.Meerbergen.vcf]

---

begin:vcard
fn:Karl Meerbergen
n:Meerbergen;Karl
org:Katholieke Universiteit Leuven;Department of Computer Science
adr:;;Celestijnenlaan 200A;Heverlee (Leuven);;B-3001;Belgium
email;internet:Karl.Meerbergen@...
tel;work:[phone]
tel;fax:[phone]
tel;cell:[phone]
url:http:://www.cs.kuleuven.be/~karlm
version:2.1
end:vcard

---

_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas

[Karl Meerbergen-2]

Hi,

I am preparing a proposal for an extendable backend system and concepts
for vectors (and scalars to some extent).

One of the design decisions I would like to make is to use free
functions as much as possible.  I think that free functions would make
life alot easier and extensions more straightforward. I will explain
later in detail.

Does someone have a strong objection against
size(v) instead of v.size(), stride(v) instead of v.stride() ?

Similarly, one could argue that meta functions are preferred to members,
e.g.
size_type<V>::type rather than V::size_type.

However, concept C++ suggests to organize this in a slightly different
way, e.g.
VectorExpression<V>::size_type
where VectorExpression is a concept.
In pure C++, VectorExpression would be a traits blob.
Therefore, I prefere the latter notation to meta functions with a single
type member.

Best,

Karl

[Karl.Meerbergen.vcf]

---

begin:vcard
fn:Karl Meerbergen
n:Meerbergen;Karl
org:K.U. Leuven;Department of Computer Science
adr:;;Celestijnenlaan 200A;Heverlee (Leuven);;B-3001;Belgium
email;internet:Karl.Meerbergen@...
tel;work:[phone]
tel;fax:[phone]
tel;cell:[phone]
url:http:://www.cs.kuleuven.be/~karlm
version:2.1
end:vcard

---

_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas

[Karl Meerbergen-2]

Hi,

Thanks for all comments you sent the last few weeks. I have written a
document that summarizes some of the ideas. I hope it is helping us for
further development.

The link can be found here:
http://www.cs.kuleuven.be/~karlm/glas/
See the heading Papers

Comments are welcome

Karl



Karl Meerbergen wrote:

> Hi,
>
> I am preparing a proposal for an extendable backend system and
> concepts for vectors (and scalars to some extent).
>
> One of the design decisions I would like to make is to use free
> functions as much as possible.  I think that free functions would make
> life alot easier and extensions more straightforward. I will explain
> later in detail.
>
> Does someone have a strong objection against
> size(v) instead of v.size(), stride(v) instead of v.stride() ?
>
> Similarly, one could argue that meta functions are preferred to
> members, e.g.
> size_type<V>::type rather than V::size_type.
>
> However, concept C++ suggests to organize this in a slightly different
> way, e.g.
> VectorExpression<V>::size_type
> where VectorExpression is a concept.
> In pure C++, VectorExpression would be a traits blob.
> Therefore, I prefere the latter notation to meta functions with a
> single type member.
>
> Best,
>
> Karl
>
>_______________________________________________
>glas mailing list
>glas@...
>http://lists.boost.org/mailman/listinfo.cgi/glas
>

[Karl.Meerbergen.vcf]

---

begin:vcard
fn:Karl Meerbergen
n:Meerbergen;Karl
org:K.U. Leuven;Department of Computer Science
adr:;;Celestijnenlaan 200A;Heverlee (Leuven);;B-3001;Belgium
email;internet:Karl.Meerbergen@...
tel;work:[phone]
tel;fax:[phone]
tel;cell:[phone]
url:http:://www.cs.kuleuven.be/~karlm
version:2.1
end:vcard

---

_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas

[Karl Meerbergen-2]

Hi,


At this time, I am the only active developer in the GLAS project and I
am feeling lonesome. Therefore, I am calling for developers who want to
work on concepts and implementation of containers, algorithms etc. as
well as the regression and performance tests, and portability.

In February, Marc Van Barel and I applied for a grant to the FWO
(Research Foundation - Flanders), without success. We are trying to get
some feed-back why we failed. I see other possibilities for funding,
which I will certainly try.

In the meantime, I would like to speed up the development of the project
by a call for developers. There are several aspects that can be
developed independently. If noone shows up, we may have a working suite
of vector concepts and algorithms only by the end of the year, depending
on my 'free' time.

I also would like to organise a meeting with those who are interested in
a more lively discussion than a mailing list.

Other suggestions to speed up a bit are welcome.

I must admit I am disappointed that there was not a single reaction on
my last e-mail. If the document was too hard to read, please tell me so
that I can improve it.


Best,


Karl

[Karl.Meerbergen.vcf]

---

begin:vcard
fn:Karl Meerbergen
n:Meerbergen;Karl
org:K.U. Leuven;Department of Computer Science
adr:;;Celestijnenlaan 200A;Heverlee (Leuven);;B-3001;Belgium
email;internet:Karl.Meerbergen@...
tel;work:[phone]
tel;fax:[phone]
tel;cell:[phone]
url:http://www.cs.kuleuven.be/~karlm
version:2.1
end:vcard

---

_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas

[Georg Baum]

Am Donnerstag, 24. Mai 2007 10:20 schrieb Karl Meerbergen:

> I must admit I am disappointed that there was not a single reaction on
> my last e-mail. If the document was too hard to read, please tell me so
> that I can improve it.

Hi Karl,

I can very well understand your disappointment. In my case it was simply
lack of time. I really would like to participate, but am really busy with
my PhD thesis currently so I unfortunately can't afford it right now.
Hopefully some others are able to join, since this project is really needed
and deserves some more attention.


Georg

_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas

[Richard Natal]

Hi Karl,

I'm starting receiving glas e-mails! I'm a Brazilian C++ programmer  and I work with C++ since 1997.
I'd like to help, but to do that, I need some kind of planing! What can I do to help? There is a TODO list somewhere?

[]s
Richard

On 5/24/07, Karl Meerbergen <Karl.Meerbergen@...> wrote:

Hi,


At this time, I am the only active developer in the GLAS project and I
am feeling lonesome. Therefore, I am calling for developers who want to
work on concepts and implementation of containers, algorithms etc. as
well as the regression and performance tests, and portability.

In February, Marc Van Barel and I applied for a grant to the FWO
(Research Foundation - Flanders), without success. We are trying to get
some feed-back why we failed. I see other possibilities for funding,
which I will certainly try.

In the meantime, I would like to speed up the development of the project
by a call for developers. There are several aspects that can be
developed independently. If noone shows up, we may have a working suite
of vector concepts and algorithms only by the end of the year, depending
on my 'free' time.

I also would like to organise a meeting with those who are interested in
a more lively discussion than a mailing list.

Other suggestions to speed up a bit are welcome.

I must admit I am disappointed that there was not a single reaction on
my last e-mail. If the document was too hard to read, please tell me so
that I can improve it.


Best,


Karl

_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas

_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas

[Ed Hill-2]

On Thu, 24 May 2007 10:20:04 +0200 Karl Meerbergen wrote:
>
> I must admit I am disappointed that there was not a single reaction
> on my last e-mail. If the document was too hard to read, please tell
> me so that I can improve it.


Hi Karl,

I've been following the glas list (lurking).  I'd like to contribute
but have to admit I'm a little intimidated.  My C++ skills are OK (have
been using it on/off since the mid-90's) but cannot claim real
familiarity/comfort with template meta-programming in general or the
Boost MPL (and this seems to be a pre-requisite for GLAS).

Can you or someone else please recommend some good background material
and/or "warm-up exercises" for glas beginners?

Ed

ps - I have a copy of Barton & Nackman and will order Abrahams &
     Gurtovoy or other titles if its generally viewed as a good
     idea...

--
Edward H. Hill III, PhD  |  ed@...  |  http://eh3.com/


_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas

[Toon Knapen]

Maybe an even better idea would be to look into 'concepts'. There is a
lot of discussion on this in the comp.std.c++ and
comp.lang.c++.moderated newsgroups (as they will be integrated in future
standards) and they are already integrated in concept-g++ of Doug
Gregor. On his website you can also find links to articles on concepts.

t

Ed Hill wrote:

> On Thu, 24 May 2007 10:20:04 +0200 Karl Meerbergen wrote:
>> I must admit I am disappointed that there was not a single reaction
>> on my last e-mail. If the document was too hard to read, please tell
>> me so that I can improve it.
>
>
> Hi Karl,
>
> I've been following the glas list (lurking).  I'd like to contribute
> but have to admit I'm a little intimidated.  My C++ skills are OK (have
> been using it on/off since the mid-90's) but cannot claim real
> familiarity/comfort with template meta-programming in general or the
> Boost MPL (and this seems to be a pre-requisite for GLAS).
>
> Can you or someone else please recommend some good background material
> and/or "warm-up exercises" for glas beginners?
>
> Ed
>
> ps - I have a copy of Barton & Nackman and will order Abrahams &
>      Gurtovoy or other titles if its generally viewed as a good
>      idea...
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> glas mailing list
> glas@...
> http://lists.boost.org/mailman/listinfo.cgi/glas

_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas

[Karl Meerbergen-2]

Hi,

Thanks to all who have responded (via the list or privately) to my call
for developers.

I am currently writing some documentation, and am planning to write some
more documents on decisions that have been made so far, which would make
it easier for 'newcomers' to understand which work is done so far.
I do not make any promises about when the documentation is going to be
ready, since june and july are pretty fully scheduled.

Most of this stuff is/will be available on
http://www.cs.kuleuven.be/~karlm/glas/

Understanding STL, boost, and concept c++ are very helpful, but also
setting up a build system, regression tests, performance tests etc, are
very important tasks.

Best,

Karl

[Karl.Meerbergen.vcf]

---

begin:vcard
fn:Karl Meerbergen
n:Meerbergen;Karl
org:K.U. Leuven;Department of Computer Science
adr:;;Celestijnenlaan 200A;Heverlee (Leuven);;B-3001;Belgium
email;internet:Karl.Meerbergen@...
tel;work:[phone]
tel;fax:[phone]
tel;cell:[phone]
url:http://www.cs.kuleuven.be/~karlm
version:2.1
end:vcard

---

_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas

[Pieter Collins]

Dear Karl,

As the main co-developer on the main project I am working on recently
graduated and vanished, I appreciate that it's important to have support!

I would be prepared to contribute to GLAS, but only if this is directly
useful for my project. Since we have some rather specialised requirements,
maybe GLAS cannot support these. Here are the main issues:

Expressions: We would like a general-purpose expression template mechanism
which we can use throughout, and not just for linear algebra. For this we
need storage expression classes BinaryExpression etc and operator classes
Add etc. These classes are orthogonal to the linear algebra concept
classes ScalaVectorExpression etc, and could probably be combined using
multiple inheritance.

Mixed Arithmetic: We use mixed-mode arithmetic for our scalar types and
would like this to carry over to the linear algebra. For example, Integer
/ Integer -> Rational. Currently we implement this using type traits
similar to
  typedef division<Integer,Integer>::result_type Rational;
but perhaps a better system would be to use late binding
  divide(Rational&,Integer,Integer);
called by dispatching from
  Rational q = z1 / z2;

Renaming: Since we want a consistent interface, and use CamelCaps class
names, we need to rename the GLAS classes. As C++ does not (currently)
have a "typedef template" construction or similar, we need to use
inheritance and wrapping. How does this interact with the expression
templates system?

Algorithms: We would like to have LAPACK functionality classes/algorithms
for LU, QR, SVD, and Eig which are not restricted to LAPACK bindings. I've
finally gotten round to requesting space on Sourceforge for the TBLAS and
fledgeling TLAPACK templated routines, but these need a class wrapper, and
as I'm not a linear algebra expert, the TLAPACK functionality is minimal.
(Help wanted!!) We need wrappers for these C-style functions.

We currently have our own implementation of the minimal functionality we
need (currently not using expression templates) but it would be better not
to have to duplicate work, if our requirements can be met. (Otherwise we
might just adapt GLAS code from time to time.)

Best regards,

Pieter Collins
CWI, Amsterdam

_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas