| 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: Alex Stapleton <alex.stapleton@xxxxxxxxxxxxx>
- Date: Tue, 20 Jan 2009 17:28:28 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=iljWs1KbGqVypdWEWB80uNQHGAIimL28VVPdHy1Xa0A=; b=PEHbZUlelAwD8QN5mclsRimciPfjjADWpFg+Q8r6MLqK4hgEZjqVOaicn53B9SgpgM oFMzr6BIm0k0u9i3hShLb2RZ4oS6NfJ+2VouQf8U/byQD0xYEghtUBR3id2EH2Uv5E8I RDx/CvM7hJbKgJYdOpON8YEtwhBq8UnAUcSmQ=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=oT1Cr3PpenCUtFsxnwe9mjyY0khbDlYAYLSG0fMJGD8zHD4r5xH7YQ5H4rx+Tda4wB gQvm4Www1KzprhT38Q5ys1vglp8FwR1CciwSPhQm9B5xq0gW5fuiXd0gNhCTzHw9VTpF DcPeIs1wlB6j8WRgxDrUII0+JkAauGAZ10RVI=
2009/1/20 Keir Mierle <mierle@xxxxxxxxx>:
> 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.
+1
> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>