commons-dev mailing list archives

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