| 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:24:51 -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=FJrNYYqy6MbZxQxEJBQqosfDQjJTK7m0avtDvNwZJCo=; b=K+kWd1/+PySkIncBjKVJataQgLTTzmXwFKmL2impEhCdQS9G/3LBdDegAHFjgE9Kok kKTq1tJM+Gl40anMmiMScpmEf3ECVcXEqZFWJWLpRppSxNs9J9xJF9LVA1Xw4Ad60zrD QhY9YBLtIYvYst2VFx6Egay8SDBR/0afuqAkE=
- 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=YXNvJWsWqN+Cu0b/Y7EAv1lceG8WdrC9holAClsIAp/I1OHkOsmI2KlOQsdHOTpzIk HJj1mANy5K8lcZVmMhEy7QOjJVXKWpiA0ayVgow00MocKEDfoTBpNZr6vvQgA6AE6f4b enIQ6YV0SO/A9z+ysdx3YwJ8RXmTj8IhuZTsg=
....ok so thinking about it, what i'm saying probably implies that this
should, at least for now, be a separate class, a cousin of Matrix.
You could even try to implement it as a subclass of Matrix...
Benoit
2010/3/2 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 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
>>>
>>
>