Re: [eigen] Malloc-free dynamic matrices |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Malloc-free dynamic matrices
- From: leon zadorin <leonleon77@xxxxxxxxx>
- Date: Wed, 3 Mar 2010 01:30:43 +1100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=HRbe47ZIhw0VOLrtmpA9SuKZVs5I1QPDMsBlPRvAX0s=; b=qb+35v9G/xE5ZgN2V16ezpyxKFYMgS0jafxC9Ol37NRqVWM8eNvJS9xlXFAoQczAxG UFvK2Wbn47RrCiZxDXMlYaPzZo8UdcIL8V8QyorHgN0vhqqICo1mEf94/Qh0P7LwQ/Kx oKHyZ+1qU29j8HOD6Do+00kPzM6NVN0ZgnI/A=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=oftAzJ89eOkmwZz+sXPKQ5ruDlG6AizRvxlNAYaVGuuJlKW9D3v4bh2LfA3rhw8Ipr roQhhig6CJXasL7D8s4BYKKnV8vaIXS17h+kTiiY7nz4xh7lVr4QUAipvUYOFbdh40AU LsLc+nywsIryjJyNOeNXsv1oFVcB5C73Abmkc=
On 3/3/10, leon zadorin <leonleon77@xxxxxxxxx> wrote:
> On 3/3/10, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> 2010/3/2 Márton Danóczy <marton78@xxxxxxxxx>:
> [...]
>>> The only API changes are a new option NeverRealloc (the name is maybe
>>> not the best) and a method reserve(int size) that allocates the
>>> memory. Then, a Matrix<Scalar, Dynamic, Dynamic, NeverRealloc> keeps
>>> track of its allocated size via the member variable m_size and each
>>> mat.resize(rows, cols) only changes two ints instead of actually
>>> allocating memory. If rows*cols < m_size, an assertion error is
>>> raised.
>
> [...]
>
>> approach... my main concern right now is that it's touching and
>> complexifying a few very central places in Eigen, whereas the use case
>> is very special. For that reason I wonder if this should rather be
>> implemented as a new separate variant of the Matrix class itself...
>
> And if it is a special/rare case usage, would it not be possible to
> already achieve this behavior with a custom pre-allocated block of
> memory and then instead of using matrix type simply using the
> object(s) of Map<> type?
>
> The "mapped" matricies would not need explicit resizing in the first
> place... and reserving of the max size is simply done at allocation of
> the very original memory slab -- as per current API and it's
> capabilities?
To clarify -- I'm getting at saying that one may not need patching
anything in eigen in the first place, and by simply using the
already-existing API of Map<> objects one could achieve what the
original poster wanted :-)
> I suppose an adapter pattern may be deployed to create custom class --
> but it's internals would/could still rely on the Map<> semantics...
>
> Kind regards
> Leon.
>