|
|
Glas :Re: [glas] introducing the storage concept, a first interface specification |
From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2005-01-20 06:34:18
Patrick Kowalzick wrote:
> Hi Toon,
>
>>> 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?
>>> 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.