commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject [Numbers] Inheritance and ValJO ? (Was: Where to define "quaternion"?)
Date Sun, 09 Dec 2018 10:21:09 GMT
Hello.

After the discussion quote below, the conclusion was to go with
inheritance:
   https://issues.apache.org/jira/browse/NUMBERS-80

However, it would make "Quaternion" fail the "ValJO" definition[1]
that mandates that all constructors be private.

Would a protected constructor really be an issue?
[In the case of "Quaternion", the subclass constructor would only
perform additional validation (cf. below for details).]


Thanks,
Gilles

[1] https://blog.joda.org/2014/03/valjos-value-java-objects.html

On Mon, 03 Dec 2018 10:31:42 +0100, Gilles wrote:
> Hi.
>
> On Mon, 3 Dec 2018 03:56:02 +0000, Matt Juntunen wrote:
>> I was just thinking from a practical standpoint. My current
>> QuaternionRotation class is still in my working branch for 
>> GEOMETRY-14
>> and so isn't really accessible to anyone. If I can finish it up in 
>> its
>> current 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 this
>> fits with the VALJO concept. If we can get this sorted, then this 
>> very
>> well 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@harfang.homelinux.org>
>> Sent: Sunday, December 2, 2018 3:57 PM
>> To: dev@commons.apache.org
>> 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 working 
>>> on
>>
>> I 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@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 <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