[SciPy-Dev] GSoC 2018 : Rotation formalism

Hanno Klemm h.klemm at gmx.de
Mon Feb 26 15:52:57 EST 2018


Hi Nikolay,

probably, I didn’t make myself clear enough. I don’t want to advocate that we try to implement any non-3D rotations in this GSOC. All I wanted to do, is to mention that it might be useful, if we think about the possibility of other rotations, when we design the underlying classes. Something along the line of

class Rotation() #general thing

class Rotation3D(Rotation)

class Rotation2D(Rotation)

I am not completely sure, if this really does make sense, but I think having the fact that 3D rotations are an (important) special case of a more general concept in the back of our minds might help to make good design choices.

As I said, just a thought,

Best,
Hanno




> On 26 Feb 2018, at 19.15, Nikolay Mayorov <nikolay.mayorov at zoho.com> wrote:
> 
> Hi, Hanno!
> 
> I personally don't feel comfortable at all doing anything with rotations in higher than 3 dimensions. Intuitively seems too abstract for a numerical methods library. You mentioned Lorentz transformation, I recall it might be considered as a rotation, but not even in Euclidean space. I think it's too tricky to go to higher dimensions, but perhaps some student can pick it up.
> 
> But Rotation2D might be a useful little addition, although I'm not sure if it is truly necessary, as it is so simple.
> 
> Thanks for your input,
> Nikolay
> 
> 
> ---- On Sun, 25 Feb 2018 19:20:38 +0500 h.klemm at gmx.de wrote ----
> 
> Hi Vishai, 
> 
> from a user’s point of view: Please don’t create a vector class: Just one more casting I have to keep track off. 
> 
> On a different note: Although of course 3D rotations are most common (and many complexities such as Euler angles and so forth are mostly done in 3D only), it might be a good idea to design the underlying framework in such a way that it can be used more generally: A rotation is essentially only an application of a particular representation of a continuous group (potentially plus a discrete transformation such as reflection). If we can think of a well thought out design, it might be easier, to subclass to nD rotations (I need a lot of 2D rotations, for example), and even Lorentz transformations for special relativity. Although the implementations might require tricky special cases, the underlying concepts are quite similar. 
> 
> Just a thought, 
> Hanno 
> 
> > On 25 Feb 2018, at 13.25, Nikolay Mayorov <nikolay.mayorov at zoho.com> wrote: 
> > 
> > Hi, Vishal! 
> > 
> > Sorry, but I don't like this idea about Vector. And I don't think anyone will like it. A vector in 3D is just a numpy array with 3 elements, it has powerful and well designed API and supports all operations you have listed (besides transforms, which should be applied to it in some way). Also I believe we should represent a set of n vectors as (n, 3). 
> > 
> > As for your second point, it is not super clear as stated. I don't think you need to make each rotation representation a "first-class citizen". For example, Euler angles are convenient for defining or interpreting a rotation, but to compose or apply rotations you can't use them directly. Please consider carefully the design I proposed and read the two first references to get a better intuition. If you see any flaws in it - we are ready for discussion. 
> > 
> > Best, 
> > Nikolay 
> > 
> > 
> > ---- On Sun, 25 Feb 2018 16:53:55 +0500 vishstar88 at gmail.com wrote ---- 
> > 
> > Here's a bunch of ideas that I have 
> >     • Create a new Vector class primarily for vector algebraic operations (instead of numpy arrays). 
> > This could be used any and every vector operation. 
> >         • Vector Product 
> >         • Scalar Product 
> >         • Translation 
> >         • Rotation (Different methods for each formalism) 
> >         • Magnitude 
> >         • Distance from other Vector objects 
> >         • Convert to and from numpy array 
> > (This could probably be extended to a Plane class for planar operations and transformations) 
> > 
> >     • Create a module in scipy.spatial.rotation that has a different method for each formalism and accepts (vector to be rotated as) Vector or numpy.ndarray along with arguments for the rotation as a numpy.ndarray 
> > 
> > 
> > Thanks, 
> > Vishal 
> > 
> > PS. Sorry for 2 mails. Didn't realize Ctrl+Enter sends a mail in Gmail 
> > 
> > 
> > _______________________________________________ 
> > SciPy-Dev mailing list 
> > SciPy-Dev at python.org 
> > https://mail.python.org/mailman/listinfo/scipy-dev 
> 
> _______________________________________________ 
> SciPy-Dev mailing list 
> SciPy-Dev at python.org 
> https://mail.python.org/mailman/listinfo/scipy-dev 
> 
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev



More information about the SciPy-Dev mailing list