| Re: [eigen] Re: yet another deep change wrt storage orders... |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Re: yet another deep change wrt storage orders...
- From: Márton Danóczy <marton78@xxxxxxxxx>
- Date: Thu, 1 Jul 2010 13:47:32 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=vJ9Mn2yaaxQE9ymZn0jz3O8myBfG6xPIUQplTpe5omo=; b=ktxIp1Gz4kcVHD9Onyo4B0ymV3fC+5YZp8H5q33GD6OEkna/dgAspaKINGPni/xw9m r4J6m0peOpquddaOQWTRKNFOCPSjiiAUj+2PISTtXWXZJBdyA5m7Pok+ivdAEFo02MGT l92fMYp9DM3MeIBqnuUWErcEwUFo4Sjo2gyC4=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=f2Z27GTKaRJjTosGnlRzwyCpUXNyjre8s6RjCcW6anokS/Na/m8v5ZYvmP8pjAmi4u fwoPGbVH9oHGITH/291e73fNmjScZ01TZRlK0j3USX5TjjOddQbNuub92bnqI5DdLWjS aFbQ0k6kcxtS1uMV94vPMV12YFx7IJPn61gQk=
Hi Benoit,
I assume you've merged it in, because code that used to work earlier
doesn't compile now. For a data acquisition module I use arrays of the
form Array<Scalar, NCHAN, Dynamic, 0, NCHAN, MAXDATA>, where NCHAN and
MAXDATA are #defined in a config.h file and depend on the version of
the hardware I compile the code for. Now, if NCHAN==1, compilation
breaks, as Eigen expects me to provide the RowMajor flag. However, my
code relies on the data being column major.
Any ideas how to fix this? Is there a strong reason to not support
1-major matrices? Can I simply take out the respective assert in
DenseStorageBase or will something terrible happen?
Thanks,
Marton
On 9 March 2010 07:16, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> the fork is there,
> https://bitbucket.org/bjacob/eigen-storageorders/
>
> the basic change is done, but i wont merge it back until all the
> current issues are resolved.
> Benoit
>
> 2010/3/8 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>> as if we didn't have enough... ever since the RowMajor fixes from
>> january, we have quite some instability in the development branch:
>> there's always a little thing broken somewhere and fixing it results
>> in something else getting broken. Currently, what's broken is certain
>> matrix algorithms applied to 1x1 matrices.
>>
>> To summarize a little discussion that happened today over IRC:
>>
>> [17:30] <bjacob> the bottom of the problem is that our idea of
>> vector-specific functions that work seamlessly for row-vecs and
>> col-vecs, detecting 1xN vs. Nx1, completely fails on the 1x1 case
>> [17:30] <gael_> yep
>> [...]
>> [17:40] <gael_> but cannot the RowMajor/ColMajor mean RowVector
>> ColumnVector for the vector case ?
>>
>> With that gael stepped over one of my big taboos so i initially
>> psychically rejected his idea... then I realized he was right, this
>> actually simplifies a lot of code we have for vectors, and moreover:
>>
>> [19:26] <bjacob> gael_: wow, here's a very very good reason for it
>> too: let's constrain the Options to Matrix, to have the right
>> RowMajorBit. This prevents having 2 different vector types that differ
>> only by the (unused) RowMajorBit !!
>>
>> So i'll start that in a fork and report here...
>>
>> Benoit
>>
>
>
>