More precisely, the resulting pattern:
Note: the number of points in the result can be less than {@link #pointCount()}, because some real points can be rounded to the same integer points.
Warning! If this object is not {@link DirectPointSetPattern}and is not {@link RectangularPattern}, this method can work slowly for some large patterns: the required time can be O(N), where N is the number of points. In these cases, this method can also throw {@link TooManyPointsInPatternError}or OutOfMemoryError. The situation is like in {@link #points()} and {@link #roundedPoints()} method.
There is a guarantee, that if this object implements {@link DirectPointSetPattern} interface,then this method requires not greater than O(N) operations and memory (N= {@link #pointCount() pointCount()}) and never throws {@link TooManyPointsInPatternError}.
There is a guarantee, that if this object implements {@link RectangularPattern} interface,then this method works quickly (O(1) operations) and without exceptions. It is an important difference from {@link #points()} and {@link #roundedPoints()} method.
The theorem I, described in the {@link Pattern comments to this interface}, section "Coordinate restrictions", provides a guarantee that this method never throws {@link TooLargePatternCoordinatesException}. @return the integer pattern, geometrically nearest to this one. @throws TooManyPointsInPatternError if this pattern is not {@link DirectPointSetPattern} andnot {@link RectangularPattern} and if, at the same time, the numberof points is greater than Integer.MAX_VALUE or, in some rare situations, is near this limit (OutOfMemoryError can be also thrown instead of this exception).
|
|
|
|
|
|