Unless anyone objects, I'm going to continue with what I'm working on with QuaternionRotation and create a merge request. That way, we'll at least have a reference implementation and baseline functionality for commons-geometry that we can modify later based on what's decided here.
-Matt ________________________________ From: Gilles <gil...@harfang.homelinux.org> Sent: Saturday, December 1, 2018 9:40 PM To: dev@commons.apache.org Subject: Re: [Numbers][Geometry] Where to define "quaternion" (Was: Making Quaternion a VALJO) On Sat, 01 Dec 2018 12:56:34 +0100, Gilles wrote: > Hello. > > On Sat, 1 Dec 2018 06:05:31 +0000, Matt Juntunen wrote: >> Hi guys, >> >> FYI, I've been working on a quaternion-related class named >> QuaternionRotation for commons-geometry (see link below). It >> includes >> slerp as well as several other geometry-oriented methods, such as >> conversion to/from axis-angle representations and creation from >> basis >> rotations. It's not quite ready for a merge yet since I still need >> to >> finish the Euler angle conversions. >> >> I did not use the Quaternion class from commons-numbers since I >> wanted to focus solely on using quaternions to represent 3D >> rotations. >> I felt like the commons-numbers class was too general for this. > > We need to explore further how to avoid duplication. > > Some questions: > * Should "QuaternionRotation" inherit from "Quaternion"? > * Should "Quaternion" be defined in [Geometry] (and removed from > [Numbers])? > * Are some utilities defined in "QuaternionRotation" general > such that they could be part of the [Numbers] "Quaternion" API. > An example might be the transformation between quaternion and > matrix (represented as a double[3][3])? > > The second consideration could apply to any computation that does > not require types defined in [Geometry]. For example, interpolation > is a purely quaternion-internal operation. s/second/third/ > > It looks to me that it should be possible to come up with a design > that defines "rotation" in [Geometry] which uses a "quaternion" > defined in [Numbers]. > Otherwise, one would wonder why "Complex" is also not in [Geometry] > (for 2D rotations). > > Best regards, > Gilles > >> >> Regards, >> Matt >> >> >> >> https://github.com/darkma773r/commons-geometry/blob/transforms/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/QuaternionRotation.java >> >> [https://avatars1.githubusercontent.com/u/3809623?s=400&v=4]<https://github.com/darkma773r/commons-geometry/blob/transforms/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/QuaternionRotation.java> >> >> >> darkma773r/commons-geometry<https://github.com/darkma773r/commons-geometry/blob/transforms/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/QuaternionRotation.java> >> Apache Commons Geometry. Contribute to darkma773r/commons-geometry >> development by creating an account on GitHub. >> github.com >> >> >> >> >> ________________________________ >> From: Gilles <gil...@harfang.homelinux.org> >> Sent: Friday, November 30, 2018 9:37 AM >> To: dev@commons.apache.org >> Subject: Re: [numbers] Making Quaternion a VALJO >> >> On Fri, 30 Nov 2018 14:22:45 +0000, Steve Bosman wrote: >>>> > and I have also emailed an ICLA. >>> >>>> Not received/acknowledged yet. >>> >>> I am now listed on the "Persons with signed CLAs but who are not >>> (yet) >>> committers." page. >> >> Welcome! >> >>>> > I think two convenience divide methods performing qr^{-1} and >>>> r^{-1}q >>>> > for q >>>> > and r would be useful, but I couldn't think of nice names for >>>> them. >>> >>>> What are the use-cases? >>>> Why aren't "multiply" and "inverse" enough? >>> >>> I must admit I'm new to quaternions and stumbled into the project >>> while >>> trying to improve my understanding so I'm not going to claim great >>> knowledge of how common these operations are. I was primarily >>> thinking of >>> Quaternion Interpolation - SLERP and SQUAD. It seems to me that you >>> end up >>> creating inverse instances and throwing them away a lot and I >>> thought >>> it >>> would be good to reduce that overhead. >> >> Surely, the class "Quaternion" is minimal but, before adding to >> the API, we be careful to have use-cases for low-level operations. >> Those mentioned above seems more high-level, tied to a specific >> domain (see also "Commons Geometry", another new component not yet >> released) but I may be wrong... >> >> Regards, >> Gilles >> >>> >>> Steve >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
