osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]# Re: [Numbers][Geometry] Where to define "quaternion"?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Hi. On Mon, 3 Dec 2018 03:56:02 +0000, Matt Juntunen wrote:

I was just thinking from a practical standpoint. My currentQuaternionRotation class is still in my working branch forGEOMETRY-14and so isn't really accessible to anyone. If I can finish it up initscurrent state (hopefully very soon) and get it merged, then someone else will be able to work with it and blend the functionality with commons-numbers.

Someone else?

Here are some notes on your questions from before: * Should "QuaternionRotation" inherit from "Quaternion"? That would work conceptually. The quaternions in the QuaternionRotation class are standard quaternions that meet two other criteria: 1) they are unit length, and 2) their scalar component is greater than or equal to zero (in order to standardize the angles involved).

It seems indeed the perfect case for inheritance.

The one sticking point here is that I'm not sure how thisfits with the VALJO concept. If we can get this sorted, then thisverywell may be the best option.

What do you see as a potential issue?

* Should "Quaternion" be defined in [Geometry] (and removed from [Numbers])? Perhaps. I've certainly only used them to represent 3D rotations. Are there any other use cases from commons-numbers?

Not within [Numbers], but that's the point of those very low-level components/modules: they are common utilities used by higher-level components/libraries/applications. Given that "QuaternionRotation" is a special case of "Quaternion", it is logical to keep the latter at a lower-level, namely in [Numebers], and make [Geometry] depend on it.

* 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 conversion to rotation matrix and slerp are the best candidates here. The other methods rely on core classes from commons-geometry, namely Vector3D.

Is "slerp" applicable to a general "Quaternion", or does it assume the additional requirements of "QuaternionRotation"? [Same question applies to all utilities in order to decide where to define them.]

One more note: I decided to make a separate package for 3D rotations in my working branch for GEOMETRY-14, so QuaternionRotation is now at https://github.com/darkma773r/commons-geometry/blob/transforms/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/rotation/QuaternionRotation.java.

Could you please update it so that it inherits from "Quaternion"? Thanks, Gilles

-Matt ________________________________ From: Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx> Sent: Sunday, December 2, 2018 3:57 PM To: dev@xxxxxxxxxxxxxxxxxx Subject: Re: [Numbers][Geometry] Where to define "quaternion" (Was: Making Quaternion a VALJO) On Sun, 2 Dec 2018 19:20:03 +0000, Matt Juntunen wrote:Unless anyone objects, I'm going to continue with what I'm workingonI certainly don't object on your working to improve the geometry code, but wherever that work overlaps with code being worked on elsewhere (in this case, the "Quaternion" class), then we'd rather have a discussion happening here first.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.My questions below are a start; I'm waiting for answers. Code duplication is bad (TM). Regards, Gilles-Matt ________________________________ From: Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx> Sent: Saturday, December 1, 2018 9:40 PM To: dev@xxxxxxxxxxxxxxxxxx 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 doesnot require types defined in [Geometry]. For example,interpolationis 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, GillesRegards, 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 <gilles@xxxxxxxxxxxxxxxxxxxxx> Sent: Friday, November 30, 2018 9:37 AM To: dev@xxxxxxxxxxxxxxxxxx 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 whiletrying to improve my understanding so I'm not going to claimgreatknowledge 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, GillesSteve

--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx

- Prev by Date:
**Re: [Numbers][Geometry] Where to define "quaternion" (Was: Making Quaternion a VALJO)** - Next by Date:
**[Geometry][Numbers] Blocker issues (Was: [geometry] 1.0 Roadmap)** - Previous by thread:
**[GitHub] commons-logging pull request #1: default methods to Log interface to prevent...** - Next by thread:
**[Geometry][Numbers] Blocker issues (Was: [geometry] 1.0 Roadmap)** - Index(es):