|
|
Glas :Re: [glas] introducing the storage concept, a first interface specification |
From: Patrick Kowalzick (patrick.kowalzick_at_[hidden])
Date: 2005-01-20 03:29:06
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......
>> 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.
Regards,
Patrick