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 09:40:58 -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=XKuyBqn6QwIhT7ZcSAbxoujh7T4j2Z7HnJdEvlFPuoo=; b=EaAWAtzaLqXbs46MD38P296SMFfXnKoCkkyWiXqNpzATzT4R9HlWG5VPS07AngGO5m gSjMpNeptTnxoOI7F0GPYRG4DYfR+1oSaWiWtFd++Nk0LZU9uHhc05kHR+PJQ9XtCgfC ldmhfmj1mIzHxhpDFYdfyEk+N2+q7vljGpT+4=
- 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=TPaNCxFh88gjtuujFeG1XQi9W/OS85LTbMS8y+76wUBmPQUXL9C+58vkStvtGJNfBS H4eXfirbSVc681hAXdRY5nsCAtmSLMvlzlwVzq1GCnyuvoioXKsx/WPIx7Lb/s/R4/5+ becqIHAiCOPCr2fklLV48nvPbwGFqwCKm/k/U=
Crashing on unaligned matrices is something that should both a) be
caught at compile time for fixed size matrices and b) work as expected
for assignments involving operator=, which is to say, it should
reallocate.
I argue that the majority of the time, users want operator= to do the
obvious thing (reallocate when necessary). If there is a need to have
aligned matrices, then that should go in the less-obvious set()
function inside the API. I thought there was some deep reason to do
with templates that the operator= / set() duality exists; now that I
see there isn't, I'm rather opposed to the current behavior.
The current operator= / set() confusion is not worth it considering
the marginal gain in safety.
What about A.noresize() = othermat to prevent allocations?
Keir
On Tue, Jan 20, 2009 at 9:28 AM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> this was the initial behavior, see this thread to see all the
> arguments which lead to the addition of set():
>
> http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2008/10/msg00040.html
>
> On Tue, Jan 20, 2009 at 5:52 PM, Keir Mierle <mierle@xxxxxxxxx> wrote:
>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>