commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject [Numbers][Geometry] Where to define "quaternion" (Was: Making Quaternion a VALJO)
Date Sat, 01 Dec 2018 11:56:34 GMT
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.

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 <gilles@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message