|
|
12
|
|
Hi all,
I am back to GLAS after a long break. Toon and I have spent quite some
time till the beginning of summer on getting a first vector kernel
right, but never finished it.
I am currently rereading the concepts. What I would like to do the
coming weeks is try and spend a day a week on the project.
I will try and separate concepts that are needed for the core
functionality and those needed for the implementation of the core in the
various backends that we currently have. Recall that the core
functionality is the implementation of BLAS like algorithms.
In the meantime Peter has worked on vector space concepts, which should
come in handy at a higher level than the core of GLAS.
Best,
Karl
--
Karl Meerbergen
Katholieke Universiteit Leuven
Department of Computer Science
E-mail: [hidden email]
URL : http://www.cs.kuleuven.be/cwis/research/nalag/Phone : +32 16 327700 (secretary)
Fax : +32 16 327996
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
|
|
I have had a look at the current GLAS doc and codes. Some cleaning is
wise and I would like to start with a fresh tree.
The concepts are going to be much slimmer than the current version. It
is my intension to hide concepts needed for the implementation details
as much as possible, and to move them to the backends. So, no iterators,
cursors etc as a member of VectorExpression or DenseVectorExpression.
The only exception is ContinuousDenseVectorExpression, where pointer
access is added which is needed for the blas backend. This is going to
be an example to illustrate how the code can be extended to vector
concepts with a specific data access, e.g. vectors stored on disk.
I think a first vector kernel can be ready pretty soon to allow some
basic blas1-type operations. Then, we see what needs to be added to
match and validate Peters vector space concept.
The idea is then to gradually enrich the concepts when more requirements
are added to GLAS.
Karl
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
|
|
On Wed, 22 Nov 2006, Karl Meerbergen wrote:
> I think we should consider this. Is concept-gcc stable now?
I think it is, although last time I checked there were some issues with
compile times that ought to go away in the final version. Aside from
spending a few hours reading the proposal, I have never used concept gcc.
Maybe someone else on this list has? My impression was though, it would
be the killer feature for linear algebra libs.
Cheers,
Ian
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
|
|
concept-gcc is an interesting "concept". It may reduce our development
effort.
But glas should compile with "old" compilers also. So, templated
functions and classes should perhaps have two headers: one for current C
++ compilers and one for concept-gcc. A variable GLAS_CONCEPT_SUPPORT or
something like that could enable or disable concept-gcc support.
Best,
Karl
On Wed, 2006-11-22 at 14:52 +0100, Ian McCulloch wrote:
> On Wed, 22 Nov 2006, Karl Meerbergen wrote:
>
> > I think we should consider this. Is concept-gcc stable now?
>
> I think it is, although last time I checked there were some issues with
> compile times that ought to go away in the final version. Aside from
> spending a few hours reading the proposal, I have never used concept gcc.
> Maybe someone else on this list has? My impression was though, it would
> be the killer feature for linear algebra libs.
>
> Cheers,
> Ian
>
>
> >
> >
> > On Wed, 2006-11-22 at 14:36 +0100, Ian McCulloch wrote:
> > > Hi Karl, Toon,
> > >
> > > Have you considered using Concept-GCC ?
> > > http://www.generic-programming.org/languages/conceptcpp/> > >
> > > Ian
> > >
> > > _______________________________________________
> > > glas mailing list
> > > [hidden email]
> > > http://lists.boost.org/mailman/listinfo.cgi/glas> > --
> > Karl Meerbergen
> > Katholieke Universiteit Leuven
> > Department of Computer Science
> >
> > E-mail: [hidden email]
> > URL : http://www.cs.kuleuven.be/cwis/research/nalag/> > Phone : +32 16 327700 (secretary)
> > Fax : +32 16 327996
> >
> > _______________________________________________
> > glas mailing list
> > [hidden email]
> > http://lists.boost.org/mailman/listinfo.cgi/glas> >
> >
> _______________________________________________
> glas mailing list
> [hidden email]
> http://lists.boost.org/mailman/listinfo.cgi/glas--
Karl Meerbergen
Katholieke Universiteit Leuven
Department of Computer Science
E-mail: [hidden email]
URL : http://www.cs.kuleuven.be/cwis/research/nalag/Phone : +32 16 327700 (secretary)
Fax : +32 16 327996
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
|
|
I see an immediate application of concept_map: glas::dense_vector
becomes a EuclideanVectorspace, e.g.
template <typename T>
concept_map EuclideanVectorspace< dense_vector<T> > {
real_type norm() const {
return norm_2(v) ;
}
T operator*( dense_vector<T> const& v ) const {
return dot( conj(*this), v ) ;
}
} ;
etc.
On Wed, 2006-11-22 at 14:52 +0100, Ian McCulloch wrote:
> On Wed, 22 Nov 2006, Karl Meerbergen wrote:
>
> > I think we should consider this. Is concept-gcc stable now?
>
> I think it is, although last time I checked there were some issues with
> compile times that ought to go away in the final version. Aside from
> spending a few hours reading the proposal, I have never used concept gcc.
> Maybe someone else on this list has? My impression was though, it would
> be the killer feature for linear algebra libs.
>
> Cheers,
> Ian
>
>
> >
> >
> > On Wed, 2006-11-22 at 14:36 +0100, Ian McCulloch wrote:
> > > Hi Karl, Toon,
> > >
> > > Have you considered using Concept-GCC ?
> > > http://www.generic-programming.org/languages/conceptcpp/> > >
> > > Ian
> > >
> > > _______________________________________________
> > > glas mailing list
> > > [hidden email]
> > > http://lists.boost.org/mailman/listinfo.cgi/glas> > --
> > Karl Meerbergen
> > Katholieke Universiteit Leuven
> > Department of Computer Science
> >
> > E-mail: [hidden email]
> > URL : http://www.cs.kuleuven.be/cwis/research/nalag/> > Phone : +32 16 327700 (secretary)
> > Fax : +32 16 327996
> >
> > _______________________________________________
> > glas mailing list
> > [hidden email]
> > http://lists.boost.org/mailman/listinfo.cgi/glas> >
> >
> _______________________________________________
> glas mailing list
> [hidden email]
> http://lists.boost.org/mailman/listinfo.cgi/glas--
Karl Meerbergen
Katholieke Universiteit Leuven
Department of Computer Science
E-mail: [hidden email]
URL : http://www.cs.kuleuven.be/cwis/research/nalag/Phone : +32 16 327700 (secretary)
Fax : +32 16 327996
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
|
|
Well, I used ConceptGCC many times and it works quite well now. The
fundamental concepts on the GLAS list, like ring and group, are
implemented with concepts now and compiled with ConceptGCC. I published
the results as technical report:
http://www.cs.indiana.edu/cgi-bin/techreports/TRNNN.cgi?trnum=TR638There is amongst others an example to compute the power function with
regard to an arbitrary binary function. There are different algorithms
for magma, semi-group, monoid and groups. The concept compiler
dispatches to the most appropriate.
In another paper still pending I did performance experiments and it
showed that the performance is the same as with gcc without concepts.
There were occasionally some minor problems with ConceptGCC but Doug
fixed most of them in the meantime. That said, the compiler is not in
perfect production mode yet but it is already extremely useful for
working with concepts.
Cheers,
Peter
On 22.11.2006, at 08:52, Ian McCulloch wrote:
>
> On Wed, 22 Nov 2006, Karl Meerbergen wrote:
>
>> I think we should consider this. Is concept-gcc stable now?
>
> I think it is, although last time I checked there were some issues with
> compile times that ought to go away in the final version. Aside from
> spending a few hours reading the proposal, I have never used concept
> gcc.
> Maybe someone else on this list has? My impression was though, it
> would
> be the killer feature for linear algebra libs.
>
> Cheers,
> Ian
>
>
>>
>>
>> On Wed, 2006-11-22 at 14:36 +0100, Ian McCulloch wrote:
>>> Hi Karl, Toon,
>>>
>>> Have you considered using Concept-GCC ?
>>> http://www.generic-programming.org/languages/conceptcpp/>>>
>>> Ian
>>>
>>> _______________________________________________
>>> glas mailing list
>>> [hidden email]
>>> http://lists.boost.org/mailman/listinfo.cgi/glas>> --
>> Karl Meerbergen
>> Katholieke Universiteit Leuven
>> Department of Computer Science
>>
>> E-mail: [hidden email]
>> URL : http://www.cs.kuleuven.be/cwis/research/nalag/>> Phone : +32 16 327700 (secretary)
>> Fax : +32 16 327996
>>
>> _______________________________________________
>> glas mailing list
>> [hidden email]
>> http://lists.boost.org/mailman/listinfo.cgi/glas>>
>>
> _______________________________________________
> glas mailing list
> [hidden email]
> http://lists.boost.org/mailman/listinfo.cgi/glas>
------------
Peter Gottschling, Ph.D.
Research Associate
Open Systems Laboratory
Indiana University
135 Lindley Hall
Bloomington, IN 47405
Tel.: +1-812-855-3608 Fax: +1-812-856-0853
http://www.osl.iu.edu/~pgottsch_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
|
|
On Wed, 2006-11-22 at 10:46 -0500, Neal Becker wrote:
> If someone wanted to play with concept c++, can it be installed in parallel to
> the normal gcc so as not to interfere?
Yes, it can be installed in parallel with GCC. I suggest putting it in
its own separate directory, then providing an alias such as "conceptg++"
for the ConceptGCC compiler executable. Otherwise, it is completely
compatible with GCC 4.1.1.
Cheers,
Doug
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
|
|
On Wed, 2006-11-22 at 14:52 +0100, Ian McCulloch wrote:
> On Wed, 22 Nov 2006, Karl Meerbergen wrote:
>
> > I think we should consider this. Is concept-gcc stable now?
>
> I think it is, although last time I checked there were some issues with
> compile times that ought to go away in the final version.
Yes. Thankfully, there are also some tricks to help improve compilation
performance. Of course, we are also working to improve compilation
performance and stability.
> Aside from
> spending a few hours reading the proposal, I have never used concept gcc.
> Maybe someone else on this list has? My impression was though, it would
> be the killer feature for linear algebra libs.
I believe Concept C++ could be a big help in the design and
implementation of GLAS, because it will allow you to ensure that the
concepts you write down are actually the concepts that you use, and
should make writing correct generic algorithms simpler. That said, you
should not depend on ConceptGCC as your only compiler: it is a prototype
for a not-yet-standard variant of C++. We have some experience with
writing generic libraries that provide the same behavior with and
without concepts. This allows us to develop with concepts (to make sure
we get things right) but deploy code that works on existing C++
compilers. This is the approach I would recommend, and of course we'll
be happy to help.
Although I am not well-versed in linear algebra, as the primary author
of ConceptGCC I will be happy to help with any questions or technical
issues regarding Concept C++ and ConceptGCC. I do lurk on the GLAS list,
but if I seem slow to respond to a query, please ping me directly.
Best Regards,
Douglas Gregor
Open Systems Lab @ Indiana University
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
|
|
> > Aside from
> > spending a few hours reading the proposal, I have never used concept gcc.
> > Maybe someone else on this list has? My impression was though, it would
> > be the killer feature for linear algebra libs.
>
> I believe Concept C++ could be a big help in the design and
> implementation of GLAS, because it will allow you to ensure that the
> concepts you write down are actually the concepts that you use, and
> should make writing correct generic algorithms simpler. That said, you
> should not depend on ConceptGCC as your only compiler: it is a prototype
> for a not-yet-standard variant of C++. We have some experience with
> writing generic libraries that provide the same behavior with and
> without concepts. This allows us to develop with concepts (to make sure
> we get things right) but deploy code that works on existing C++
> compilers. This is the approach I would recommend, and of course we'll
> be happy to help.
I agree that conceptGCC is a great help for checking concepts in GLAS.
It will reduce development time and keep models consistent with concept
changes (which is unavoidable at this stage).
>
> Although I am not well-versed in linear algebra, as the primary author
> of ConceptGCC I will be happy to help with any questions or technical
> issues regarding Concept C++ and ConceptGCC. I do lurk on the GLAS list,
> but if I seem slow to respond to a query, please ping me directly.
Thanks! That can be very helpful. I will have a look at conceptGCC the
coming weeks.
Karl
>
> Best Regards,
> Douglas Gregor
> Open Systems Lab @ Indiana University
>
> _______________________________________________
> glas mailing list
> [hidden email]
> http://lists.boost.org/mailman/listinfo.cgi/glas--
Karl Meerbergen
Katholieke Universiteit Leuven
Department of Computer Science
E-mail: [hidden email]
URL : http://www.cs.kuleuven.be/cwis/research/nalag/Phone : +32 16 327700 (secretary)
Fax : +32 16 327996
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
|
|
Peter,
One question that is on my mind for a while now is the following one:
the mathematical definition of e.g. magma is clear. When do two types
belong to the same magma? E.g. int + double is an operation between
different types but they belong to double. Is there a mechanism in your
concepts that takes care of this?
Another examples is vector<double> v, w ;
The expression v+w returns e.g.
add_vector< vector<double>, vector<double> >,
which is only evaluated at assignment, e.g. x=v+w.
Do you deal with this returntype in your concepts? I think this would be
very helpful.
Thanks,
Karl
On Wed, 2006-11-22 at 10:38 -0500, Peter Gottschling wrote:
> Well, I used ConceptGCC many times and it works quite well now. The
> fundamental concepts on the GLAS list, like ring and group, are
> implemented with concepts now and compiled with ConceptGCC. I published
> the results as technical report:
>
> http://www.cs.indiana.edu/cgi-bin/techreports/TRNNN.cgi?trnum=TR638>
> There is amongst others an example to compute the power function with
> regard to an arbitrary binary function. There are different algorithms
> for magma, semi-group, monoid and groups. The concept compiler
> dispatches to the most appropriate.
>
> In another paper still pending I did performance experiments and it
> showed that the performance is the same as with gcc without concepts.
>
> There were occasionally some minor problems with ConceptGCC but Doug
> fixed most of them in the meantime. That said, the compiler is not in
> perfect production mode yet but it is already extremely useful for
> working with concepts.
>
> Cheers,
> Peter
>
> On 22.11.2006, at 08:52, Ian McCulloch wrote:
>
> >
> > On Wed, 22 Nov 2006, Karl Meerbergen wrote:
> >
> >> I think we should consider this. Is concept-gcc stable now?
> >
> > I think it is, although last time I checked there were some issues with
> > compile times that ought to go away in the final version. Aside from
> > spending a few hours reading the proposal, I have never used concept
> > gcc.
> > Maybe someone else on this list has? My impression was though, it
> > would
> > be the killer feature for linear algebra libs.
> >
> > Cheers,
> > Ian
> >
> >
> >>
> >>
> >> On Wed, 2006-11-22 at 14:36 +0100, Ian McCulloch wrote:
> >>> Hi Karl, Toon,
> >>>
> >>> Have you considered using Concept-GCC ?
> >>> http://www.generic-programming.org/languages/conceptcpp/> >>>
> >>> Ian
> >>>
> >>> _______________________________________________
> >>> glas mailing list
> >>> [hidden email]
> >>> http://lists.boost.org/mailman/listinfo.cgi/glas> >> --
> >> Karl Meerbergen
> >> Katholieke Universiteit Leuven
> >> Department of Computer Science
> >>
> >> E-mail: [hidden email]
> >> URL : http://www.cs.kuleuven.be/cwis/research/nalag/> >> Phone : +32 16 327700 (secretary)
> >> Fax : +32 16 327996
> >>
> >> _______________________________________________
> >> glas mailing list
> >> [hidden email]
> >> http://lists.boost.org/mailman/listinfo.cgi/glas> >>
> >>
> > _______________________________________________
> > glas mailing list
> > [hidden email]
> > http://lists.boost.org/mailman/listinfo.cgi/glas> >
> ------------
> Peter Gottschling, Ph.D.
> Research Associate
> Open Systems Laboratory
> Indiana University
> 135 Lindley Hall
> Bloomington, IN 47405
> Tel.: +1-812-855-3608 Fax: +1-812-856-0853
> http://www.osl.iu.edu/~pgottsch>
> _______________________________________________
> glas mailing list
> [hidden email]
> http://lists.boost.org/mailman/listinfo.cgi/glas--
Karl Meerbergen
Katholieke Universiteit Leuven
Department of Computer Science
E-mail: [hidden email]
URL : http://www.cs.kuleuven.be/cwis/research/nalag/Phone : +32 16 327700 (secretary)
Fax : +32 16 327996
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
|
|
On Wed, 2006-11-22 at 12:32 -0500, Douglas Gregor wrote:
> That said, you
> should not depend on ConceptGCC as your only compiler: it is a prototype
> for a not-yet-standard variant of C++. We have some experience with
> writing generic libraries that provide the same behavior with and
> without concepts. This allows us to develop with concepts (to make sure
> we get things right) but deploy code that works on existing C++
> compilers. This is the approach I would recommend, and of course we'll
> be happy to help.
Do you have a document that describes this? I browsed through the
tutorial and I think I am getting an idea of how conceptc++ can help us.
But I do not see how a concept free version can coexist. I suppose I can
figure it out myself, but I am sure your help reduces the learning
process.
Thanks
Karl
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
|
|
Hello,
Here is an example that I find a strong feature that we can use in GLAS:
the function printout() does a conceptwise specialization without the
need for traits or partial template specialization.
Karl
#include <concepts>
#include <iostream>
concept Foo<typename T> {} ;
concept Bar<typename T> {} ;
template <Foo T>
void printout(T const& t) {
std::cout << "concept Foo" << std::endl ;
}
template <Bar T>
void printout(T const& t) {
std::cout << "concept Bar" << std::endl ;
}
concept_map Foo<int> {} ;
concept_map Bar<double> {} ;
int main() {
int i = 5 ;
double d = 6.0 ;
printout( i ) ;
printout( d ) ;
return 0 ;
}
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
|
|
Hi,
I think I found a way to develop the code with conceptc++ and still use
the c++ compiler using the current GLAS concepts. I will make a proposal
to the list later.
Have a nice day,
Karl
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
|
|
On Thu, 2006-11-23 at 15:06 +0100, Karl Meerbergen wrote:
> On Wed, 2006-11-22 at 12:32 -0500, Douglas Gregor wrote:
> > That said, you
> > should not depend on ConceptGCC as your only compiler: it is a prototype
> > for a not-yet-standard variant of C++. We have some experience with
> > writing generic libraries that provide the same behavior with and
> > without concepts. This allows us to develop with concepts (to make sure
> > we get things right) but deploy code that works on existing C++
> > compilers. This is the approach I would recommend, and of course we'll
> > be happy to help.
>
> Do you have a document that describes this? I browsed through the
> tutorial and I think I am getting an idea of how conceptc++ can help us.
> But I do not see how a concept free version can coexist. I suppose I can
> figure it out myself, but I am sure your help reduces the learning
> process.
I do not have any documents that describe how to do this. Between Peter
Gottschling and I, we should be able to write up some guidelines.
Cheers,
Doug
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
|
|
Hi Karl, On Nov 23, 2006, at 2:39 AM, Karl Meerbergen wrote: Peter,
One question that is on my mind for a while now is the following one: the mathematical definition of e.g. magma is clear. When do two types belong to the same magma? E.g. int + double is an operation between different types but they belong to double. Is there a mechanism in your concepts that takes care of this?
Good question. That is an issue that needs careful consideration. At the moment I only considered operations between arguments of the same type. There are some ideas but they are not worked out in detail. I see 2 approaches:
1. We can compute op(x, y) if T1 is convertible into T2 and T2 is a magma, or vice versa. This approach is probably more flexible but the risk is that the mixed operations on T1 and T2 must be semantically equivalent to operations on T2. Unfortunately, with automatic conversion, the programmer has no control whether the semantics of the mixed operations are held.
2. We introduce a concept like MixedArithmetic<Op, T1, T2, TA> that specifies that an operation of type Op on two arguments of types T1 and T2 are computed on type TA. Meaning: the arguments are converted from T1 and T2 into TA and the concept check is performed w.r.t. TA, e.g. AdditiveMagma<TA>. Most likely TA would be T1 or T2.
The second method seems to be semantically more controllable but is also kind of cumbersome. The best would be search together for a solution. I have no satisfying solution yet, only a very vague idea. Another examples is vector<double> v, w ; The expression v+w returns e.g. add_vector< vector<double>, vector<double> >, which is only evaluated at assignment, e.g. x=v+w. Do you deal with this returntype in your concepts? I think this would be very helpful.
That works. As long the return type is assignable to the vector type. You can write x=v+w. Rolf Bonderer and I did this for instance uBlas vector addition. He also defined some more concept_maps so that one could use more complex expressions, like x+= alpha * y;
If you add three vectors in one expression, e.g. x=v+w+z you run into the first problem (unless you write an explicit concept_map for this expression). I believe for expression templates exist also another general solutions to enable interoperability between the original type and intermediate results. However, if we find a good solution for the first problem it might work for ET, too.
Best,
Peter Thanks,
Karl
On Wed, 2006-11-22 at 10:38 -0500, Peter Gottschling wrote: Well, I used ConceptGCC many times and it works quite well now. The fundamental concepts on the GLAS list, like ring and group, are implemented with concepts now and compiled with ConceptGCC. I published the results as technical report:
There is amongst others an example to compute the power function with regard to an arbitrary binary function. There are different algorithms for magma, semi-group, monoid and groups. The concept compiler dispatches to the most appropriate.
In another paper still pending I did performance experiments and it showed that the performance is the same as with gcc without concepts.
There were occasionally some minor problems with ConceptGCC but Doug fixed most of them in the meantime. That said, the compiler is not in perfect production mode yet but it is already extremely useful for working with concepts.
Cheers, Peter
On 22.11.2006, at 08:52, Ian McCulloch wrote:
On Wed, 22 Nov 2006, Karl Meerbergen wrote:
I think we should consider this. Is concept-gcc stable now?
I think it is, although last time I checked there were some issues with compile times that ought to go away in the final version. Aside from spending a few hours reading the proposal, I have never used concept gcc. Maybe someone else on this list has? My impression was though, it would be the killer feature for linear algebra libs.
Cheers, Ian
On Wed, 2006-11-22 at 14:36 +0100, Ian McCulloch wrote: Hi Karl, Toon,
Have you considered using Concept-GCC ?
Ian
_______________________________________________ glas mailing list
-- Karl Meerbergen Katholieke Universiteit Leuven Department of Computer Science
Phone : +32 16 327700 (secretary) Fax : +32 16 327996
_______________________________________________ glas mailing list
_______________________________________________ glas mailing list
------------ Peter Gottschling, Ph.D. Research Associate Open Systems Laboratory Indiana University 135 Lindley Hall Bloomington, IN 47405 Tel.: +1-812-855-3608 Fax: +1-812-856-0853
_______________________________________________ glas mailing list
-- Karl Meerbergen Katholieke Universiteit Leuven Department of Computer Science
Phone : +32 16 327700 (secretary) Fax : +32 16 327996
_______________________________________________ glas mailing list
------------ Peter Gottschling Research Associate Open Systems Laboratory Indiana University 135 Lindley Hall Bloomington, IN 47405 Tel.: +1 812 855-3608 Fax: +1 812 856 0853
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
|
|
On Nov 22, 2006, at 5:13 AM, Karl Meerbergen wrote: I have had a look at the current GLAS doc and codes. Some cleaning is wise and I would like to start with a fresh tree.
The concepts are going to be much slimmer than the current version. It is my intension to hide concepts needed for the implementation details as much as possible, and to move them to the backends. So, no iterators, cursors etc as a member of VectorExpression or DenseVectorExpression.
That is an excellent idea. I think such specifics are needed in some implementations and eventually we need also concepts for such specific details.
However, I find it important that we find a set of basic concepts that is free of such details.
The only exception is ContinuousDenseVectorExpression, where pointer access is added which is needed for the blas backend.
Maybe you can split this into 2 concepts, one without pointer access and a refinement for blas with pointer access. This is going to be an example to illustrate how the code can be extended to vector concepts with a specific data access, e.g. vectors stored on disk.
I think a first vector kernel can be ready pretty soon to allow some basic blas1-type operations. Then, we see what needs to be added to match and validate Peters vector space concept.
The idea is then to gradually enrich the concepts when more requirements are added to GLAS.
Karl
_______________________________________________ glas mailing list
------------ Peter Gottschling Research Associate Open Systems Laboratory Indiana University 135 Lindley Hall Bloomington, IN 47405 Tel.: +1 812 855-3608 Fax: +1 812 856 0853
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
|
|
On Nov 22, 2006, at 9:14 AM, Karl Meerbergen wrote: I see an immediate application of concept_map: glas::dense_vector becomes a EuclideanVectorspace, e.g.
template <typename T> concept_map EuclideanVectorspace< dense_vector<T> > { real_type norm() const { return norm_2(v) ; }
That is an interesting idea to define a concept-dependent default norm. However, we have to consider potential conflicts for vector types that model multiple concepts with different default norms.
template <typename T> concept_map L1VectorSpace< dense_vector<T> > { real_type norm() const { return norm_1(v) ; } }
concept L12VectorSpace<typename Vector> : L1VectorSpace<Vector>, EuclideanVectorSpace<Vector> {}
One solution to resolve this conflict is to introduce a convention which norm is prioritized over the other (assuming we can agree on one).
concept L12VectorSpace<typename Vector> : L1VectorSpace<Vector>, EuclideanVectorSpace<Vector> { real_type norm() { return norm_2(v); } }
At any rate, I'm happy to get company on the algebraic concepts.
Best, Peter T operator*( dense_vector<T> const& v ) const { return dot( conj(*this), v ) ; } } ;
etc.
On Wed, 2006-11-22 at 14:52 +0100, Ian McCulloch wrote: On Wed, 22 Nov 2006, Karl Meerbergen wrote:
I think we should consider this. Is concept-gcc stable now?
I think it is, although last time I checked there were some issues with compile times that ought to go away in the final version. Aside from spending a few hours reading the proposal, I have never used concept gcc. Maybe someone else on this list has? My impression was though, it would be the killer feature for linear algebra libs.
Cheers, Ian
On Wed, 2006-11-22 at 14:36 +0100, Ian McCulloch wrote: Hi Karl, Toon,
Have you considered using Concept-GCC ?
Ian
_______________________________________________ glas mailing list
-- Karl Meerbergen Katholieke Universiteit Leuven Department of Computer Science
Phone : +32 16 327700 (secretary) Fax : +32 16 327996
_______________________________________________ glas mailing list
_______________________________________________ glas mailing list
-- Karl Meerbergen Katholieke Universiteit Leuven Department of Computer Science
Phone : +32 16 327700 (secretary) Fax : +32 16 327996
_______________________________________________ glas mailing list
------------ Peter Gottschling Research Associate Open Systems Laboratory Indiana University 135 Lindley Hall Bloomington, IN 47405 Tel.: +1 812 855-3608 Fax: +1 812 856 0853
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
|
12
|
Locked
