| Re: [eigen] State of the problem with std::vector |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] State of the problem with std::vector
- From: "Benoit Jacob" <jacob.benoit.1@xxxxxxxxx>
- Date: Thu, 8 Jan 2009 21:40:44 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=KuWorTIxVi5qVhJGk8PBbeaZliyyd/cTO3w5MsEpADw=; b=x1NbQGVUoEFe3NEuNcAh2tXOUefauV2KdwnT0FzRTaSMzm1VenKRSZZWU7OcOZ9z+q 1MYPkREhZAGULOhWUJxBfg8OOp3icAiCAzH/f9k0vE98XsFG9M/bddIi6fAgGgc+5+nu MSR6nTC1dCkhUGY/zm6dp3E8bGzBkqdAgxi8s=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=tjDye57Hy99RDRHbMbCMLgL1SwF4tXL5ZQMHIOA4qSoQLAAvlMHb3tW+jkWy3RuVjR Hmt2rOTyhaEwo1oxl0E4O3tXy+pfbn/Sq5Ow2QMyCHBrFt9uMS92VdYitnjDlm+qm8T+ SO/wav+0Y4sF4iaMWaUHU+vWcwv+8rLyvAiwg=
2009/1/8 Keir Mierle <mierle@xxxxxxxxx>:
> A "non-solution" is to not use Vector4f. Instead use Matrix4Xf, which is
> fixed at 4 rows and X columns; each column is a different vector. I use this
> all the time in libmv to represent a collection of 4D vectors (homogeneous
> in my case). This is also handy for bulk transforms that take advantage of
> vectorization (i.e. by multiplying by a matrix).
This is perfect for users for whom this is an option, of course. But
it doesn't do all what std::vector does (insert...) and many users
simply have to use std::vector.
> On another note: Does eigen have shorthands for small numbers of rows /
> colums, but variable numbers for the other? i.e. 4 x n, or n x 4, etc?
Not for now.
> I
> have defines for Mat2X...Mat5X, MatX2...MatX5 in libmv for exactly this
> reason. Lots of convenience typedefs are great! Promotes mutual
> understanding for users of the library if they don't have to make their own
> different typedefs.
One has to find the right compromise between this, and the fact that
we already have a large number of typedefs and this proposal would
make it even much larger. Here before taking any decision what's
needed is a measurement of the impact on compilation time. If it's
costly one can still consider a separate header Eigen/MoreTypedefs.
Cheers,
Benoit
---