| 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 09:21:06 -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=r5qNEyETct2o6aLCaY0clOZRAM1h3N6du7rqDCtC114=; b=nZvE1eEYEUK4XrMOvA3N9fKCMZG3WGKTYAruujssEBIxoW3FzKjomleO37/cfrh54Z GIPKPIfe/1ZmhyzPKFraBRptvO77q9NGDO2Kir2cU3cScvtGwJw2aUMmi29z39lkehmv QVW4givJm2PDEFfEdOkfQoHlc+q0KN1abc1YM=
- 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=B+kuBU/v2L8+Tg6DxwAGvax0fnUCbROlcJBwTkMukXB8hTi5kulAb9q7hXo56K73CE xwOlSJjZVyLM9qKdpXgs2MLeLu6VEAe/tnyFhX0Mpty93UyoJ8AeF9aK4MCwXk8Tk/vF OOimW7HHJWl8vsDrW8SFxxAyXxpSnJoqPGjrw=
2nd round of thoughts: i'd really feel far, far better if this could
be done with only minimal changes to existing files.
I'm:
- OK to have this as Matrix< .... some Option >
- OK to add a reserve() method even if it's only used in this very special case.
but i'm more concerned about the changes in DenseStorageBase.h and
MatrixStorage.h. If these could be isolated into separate files that'd
be much better.
Benoit
2010/3/2 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 2010/3/2 Márton Danóczy <marton78@xxxxxxxxx>:
>> Hi,
>>
>> I have implemented an option for malloc-free matrices similar to
>> Matrix<Scalar, Dynamic, Dynamic, Options, MaxRows, MaxCols>, but
>> heap-allocated (i.e., potentially huge) and the max size not known at
>> compile time. My use case is real-time data processing on an iPhone,
>> where buffers are Eigen matrices that gets resized very often (every
>> time the input has been polled).
>>
>> 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.
>>
>> Would be great if someone could comment on the attached patch.
>> Unfortunately, the test suite is currently broken (in
>> test/mixingtypes.cpp),
>
> Fixed.
>
>> so I couldn't test it, but it works in my
>> project.
>
> I haven't yet looked very carefully at your patch but the idea sounds
> reasonable and implementing this as a matrix option is a plausible
> 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...
>
> I'll be waiting for other peoples opinions...
>
> Benoit
>
>>
>> Greets,
>> Marton
>>
>