Re: [eigen] conservative resize ... |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] conservative resize ...
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Mon, 7 Sep 2009 09:16:03 -0400
- 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=hwDCQvOYyr+cmLGjNJ+vI17rBBiFNRFjlJw9GkGuCv8=; b=Q0WLjkoTRcE66yAxb1uGlAGsrZE9lEbsEF8M1C8H/zXOfStsoKIgypd439PHFQAOK5 t7jYU4eQvWrUk8wDuA0+dV6ArY6fhTbu5mV7ATCqSCyuPn7fLmRQ+D9zCxQyvej4AcwT 4kP4fac62xpcfLAVqwLpvhcP0zlMylJ8wTui0=
- 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=QwsODTCXMGugA1b8EAJwFPCWqbyy1TZUZryeZZlvxZMGwa4kIDNyeRmFH15+Zs3nAm PT8WhdN+R+0GNGRPUc9O5LX4GCe9H6SITZ/QJ2zHUqVPvrqtUTInuY5JdNMcZcrTwr7u BsAxmOHiBln/g3RUyLCARpgonwuan2LODlMBc=
+1 from me too!
About why NoChange_t is a struct as opposed to a special enum value,
it's because someone objected that it was dangerous to overload with
respect to the difference between enum and int. About why it should be
a different type, it was because we wanted that choice to be resolved
at compile-time rather than at runtime, otherwise all resizing would
have to do an if() which was not optimal as we have a lot of trivial
resizing calls that should have zero cost.
Benoit
2009/9/7 Márton Danóczy <marton78@xxxxxxxxx>:
> great idea, +1!
>
>
> 2009/9/7 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> hi,
>>
>> what about the following:
>>
>> - we keep only the two simple conservativeResize() overloads taking
>> only size arguments
>>
>> - we add one template overload:
>>
>> template<typename OtherDerived>
>> void conservativeResize(const MatrixBase<OtherDerived>& other);
>>
>> resizing *this to match the sizes of other, and filling the extended
>> parts from the respective parts of other. Typical use cases:
>>
>> Mat m;
>>
>> // ...
>>
>> // extend with 0 (similar to the current m.conservativeResize(r, c, true))
>> m.conservativeResize(Mat::Zero(r,c));
>>
>> // extend with x:
>> m.conservativeResize(Mat::Constant(r, c, x));
>>
>> // and some more complex examples:
>> m.conservativeResize(Mat::Identity(r,c));
>> m.conservativeResize(Mat::Random(r,c));
>>
>> The drawback is that it makes the "extend with zeros" a bit more verbose..
>> Alos, perhaps conservativeResize() is not a very good name for this
>> overload, but what do you think about this idea ?
>>
>> cheers,
>> gael.
>>
>>
>>
>> On Mon, Sep 7, 2009 at 1:52 PM, Hauke Heibel<hauke.heibel@xxxxxxxxxxxxxx> wrote:
>>> On Mon, Sep 7, 2009 at 1:34 PM, Márton Danóczy<marton78@xxxxxxxxx> wrote:
>>>> You're right, initializing a matrix after resizing should suffice, if
>>>> it is not slower than doing both in one step.
>>>
>>> It is possible and would probably be even faster - if done correctly.
>>> I am just saying this because you would need to take care of
>>> initializing only those parts of the matrix which are yet
>>> uninitialized. At the moment, when pre-initializing with zeros, the
>>> parts of the old and resized matrices that overlap are accessed twice.
>>> Once for initializing with zeros and a second time to copy the old
>>> values.
>>>
>>> @Benoit, ExtendByZero is fine. I am just wondering, was there a
>>> particular reason for making NoChange_t a struct? Should we follow the
>>> same strategy to ExtendByZero?
>>>
>>> - Hauke
>>>
>>>
>>>
>>
>>
>>
>
>
>