Re: [glas] using (boost)range or STL style interface [was: dense and sparse vectors]
From: David Abrahams (dave_at_[hidden])
Date: 2005-08-02 13:56:47
Toon Knapen <toon.knapen_at_[hidden]> writes:
> Neal Becker wrote:
>> I have not followed the details of this discussion. I wonder,
>> though, if the use of "range" was considered as an interface,
>> rather than stl-style iterators. I have been making extensive use
>> of boost::range for all my container needs, and have found it to be
>> more useful than iterators.
> My feeling currently is that people are familiar with the STL style
> interface while not with boost::range. AFAICT both approaches however
> can coexist so there's no harm in supporting a range-style interface as
> However having both styles of interfaces complicates matters a bit
Yes, it does. So there is _some_ harm at least.
A sequence-based interface has real advantage in terms of
> (not everybody is familiar with boost:;range, possible
> portability-problems) in respect to the added value of having both
> styles of interfaces. Additionally the question of supporting
> range-style interfaces or not is *currently* IMHO not essential to
> the linear algebra capabilities. It is already very difficult to
> find consensus on IMHO more important issues like defining a generic
> interface for different types of sparse matrices etc.
Unfortunately, the issue of "iterators or ranges" goes right to the
heart of what the generic interface for a matrix looks like.
> So my feeling is to not consider it *now*. This does not exclude
> that it might be considered in the future. And this is of course my
> current feeling but I actually have not really a real strong opinion
> on the issue.
For what it's worth, the MTL4 project is using a Sequence interface:
which is similar to the Boost.Range interface, but generalized along
- Instead of iterators, we use cursors and property maps:
- Cursors are generalized so that the begin and end cursor for a
sequence need not be the same type. This generalization allows us
to do some really interesting things with fixed-size sequences,
unrolling operations on them completely at compile-time. It also
allows us to treat non-homogeneous sequences (e.g. boost::tuple)
as :concept:`Sequences`. [¹]
- We are supporting segmented cursors and property maps, per
http://lafstern.org/matt/segmented.pdf. Segmentation turns out to
be crucial for blocking, parallel decomposition, and efficient
operation on linearized CSR matrices.
[¹] We can also solve a nagging problem with many input iterators: a
special degenerate iterator value is often needed to use as the
end-of-sequence indicator, which complicates the iterator's
comparison operators and reduces their efficiency. There are a
few other neat tricks, too.
-- Dave Abrahams Boost Consulting www.boost-consulting.com