| Re: [eigen] Qt's container support |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Qt's container support
- From: Keir Mierle <mierle@xxxxxxxxx>
- Date: Tue, 20 Jan 2009 08:52:46 -0800
- 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=HvPEbnubpVHUUSaZw2RTPmcoVJMYXcmiaLCOq6XnXOM=; b=JpO/r3pxyZ/D+2XtwPdXm8fhfWI+ndU93VoFGO1Coj1RhhYtGnG4GSHMt/5k1EaimM CjBIuUfkx/C1DkQdaGsnGQ5O0Qn5iE28BYGF2Y9HK+YU43SLRNMcV6MwRhX1zHUccBXQ VyA9IFDPvlwMzwwcSDHCoZPT3icFbJRFOP3ho=
- 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=JaWlQbD0rPaO0OUcryQFPd9o+ifD42dBCoG3ZWK//gJu8mJ70koBlSZm2tPUEukRpq MGyYu094qEBg/1u6O+p9pnpAJOsIS38nh3YLxqmaGRS8Vzn7kcfAro2yGI2+PUYML9MC 29wVAYtLNM5rfRV+cAcJPbT0c5l6hORm7r1sg=
On Tue, Jan 20, 2009 at 8:42 AM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> independently of the QVector::fill() issue I'm in favor to allow
> operator= to resize an uninitialized matrix. I'm pretty sure the
> unique argument was this if()....
>
> To make it clear to everyone, after this change you 'll be able to do:
>
> MatrixXf a;
> a = MatrixXf::Random(100,100); // will be ok
>
> but not the following:
>
> MatrixXf a;
> a = MatrixXf::Random(100,100); // will still be OK
> a = MatrixXf::Random(50,50); // NOT OK => use .set()
Why not? That's still an inconsistency. What's wrong with reallocating
here? These semantics still violate the principle of least surprise.
Keir
>
> Gael.
>
> On Tue, Jan 20, 2009 at 5:09 PM, Keir Mierle <mierle@xxxxxxxxx> wrote:
>> On Tue, Jan 20, 2009 at 8:03 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>> 2009/1/20 Keir Mierle <mierle@xxxxxxxxx>:
>>>> What is wrong with (a)? I'd like to have this anyway.
>>>
>>> In my understanding the main problem with (a) was that it would
>>> require operator= to start with an if() to check if the matrix is
>>> already initialized (so runtime overhead).
>>>
>>> Perhaps this argument isn't convincing: dynamic-size matrices involve
>>> runtime branching anyway eveytime you have to loop over their
>>> coefficients, so this if() is going to be negligible.
>>
>> Exactly. Also, I believe that in some cases GCC can prove that a
>> matrix is uninitialized even for dynamic sized matrices and skip the
>> if, provided operator= is inlined. This will require some
>> investigation, but my understanding is that the scalar promotion of
>> aggregates optimization phase will expose this (scalar promotion of
>> aggregates breaks structures up into individual basic types, exposing
>> many optimization opportunities).
>>
>>> It's true that this aspect of our API is one of the things that's
>>> causing the most trouble to users. I'm open to reconsidering it. But
>>> first: is there another reason for the current behavior that i
>>> forgot...?
>>>
>>> Benoit
>>>
>>>
>>>
>>
>>
>>
>
>
>