> On Dec 12, 2018, at 5:48 PM, Stephen Colebourne <scolebou...@joda.org> wrote:
>
> I think this has already been worked out, but the main reason for no
> inheritance is that is probably blocks future conversion to value types.
> Composition instead of inheritance is usually the right solution.
+1 to that.
>
> Stephen
>
>
>> On Sun, 9 Dec 2018 at 10:21, Gilles <gil...@harfang.homelinux.org> wrote:
>>
>> 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 <gil...@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 <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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
