commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Juntunen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GEOMETRY-9) New Euclidean Vector Methods
Date Thu, 06 Sep 2018 02:04:00 GMT

    [ https://issues.apache.org/jira/browse/GEOMETRY-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16605168#comment-16605168
] 

Matt Juntunen commented on GEOMETRY-9:
--------------------------------------

# This is something I've been going back and forth on. We throw exceptions in several methods
when we encounter vectors with zero norms, however the circumstances of the method call vary
and makes the actual type of exception hard to decide on. For example, the Vector3D.angle(Vector3D)
method requires that both vectors have zero norms. So, should we throw an IllegalStateException
if the calling vector has a zero norm and an IllegalArgumentException if the argument does?
If a user wants to catch a zero norm in this situation, would they then need to catch both
exception types? I've been trying to avoid this by using an IllegalStateException for all
zero norm situations but this doesn't quite feel right. I know we've talked about this before,
but I'd really like to go back to having a general GeometryException class with a ZeroNormException
subclass. That would be the most useful to me as a user of the library, since I could catch
a single exception hierarchy for geometric errors.
 # I see what you're saying, but I think that Vectors is legitimate as a utility class. It
contains only well-defined mathematical equations and saves us from having to duplicate the
code in other places. For example, Vectors.norm(double, double, double) is used in Point3D.distance(),
Vector3D.distance(), Vector3D.getNorm(), and one more place that I added for GEOMETRY-10.
 # I did this partly because there were already several existing methods following the same
pattern and partly because I think in some situations, using a static method can make code
slightly easier to read. For example, I usually picture the dot product as an operator  in
its own right and not as something that a vector does, so I may want to write Vector3D.dotProduct(v1,
v2) as opposed to v1.dotProduct(v2) when coding an algorithm. Those are really the only reasons.

> New Euclidean Vector Methods
> ----------------------------
>
>                 Key: GEOMETRY-9
>                 URL: https://issues.apache.org/jira/browse/GEOMETRY-9
>             Project: Apache Commons Geometry
>          Issue Type: Wish
>            Reporter: Matt Juntunen
>            Priority: Minor
>
> We should add some more methods to the Euclidean vector classes for user convenience
and algorithm clarity.
>  # length() – more intuitive alias for getNorm()
>  # project(Vector) – returns the current vector projected onto the given vector
>  # static project(Vector, Vector) – static version of project
>  # reject(Vector) – returns the current vector projected onto the plane whose normal
is passed to the method (vec equals vec.project(v) + vec.reject(v))
>  # static reject(Vector, Vector) – static version of reject
>  # lerp(Vector, double) – linear interpolation between the current vector and the given
one
>  # static lerp(Vector, Vector, double) – static version of lerp
>  # withLength(double) – returns the current vector with the given length. This is equivalent
to vector.normalize().scalarMultiply(x) but without the intermediate vector.
>  
> Pull request: [https://github.com/apache/commons-geometry/pull/8]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message