| 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: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Tue, 2 Mar 2010 12:16:01 -0500
- 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=Y+dzG49GJx/iRdpmy3N+D2eITCxrUHXOJW+i4UonPCE=; b=AlC2UrMF/bArav2pBIJnXV+mbJf6ojALwXrmAPgIF04SGcK5pYGfy0U/ZWK5ghYyb8 wtjN2dMVYu0dxHbEaZN48XDeXDyM6GabQFuKb2toaapzK5XAfhprN2vuSoKT878fOCbo s2lgllgkTDuXZmds4cKgnFoNItRTQB66ZvlcI=
- 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=wELr3SwHfh7v8/WnETHS/rXY/++UWpONmMzdZjuECA+iTPBsfO7GidC9LetJJQOvrA aZj/ELpIYqZuyxZ0M8Mu9GtfOCns22+IrPP1WdYZLCY4R1OyDdnBCihEp7eg8VQC+9A9 be4I9gDRkysDHvXXZQ1eycq+Nn6ctyxbpXsXY=
2010/3/2 leon zadorin <leonleon77@xxxxxxxxx>:
> 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 :-)
Yes, that sounds like a very good idea. It may require minor API
additions to class Map to make it convenient for Marton, but that's
still much lighter than the proposed patch.
Benoit
>
>> 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.
>>
>
>
>