|
|
Glas :Re: [glas] introducing the storage concept, a first interface specification |
From: Patrick Kowalzick (patrick.kowalzick_at_[hidden])
Date: 2005-01-20 08:11:24
>>>> to 1.)
>>>> For an effective algorithm it is not necessary that the data is
>>>> "globaly" consecutive. It might be enough that parts of the data are
>>>> "localy" consecutive. E.g. two matrices which are stored in several
>>>> vectors (rows or columns) can be added very fast iterating along the
>>>> vectors but not across the vectors (but only due to the cache).
>>>
>>>
>>>
>>> True. That was also (part of) the idea behind compound_storage. But
>>> suppose your matrix uses several vectors to store its elements, you
>>> still want to define _where_ these vectors are stored.
>>>
>>> For maximum flexibility you might want to store them on the heap (this
>>> would allow resizing, see later). But for performance reasons you might
>>> want them on the stack. This is less flexible however because the size
>>> is limited. When treating very large vectors that are too big to store
>>> in memory, you will have to store (part of) your vector in a file.
>>> _These_ kind of _optimizations_ are the most important idea behind the
>>> storage.
>>
>>
>> I do not agree, and the reasons therefor are simple: I do not see a
>> reason to chose where to save the data except with the direct use of
>> (simple) containers. But it is true that I do not have a reason against.
>> So my personal conclusion is easy: I have to test a little bit and try
>> some configurations......
>
>
> IIUC you don't agree that we need soth. like a storage? Don't you think it
> would be good to be able to specify if a vector should be stored on the
> heap or on the stack? What do you mean by 'simple container' in the above
> paragraph?
No, I believe it is very important to have the choice _where_ to store the
data, but this is a users view. I am not sure that an algorithm (developer)
needs to know _where_ the data is stored, but the algorithm must have the
ability to work efficient and needs the _how_.
An orthogonal design would imply for me, that a user can use any container
he likes (if adopted a lit to cary informations needed about the structure)
including boost::array (stack), std::vector (ok, inefficient constructing)
or a wrapper for an easy heap based array.
But, as long as I m not familiar with implementation designs I have to test
a little bit before, to make common implementation errors :).
>>>> to 2.)
>>
>> like 1.), I have to think.
>>
>>>> to 3.)
>>>> IMO, only if there is an information if a vector is resizable there
>>>> might exist a compile-time check if an addition between two
>>>> not-resizable vectors is possible. I do not have an example (and it
>>>> might not exist with expressions), but I can also imagine that some
>>>> algorithms might need resize and can not always work with a
>>>> constructor.
>>>
>>>
>>> I think we should respect the dimensions (or size) of the vectors and
>>> therefore I think operands first need to be properly dimensioned before
>>> using them in an operation. Thus adding 2 vectors requires that both
>>> vectors have the same dimension and thus respecting the laws of vector
>>> fiels.
>>
>>
>> I meant a different thing. If a vector could not be resized _and_ the
>> size is known at compile time (possible for stack based), there is an
>> information (concept?) needed, to enable compile-time error checking.
>
> I don't think it needs a concept. The error checking you are referring to
> can be done by using a BOOST_STATIC_ASSERT.
Ok. But this means there is a static size information needed. Is a
static size_type size() {}
like defined in boost.array enough? The implementation in ublas is slightly
different, but IMO not "clean".
Regards,
Patrick