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

Matt Juntunen commented on NUMBERS-161:
---------------------------------------

bq. Can the issue provide a corresponding unit test (indicating which accuracy 
must be achieved)?

Yes. The issue I mentioned above with {{Double.MIN_NORMAL}} is one example. 
Overall, the class should produce the same results as if the operations were 
done directly on doubles of the correct units. We can easily test this.

bq. Why normalizeAbove and normalizeBelow instead of just one of them or 
normalizeCenter (aka reduce)?

I added this because the method guarantees are in terms of the upper and lower 
bounds, e.g., the return value is guaranteed to be within the range {{[x, x + 
period)}}. This is troublesome when only the center is given. For example, say 
that we want a lower bound of {{x = pi/3}}. If we must specify the center, we 
must compute {{center = x + pi}}. However, we have now lost our guarantee 
because {{center - pi != x}} exactly. So, we get a stronger guarantee by 
specifying one of the bounds.

bq. I guess that there will be a normalizer factory method for each concrete 
type

I believe so. I haven't gotten to that point yet since I'm still working 
through the initial design.

> PlaneAngle Numerical Accuracy
> -----------------------------
>
>                 Key: NUMBERS-161
>                 URL: https://issues.apache.org/jira/browse/NUMBERS-161
>             Project: Commons Numbers
>          Issue Type: Improvement
>            Reporter: Matt Juntunen
>            Assignee: Gilles Sadowski
>            Priority: Major
>
> The current {{PlaneAngle}} class introduces unnecessary round-off errors 
> during use since it internally converts all values to turns. For example, it 
> is currently impossible to represent the radians value {{Double.MIN_NORMAL}} 
> exactly since the internal multiplication introduces errors: 
> {{PlaneAngle.ofRadians(Double.MIN_NORMAL).toRadians()}} does not equal 
> {{Double.MIN_NORMAL}}. We should restructure this API so that values are 
> stored exactly and multiplication is only performed when required.
> This issue was discovered during work on GEOMETRY-124. Use of the new 
> {{Reduce}} class added two more floating point operations to angle 
> normalization and caused a regression in commons-geometry-spherical.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to