Re: [eigen] Patch to AlignedBox |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Patch to AlignedBox
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Thu, 11 Oct 2012 19:16:42 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=6QP7wo5XYbRfHzig8Kn3hbIt3AjQei/35Mnq/uLCCXk=; b=aO/8zAlmGCQlothkgJWbdcedf4NO4yDaxp7LRly4AEHI1S62IVrGzTET2eyi88L3RC oUzHUQQO9wuk8SXP/grzYz3vs5Fn72kZk2mCyRc9WtOZo79Zk3uG8B14pSQvYfVUSqlp Pm3nVWPqJbML1id6kmHoAPYjQ3BNwb0sZ+/NWDi1bo///VP/t1w3fruAlglwa5oscSw9 hJYJ4FdWdUrfiPTjifejXoBPwWAzemxY+6sVq7TOB3SaxE4w9R7B92Sw1y0Xd9yf7PkF a/0Nw0RSp8+tC7rEx1JDkX+0gdBXbuKcoPf7UfYHNrOoj51DSPSDZcbitqN0xWYz2RdR e/ww==
On Thu, Oct 11, 2012 at 10:50 AM, Wood, Tobias <tobias.wood@xxxxxxxxx> wrote:
> Hi Gael,
> Thanks for the response.
>
>> what's the use case for "expand"?
> In this case I am using an AlignedBox3d to keep track of the view limits for an OpenGL volume rendering application. I implemented zooming into/out of the volume by expanding/contracting the AlignedBox. AlignedBox already has a translate() method, so I thought it was odd that is was missing some way to scale it as well.
ok, why not.
>> (I think "scale" would be less
>> misleading since we already have a "extend" function with a totally
>> different behavior)
> I completely agree.
>
>> Regarding CornerMatrixType I think it should be a fixed size matrix
>> instead of a dynamic one.
> For some odd reason when I wrote it the first time I convinced myself you couldn't compute the matrix size at compile time. But obviously you can, so I've actually made this change already by defining:
> typedef Matrix<Scalar,AmbientDimAtCompileTime,1 << AmbientDimAtCompileTime> CornerMatrixType;
good.
>> Finally, regarding the new names, I'd rather sort the words in X, Y, Z
>> order, what do you think?
> This is unfortunately a matter of personal preference. I think that X, Y, Z is the more logical ordering. However the 2D names are currently defined in Y, X order, so I went Z, Y, X for consistency. Perhaps it is also more common to say "Bottom Left" rather than "Left Bottom" in daily usage? To make it even more confusing, the 1D names are "Min" and "Max", which don't correspond to any particular axis but are more general. I would argue the most important thing here is consistency, so which ever ordering is chosen the 1D and 2D names should match.
ok, I forgot about the 2D names.
> Is there some way to mark the old names as deprecated, beyond a comment in the code and note in the documentation?
in the doc use \deprecated, and in the code there is a
EIGEN_DEPRECATED macro, but it won't work for individual enum name, so
we can only mark it in the doc.
also, your new function could probably call corner() instead of
duplicating the code.
cheers,
gael
> I'm happy to submit an updated patch once the above is decided on.
>
> Best wishes,
> Toby
>
>