[
https://issues.apache.org/jira/browse/MATH-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13460471#comment-13460471
]
Sébastien Brisard commented on MATH-863:
----------------------------------------
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: MATH-863
> URL: https://issues.apache.org/jira/browse/MATH-863
> 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
