[jira] [Updated] (SIS-318) Support PassThroughTransform directly into AbstractMathTransform
[
https://issues.apache.org/jira/browse/SIS-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-318:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Support PassThroughTransform directly into AbstractMathTransform
>
>
> Key: SIS-318
> URL: https://issues.apache.org/jira/browse/SIS-318
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Labels: performance
> Fix For: 1.2
>
>
> Add the 4 variants (for {{float[]}} and {{double[]}} arrays) of the following
> method in {{AbstractMathTransform}}:
> {code:java}
> protected void transform(double[] srcPts, int srcOff, int srcInc,
> double[] dstPts, int dstOff, int dstInc, int numPts)
> throws TransformException;
> {code}
> The difference compared to existing methods is the addition of {{srcInc}} and
> {{dstInc}} parameters. Then, move the {{AbstractMathTransform}} default
> implementations of {{transform(…)}} methods under those 4 new methods. The
> default implementation of previous methods would redirect to the new ones
> like below:
> {code:java}
> @Override
> public void transform(double[] srcPts, int srcOff,
> double[] dstPts, int dstOff, int numPts) throws
> TransformException
> {
> transform(srcPts, srcOff, getSourceDimensions(),
> dstPts, dstOff, getTargetDimensions(), numPts);
> }
> {code}
> This approach should ensure {{MathTransform}} methods consistency no matter
> if a sub-class override the old methods or the new ones. Modify all Apache
> SIS implementations that override the old methods for overriding the new ones
> instead.
> With those news methods, we can modify {{PassThroughTransform}}
> implementation for invoking those methods on the sub-transform with
> {{srcInc}} and {{dstInc}} values increased by {{firstAffectedOrdinate}} +
> {{numTrailingOrdinates}}. The performance benefit may be important since
> {{PassThroughTransform}} can hardly implement the {{transform}} method in an
> efficient way otherwise. We will still need the current
> {{transformOverlapping}} private method however as a fallback when array
> regions overlap.
> This approach would also make easier to concatenate the matrices of linear
> transforms. In the current implementation we lost a concatenation opportunity
> if one linear transform is the last {{MathTransform}} (in a chain of a
> concatenated transforms) inside the {{PassThroughTransform}}, while the other
> linear transform is the first {{MathTransform}} outside the
> {{PassThroughTransform}}. We could move the former linear transform outside
> the {{PassThroughTransform}}, but it cause confusing WKT to be formatted if
> the transforms inside the {{PassThroughTransform}} have a
> {{ContextualParameters}}. We expect that this problem would be solved with
> the fix proposed in this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-318) Support PassThroughTransform directly into AbstractMathTransform
[
https://issues.apache.org/jira/browse/SIS-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-318:
Fix Version/s: 1.1
> Support PassThroughTransform directly into AbstractMathTransform
>
>
> Key: SIS-318
> URL: https://issues.apache.org/jira/browse/SIS-318
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.5, 0.6, 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Labels: performance
> Fix For: 1.1
>
>
> Add the 4 variants (for {{float[]}} and {{double[]}} arrays) of the following
> method in {{AbstractMathTransform}}:
> {code:java}
> protected void transform(double[] srcPts, int srcOff, int srcInc,
> double[] dstPts, int dstOff, int dstInc, int numPts)
> throws TransformException;
> {code}
> The difference compared to existing methods is the addition of {{srcInc}} and
> {{dstInc}} parameters. Then, move the {{AbstractMathTransform}} default
> implementations of {{transform(…)}} methods under those 4 new methods. The
> default implementation of previous methods would redirect to the new ones
> like below:
> {code:java}
> @Override
> public void transform(double[] srcPts, int srcOff,
> double[] dstPts, int dstOff, int numPts) throws
> TransformException
> {
> transform(srcPts, srcOff, getSourceDimensions(),
> dstPts, dstOff, getTargetDimensions(), numPts);
> }
> {code}
> This approach should ensure {{MathTransform}} methods consistency no matter
> if a sub-class override the old methods or the new ones. Modify all Apache
> SIS implementations that override the old methods for overriding the new ones
> instead.
> With those news methods, we can modify {{PassThroughTransform}}
> implementation for invoking those methods on the sub-transform with
> {{srcInc}} and {{dstInc}} values increased by {{firstAffectedOrdinate}} +
> {{numTrailingOrdinates}}. The performance benefit may be important since
> {{PassThroughTransform}} can hardly implement the {{transform}} method in an
> efficient way otherwise. We will still need the current
> {{transformOverlapping}} private method however as a fallback when array
> regions overlap.
> This approach would also make easier to concatenate the matrices of linear
> transforms. In the current implementation we lost a concatenation opportunity
> if one linear transform is the last {{MathTransform}} (in a chain of a
> concatenated transforms) inside the {{PassThroughTransform}}, while the other
> linear transform is the first {{MathTransform}} outside the
> {{PassThroughTransform}}. We could move the former linear transform outside
> the {{PassThroughTransform}}, but it cause confusing WKT to be formatted if
> the transforms inside the {{PassThroughTransform}} have a
> {{ContextualParameters}}. We expect that this problem would be solved with
> the fix proposed in this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SIS-318) Support PassThroughTransform directly into AbstractMathTransform
[
https://issues.apache.org/jira/browse/SIS-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-318:
Description:
Add the 4 variants (for {{float[]}} and {{double[]}} arrays) of the following
method in {{AbstractMathTransform}}:
{code:java}
protected void transform(double[] srcPts, int srcOff, int srcInc,
double[] dstPts, int dstOff, int dstInc, int numPts)
throws TransformException;
{code}
The difference compared to existing methods is the addition of {{srcInc}} and
{{dstInc}} parameters. Then, move the {{AbstractMathTransform}} default
implementations of {{transform(…)}} methods under those 4 new methods. The
default implementation of previous methods would redirect to the new ones like
below:
{code:java}
@Override
public void transform(double[] srcPts, int srcOff,
double[] dstPts, int dstOff, int numPts) throws
TransformException
{
transform(srcPts, srcOff, getSourceDimensions(),
dstPts, dstOff, getTargetDimensions(), numPts);
}
{code}
This approach should ensure {{MathTransform}} methods consistency no matter if
a sub-class override the old methods or the new ones. Modify all Apache SIS
implementations that override the old methods for overriding the new ones
instead.
With those news methods, we can modify {{PassThroughTransform}} implementation
for invoking those methods on the sub-transform with {{srcInc}} and {{dstInc}}
values increased by {{firstAffectedOrdinate}} + {{numTrailingOrdinates}}. The
performance benefit may be important since {{PassThroughTransform}} can hardly
implement the {{transform}} method in an efficient way otherwise. We will still
need the current {{transformOverlapping}} private method however as a fallback
when array regions overlap.
This approach would also make easier to concatenate the matrices of linear
transforms. In the current implementation we lost a concatenation opportunity
if one linear transform is the last {{MathTransform}} (in a chain of a
concatenated transforms) inside the {{PassThroughTransform}}, while the other
linear transform is the first {{MathTransform}} outside the
{{PassThroughTransform}}. We could move the former linear transform outside the
{{PassThroughTransform}}, but it cause confusing WKT to be formatted if the
transforms inside the {{PassThroughTransform}} have a {{ContextualParameters}}.
We expect that this problem would be solved with the fix proposed in this issue.
was:
Add the 4 variants (for {{float[]}} and {{double[]}} arrays) of the following
method in {{AbstractMathTransform}}:
{code:java}
protected void transform(double[] srcPts, int srcOff, int srcInc,
double[] dstPts, int dstOff, int dstInc, int numPts)
throws TransformException;
{code}
The difference compared to existing methods is the addition of {{srcInc}} and
{{dstInc}} parameters. Then, move the {{AbstractMathTransform}} default
implementations of {{transform(…)}} methods under those 4 new methods. The
default implementation of previous methods would redirect to the new ones like
below:
{code:java}
@Override
public void transform(double[] srcPts, int srcOff,
double[] dstPts, int dstOff, int numPts) throws
TransformException
{
transform(srcPts, srcOff, getSourceDimensions(),
dstPts, dstOff, getTargetDimensions(), numPts);
}
{code}
This approach should ensure {{MathTransform}} methods consistency no matter if
a sub-class override the old methods or the new ones. Modify all Apache SIS
implementations that override the old methods for overriding the new ones
instead.
With those news method, we can modify {{PassThroughTransform}} implementation
for invoking those methods on the sub-transform with {{srcInc}} and {{dstInc}}
values increased by {{firstAffectedOrdinate}} and {{numTrailingOrdinates}}. The
performance benefit may be important, since it can hardly implement the
{{transform}} method in an efficient way otherwise. We will still need the
current {{transformOverlapping}} private method however as a fallback when
array regions overlap.
This approach would also make easier to concatenate the matrices of linear
transforms. In the current implementation we lost a concatenation opportunity
if one linear transform is the last {{MathTransform}} (in a chain of a
concatenated transforms) inside the {{PassThroughTransform}}, while the other
linear transform is the first {{MathTransform}} outside the
{{PassThroughTransform}}. We could move the former linear transform outside the
{{PassThroughTransform}}, but it cause confusing WKT to be formatted if the
transforms inside the {{PassThroughTransform}} have a {{ContextualParameters}}.
We expect that this problem would be solved with the fix proposed in this issue.
> Support PassThroughTransform directly into AbstractMathTransform
>
[jira] [Updated] (SIS-318) Support PassThroughTransform directly into AbstractMathTransform
[
https://issues.apache.org/jira/browse/SIS-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-318:
Description:
Add the 4 variants (for {{float[]}} and {{double[]}} arrays) of the following
method in {{AbstractMathTransform}}:
{code:java}
protected void transform(double[] srcPts, int srcOff, int srcInc,
double[] dstPts, int dstOff, int dstInc, int numPts)
throws TransformException;
{code}
The difference compared to existing methods is the addition of {{srcInc}} and
{{dstInc}} parameters. Then, move the {{AbstractMathTransform}} default
implementations of {{transform(…)}} methods under those 4 new methods. The
default implementation of previous methods would redirect to the new ones like
below:
{code:java}
@Override
public void transform(double[] srcPts, int srcOff,
double[] dstPts, int dstOff, int numPts) throws
TransformException
{
transform(srcPts, srcOff, getSourceDimensions(),
dstPts, dstOff, getTargetDimensions(), numPts);
}
{code}
This approach should ensure {{MathTransform}} methods consistency no matter if
a sub-class override the old methods or the new ones. Modify all Apache SIS
implementations that override the old methods for overriding the new ones
instead.
With those news method, we can modify {{PassThroughTransform}} implementation
for invoking those methods on the sub-transform with {{srcInc}} and {{dstInc}}
values increased by {{firstAffectedOrdinate}} and {{numTrailingOrdinates}}. The
performance benefit may be important, since it can hardly implement the
{{transform}} method in an efficient way otherwise. We will still need the
current {{transformOverlapping}} private method however as a fallback when
array regions overlap.
This approach would also make easier to concatenate the matrices of linear
transforms. In the current implementation we lost a concatenation opportunity
if one linear transform is the last {{MathTransform}} (in a chain of a
concatenated transforms) inside the {{PassThroughTransform}}, while the other
linear transform is the first {{MathTransform}} outside the
{{PassThroughTransform}}. We could move the former linear transform outside the
{{PassThroughTransform}}, but it cause confusing WKT to be formatted if the
transforms inside the {{PassThroughTransform}} have a {{ContextualParameters}}.
We expect that this problem would be solved with the fix proposed in this issue.
was:
Move the {{firstAffectedOrdinate}} and {{numTrailingOrdinates}} fields from
{{PassThroughTransform}} to its {{AbstractMathTransform}} parent class. Every
{{AbstractMathTransform}} subclasses should then take those fields in account.
We expect no performance penalty on {{AbstractMathTransform}} subclasses since
it would just change the value in an addition which is applied anyway. On the
other hand, it may provide significant performance gain by reducing the need
for the {{PassThroughTransform}}, which can hardly implement the {{transform}}
method in an efficient way.
It would also make easier to concatenate the matrices of linear transforms. In
the current implementation we lost a concatenation opportunity if one linear
transform is the last {{MathTransform}} (in a chain of a concatenated
transforms) inside the {{PassThroughTransform}}, while the other linear
transform is the first {{MathTransform}} outside the {{PassThroughTransform}}.
We could move the former linear transform outside the {{PassThroughTransform}},
but it cause confusing WKT to be formatted if the transforms inside the
{{PassThroughTransform}} have a {{ContextualParameters}}. We expect that this
problem would be solved with the fix proposed in this issue.
> Support PassThroughTransform directly into AbstractMathTransform
>
>
> Key: SIS-318
> URL: https://issues.apache.org/jira/browse/SIS-318
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.5, 0.6, 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Labels: performance
>
> Add the 4 variants (for {{float[]}} and {{double[]}} arrays) of the following
> method in {{AbstractMathTransform}}:
> {code:java}
> protected void transform(double[] srcPts, int srcOff, int srcInc,
> double[] dstPts, int dstOff, int dstInc, int numPts)
> throws TransformException;
> {code}
> The difference compared to existing methods is the addition of {{srcInc}} and
> {{dstInc}} parameters. Then, move the {{AbstractMathTransform}} default
> implementations of {{transform(…)}} methods under those 4 new methods. The
> default implementation of previous methods would redirect to the new
[jira] [Updated] (SIS-318) Support PassThroughTransform directly into AbstractMathTransform
[
https://issues.apache.org/jira/browse/SIS-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-318:
Affects Version/s: 0.7
0.8
> Support PassThroughTransform directly into AbstractMathTransform
>
>
> Key: SIS-318
> URL: https://issues.apache.org/jira/browse/SIS-318
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.5, 0.6, 0.7, 0.8
>Reporter: Martin Desruisseaux
>Priority: Minor
> Labels: performance
>
> Move the {{firstAffectedOrdinate}} and {{numTrailingOrdinates}} fields from
> {{PassThroughTransform}} to its {{AbstractMathTransform}} parent class. Every
> {{AbstractMathTransform}} subclasses should then take those fields in
> account. We expect no performance penalty on {{AbstractMathTransform}}
> subclasses since it would just change the value in an addition which is
> applied anyway. On the other hand, it may provide significant performance
> gain by reducing the need for the {{PassThroughTransform}}, which can hardly
> implement the {{transform}} method in an efficient way.
> It would also make easier to concatenate the matrices of linear transforms.
> In the current implementation we lost a concatenation opportunity if one
> linear transform is the last {{MathTransform}} (in a chain of a concatenated
> transforms) inside the {{PassThroughTransform}}, while the other linear
> transform is the first {{MathTransform}} outside the
> {{PassThroughTransform}}. We could move the former linear transform outside
> the {{PassThroughTransform}}, but it cause confusing WKT to be formatted if
> the transforms inside the {{PassThroughTransform}} have a
> {{ContextualParameters}}. We expect that this problem would be solved with
> the fix proposed in this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
