osdir.com


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

Re: [Numbers] Inheritance and ValJO ? (Was: Where to define "quaternion"?)



> On Dec 12, 2018, at 5:48 PM, Stephen Colebourne <scolebourne@xxxxxxxx> 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 <gilles@xxxxxxxxxxxxxxxxxxxxx> 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 <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 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@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 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@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
>>>>>>>> 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@xxxxxxxxxxxxxxxxxx
>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>> 
>> 

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