[ https://issues.apache.org/jira/browse/MATH863?page=com.atlassian.jira.plugin.system.issuetabpanels:commenttabpanel&focusedCommentId=13460471#comment13460471
]
Sébastien Brisard commented on MATH863:

I personally don't like {{leftMultiply}} and {{rightMultiply}}, for three reasons
# who is meant to stand on the left/right is not intuitive to me
# I can't see the gain of {{this.leftMultiply(a)}} over {{a.rightMultiply(this)}}
# {{FieldElement}} has a fluent interface. So you could write something like {{a.add(b.rightMultiply(c))}},
which reads how it should, namely {{a + (b * c)}}, while {{a.add(b.leftMultiply(c))}} should
read the other way {{a + (c * b)}}, which somehow breaks the fluent interface.
Besides, I don't understand why {{SkewField}} should not be equipped with a multiplication/division
(with no assumption on commutativity), while the mathematical definition of a skew field clearly
states that there is a multiplication/division.
How about
# we create a superinterface of {{FieldElement}}, for example {{SkewFieldElement}} which is
*not necessarily* commutative, and we say so in the Javadoc. This interface has the same methods
as {{FieldElement}} *including* {{multiply}} and {{divide}} (basically we move all methods
from {{FieldElement}} to {{SkewFieldElement}}, and {{FieldElement}} becomes a marker interface).
{{multiply}} would effectively be what Julien named {{rightMultiply}}, and there is no need
in my view to provide a {{leftMultiply}} (or maybe I'm missing something?)
# we clearly state in the interface that {{FieldElement}} *is* commutative
> new Quaternion class added in complex package
> 
>
> Key: MATH863
> URL: https://issues.apache.org/jira/browse/MATH863
> Project: Commons Math
> Issue Type: New Feature
> Affects Versions: 3.1
> Reporter: Julien Anxionnat
> Attachments: quaternion_adjustments.patch, quaternion.patch, quaternion_v2.patch
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> This patch provides a new class for the mathematical object "Quaternion" in the complex
package.
> This quaternion is considered as a mathematical object (the Hamilton's hypercomplex number).
> Note that it's not a rotation quaternion which has to be a quaternion of norm one. Although
this feature could be used for a getter in the Rotation class.
> This patch provides also some improvements in Precision class : a "double comparison
epsilon" and a method to compute relative comparison.
> (Please, note that's it's my first contribution, and I apologize in advance for my mistakes…)

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
