| Re: [eigen] issue 77: map with stride |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen <eigen@xxxxxxxxxxxxxxxxxxx>
- Subject: Re: [eigen] issue 77: map with stride
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Mon, 18 Jan 2010 13:07:02 +0100
- 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=XHUTMXiOHeMT/JbvOlljrnnSv5rjhOXhC9JRQvPwAxs=; b=Ca5lKVGoZ56vf5PkBc9Yqv5qLoehDRUytshvXCuLNXRMN26D+Ba2gWEmxf6iBpJMhR jzeboYeZMVATZnrCXaQT5O5JhxYBq/nEHrqsQANWo8I3hujSA7VUFF7mO6SLUBdAIveQ ll5AKnlfZq2zHuVcfv0Ar8c+ULP/4Ep583cgA=
- 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=uEdWME052Ombp0jKUqD6wzqy0vt6Rs3mbwAo+LviWaF5UnHRu9vntPQ+1n1U7BUu6U fyFkijRo3iPoryE9t60md4+huegDO+73tM7DJjTyWJ7BoMa6/ThKERt+7jWbRlnFMVDq yAqnC7o4B0DqfSBrkmx4YrR2n3YwcRJ5xKfH8=
On Mon, Jan 18, 2010 at 6:25 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> Finally, regarding the RowMajorBit flag, here is a proposal: What about add a ColMajorBit flag (i.e., RowMajorBir=1 and ColMAjorBit=2). For vectors we would ensure that Flags&(RowMajorBit|ColMajorBit)==0, and expressions having no preferred orders like some matrix products and binary ops between a colmajor and a rowmajor matrices could have both bit flag.
>
> This is a bit more elegant than our current design, yes.
>
> This can also lead to a slightly better logic determining storage
> orders, for example in:
>
> RowMajorMatrix + ColMajorMatrix + ColMajorMatrix2
>
> the first + could say "i dont care about the storage order" so the 2nd
> + chooses column-major. But I don't see that happening a lot in
> practice.
>
> FYI, I spent time thinking if/how we should do such a change also to
> the Options parameter of Matrix. The answer is no:
> - 0 must stay the default value in all cases including matrices, as
> this is a bit field touched by the user.
> - so 0 would have to mean "column major, and nevermind if it's a vector"
> - so a column-major matrix could have either 0 or ColMajor here.
> - that's 2 separate types meaning exactly the same thing: a recipe to
> generate redundant template instantiations. Bad.
>
> So in all cases, the Options template parameter to Matrix stays as-is.
> So there would be a discrepancy between it and MatrixBase::Flags.
> Perhaps that negates the elegance benefit of the proposed change to
> MatrixBase::Flags?
Indeed, it would be quite unfortunate that ColMajor would be different
than ColMajorBit... On the other hand, I'm not sure that 0 really has
to mean ColMajor, and I think that the following exclusive set of
flags could work well:
- ColMajor = ColMajorBit
- RowMajor = RowMajorBit
- NoMajor = 0
Indeed, let's have a look at the three reasons a user has to play with
the Options parameter:
- the user wants a row major matrix => no change
- the user wants to add the DontAlign option => if that's a column
major matrix he must "or" it with ColMajor and he can keep DontAlign
alone for vectors.
- the user wants to set the default values of MaxRows and/or MaxCols
=> he must use ColMajor while currently he can also write a
meaningless "0". If the actual matrix type is a vector, then he can
either use Align, NoOrder, or... "0".
Here the points are that:
1 - such a change makes Matrix declarations more explicit,
2 - the two cases where the user would now have to bother about
explicitly setting ColMajor are extremely rare uses cases, so that's
no big deal.
Of course wrong values of Options would be cough at compile time.
Finally, I agree that:
"If the actual matrix type is a vector, then he can either use Align,
NoOrder, or... 0."
is still not perfect. Perhaps the "NoOrder" is not needed, or maybe
you have a better name to propose ?
gael