Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Martin Desruisseaux <martin.desruisseaux@ge...>  20070515 14:38:52

Graham Davis a écrit : > public boolean equals(Object o) { > if (o instanceof DirectPosition  o instanceof DirectPositionImpl) > return this.equals((DirectPosition) o, 0); > else > return false; > } Note: the " o instanceof DirectPositionImpl" is useless. I suggest to remove it. > /** > * Compares coodinates of Direct Positions and allows a tolerance value in > * the comparison. Implementation Note: Parameter has to be of Type > * DirectPosition (not DirectPositionImpl), so that the equals method is > * found for DirectPosition´s and DirectPositionImpl´s I suggest to remove the implementation note: it is normal interface programming and don't really bring info as far as I can see... > public boolean equals(DirectPosition position, double tol) { > int D = position.getDimension(); > if( D != getDimension() ) return false; > for (int i = 0; i < D; ++i) { > if (Math.abs(DoubleOperation.subtract(position.getOrdinate(i), this.coordinate[i])) > tol) > return false; > } > return true; > } What is DoubleOperation? What are its advantage compared to the usual '' operator? position.getOrdinate(i) returns double value anyway, and Math.abs(double) expect a double anyway. Additional note: I suggest to replace: if (abs(position.getOrdinate(i)  this.getOrdinate(i)) > tol) by if (!(abs(position.getOrdinate(i)  this.getOrdinate(i))) <= tol) Purpose: consider positions as different if at least one ordinate is Double.NaN. Martin 
From: Graham Davis <gdavis@re...>  20070523 23:59:39

Hi Martin, sorry for the late reply. My comments are inline: Martin Desruisseaux wrote: >Graham Davis a écrit : > > >>public boolean equals(Object o) { >> if (o instanceof DirectPosition  o instanceof DirectPositionImpl) >> return this.equals((DirectPosition) o, 0); >> else >> return false; >>} >> >> > >Note: the " o instanceof DirectPositionImpl" is useless. I suggest to remove it. > > Good eye, that does seem useless. I will remove that. >>/** >> * Compares coodinates of Direct Positions and allows a tolerance value in >> * the comparison. Implementation Note: Parameter has to be of Type >> * DirectPosition (not DirectPositionImpl), so that the equals method is >> * found for DirectPosition´s and DirectPositionImpl´s >> >> > >I suggest to remove the implementation note: it is normal interface programming >and don't really bring info as far as I can see... > > > Good point, I will remove this too. >>public boolean equals(DirectPosition position, double tol) { >> int D = position.getDimension(); >> if( D != getDimension() ) return false; >> for (int i = 0; i < D; ++i) { >> if (Math.abs(DoubleOperation.subtract(position.getOrdinate(i), this.coordinate[i])) > tol) >> return false; >> } >> return true; >>} >> >> > >What is DoubleOperation? What are its advantage compared to the usual '' >operator? position.getOrdinate(i) returns double value anyway, and >Math.abs(double) expect a double anyway. > >Additional note: I suggest to replace: > > if (abs(position.getOrdinate(i)  this.getOrdinate(i)) > tol) > >by > > if (!(abs(position.getOrdinate(i)  this.getOrdinate(i))) <= tol) > >Purpose: consider positions as different if at least one ordinate is Double.NaN. > > Martin > > I'm not sure why the original implementer uses DoubleOperation here. I assumed it was to catch special cases when one or both values were NaN, but looking at the code, it just seems to use the regular '' operator. Your suggestion again seems good, and I will implement this change as well. Thanks for the feedback Martin! Graham.  Graham Davis Refractions Research Inc. gdavis@... 
From: Graham Davis <gdavis@re...>  20070524 18:34:00

Martin Desruisseaux wrote: >>What is DoubleOperation? What are its advantage compared to the usual '' >>operator? position.getOrdinate(i) returns double value anyway, and >>Math.abs(double) expect a double anyway. >> >>Additional note: I suggest to replace: >> >> if (abs(position.getOrdinate(i)  this.getOrdinate(i)) > tol) >> >>by >> >> if (!(abs(position.getOrdinate(i)  this.getOrdinate(i))) <= tol) >> >>Purpose: consider positions as different if at least one ordinate is Double.NaN. >> >> Martin >> >> >> >> I think that we should consider positions with similar NaN ordinates to be equal. Currently you can create a DirectPosition without initializing ordinates, and they will be filled with Double.NaN. If you then compare these positions, or enter values for only 1 of 2 ordinates (or only 2of 3, etc), these positions would not be considered equal if we change this. This might be especially important for 2.5 Dimension positions. Consider this example, you have two points in 2.5 Dimensions (x, y and some nonspatial value to be stored in z). If you create the positions with the same x and y values, but do not have a value to enter for the z dimension yet, should these positions not be considered equal at this point? The z ordinates will be NaN. So, I think I should leave this last part of the DirectPosition equals method the same. What do you think?  Graham Davis Refractions Research Inc. gdavis@... 
From: Martin Desruisseaux <martin.desruisseaux@ge...>  20070527 16:31:40

Graham Davis a écrit : > I think that we should consider positions with similar NaN ordinates to > be equal. (...snip...) > > So, I think I should leave this last part of the DirectPosition equals > method the same. What do you think? It depends what we want to do: The current code will consider 2 points as equals if at least one point have NaN value, even if the other point has valid value. For example (2,5,8) and (2,NaN,8) are considered equals. With the proposed code change, (2,5,8) and (2,NaN,8) are considered different but (2,NaN,8) and (2,NaN,8) would be considered different as well. If the goal is "(2,5,8) and (2,NaN,8) are different" but (2,NaN,8) and (2,NaN,8) are equals", then a possible approach (admitly harder to read) is: double a = position.getOrdinate(i); double b = this.getOrdinate(i); if (!(abs(a  b) <= tol) && (!Double.isNaN(a)  !Double.isNaN(b))) { return false; } Whatever policy is choosen regarding NaN, it is probably worth to put a javadoc comment or a comment in the code... Martin 
From: Graham Davis <gdavis@re...>  20070528 15:57:22

Martin Desruisseaux wrote: >Graham Davis a écrit : > > >>I think that we should consider positions with similar NaN ordinates to >>be equal. (...snip...) >> >>So, I think I should leave this last part of the DirectPosition equals >>method the same. What do you think? >> >> > >It depends what we want to do: > >The current code will consider 2 points as equals if at least one point have NaN >value, even if the other point has valid value. For example (2,5,8) and >(2,NaN,8) are considered equals. > >With the proposed code change, (2,5,8) and (2,NaN,8) are considered different >but (2,NaN,8) and (2,NaN,8) would be considered different as well. > >If the goal is "(2,5,8) and (2,NaN,8) are different" but (2,NaN,8) and (2,NaN,8) >are equals", then a possible approach (admitly harder to read) is: > >double a = position.getOrdinate(i); >double b = this.getOrdinate(i); >if (!(abs(a  b) <= tol) && (!Double.isNaN(a)  !Double.isNaN(b))) { > return false; >} > >Whatever policy is choosen regarding NaN, it is probably worth to put a javadoc >comment or a comment in the code... > > Martin > > Agreed, and that's what I've done. I've taken an approach similar to the one you listed above, where (2,5,8) and (2,NaN,8) are different, but (2,NaN,8) and (2,NaN,8)are equal. I've added a comment to explain that as well.  Graham Davis Refractions Research Inc. gdavis@... 
From: Jody Garnett <jgarnett@re...>  20070524 19:10:29

Martin Desruisseaux wrote: > What is DoubleOperation? What are its advantage compared to the usual '' > operator? position.getOrdinate(i) returns double value anyway, and > Math.abs(double) expect a double anyway. > DoubleOperation is a stratagy object employed by the unsupported/geometry implementation to support "enhanced percision" .. one implementation uses normal double math, the other one converts things to BigDecimal to perform the math, and then back again to double for the answer. One idea would be add this functionality to the Percision interface, as it is a similar concept to the rounding functions already present there.... but rounding and choice of math implementation are different concerns. (One idea I had was to use an implementation based on IBM's strict math if needed). Jody 
From: Jody Garnett <jgarnett@re...>  20070524 19:13:38

This is a tough call .. one way to handle it would be in the 2.5 D case use the CRS should constrain the equals test to only the first 2 dimensions (and ignore the 3rd ordinate regardless of what kind of value it is?). I think Martin has the right idea here (for the DirectPosition.equals( Object ) method), their may be a use for a DirectPosition.equals( Position ) method which performs the CRS aware comparison.... You are in a better position to appreciate the difference than me ... it is the same tradeoff between Geometry.equals( Object ) and Geometry.equals( TransfiniteSet ). Cheers, Jody Graham Davis wrote: > I think that we should consider positions with similar NaN ordinates to > be equal. Currently you can create a DirectPosition without > initializing ordinates, and they will be filled with Double.NaN. If you > then compare these positions, or enter values for only 1 of 2 ordinates > (or only 2of 3, etc), these positions would not be considered equal if > we change this. This might be especially important for 2.5 Dimension > positions. > > Consider this example, you have two points in 2.5 Dimensions (x, y and > some nonspatial value to be stored in z). If you create the positions > with the same x and y values, but do not have a value to enter for the z > dimension yet, should these positions not be considered equal at this > point? The z ordinates will be NaN. > > So, I think I should leave this last part of the DirectPosition equals > method the same. What do you think? > > 
From: Graham Davis <gdavis@re...>  20070525 16:23:03

Thanks for the input. I've currently got the equals method working so that that the CRS constrains the test to the number of dimensions it defines. Both equals methods use this (object) and (position). They both also test specifically for Double.NaN so that anytime similar ordinates are NaN they are considered equal. For now I think having both methods work similarly is the most intuitive. If it turns out we need to change one or both so that 2.5D comparisons do look at the 3rd ordinate, we can change it at that time. Graham. Jody Garnett wrote: > This is a tough call .. one way to handle it would be in the 2.5 D > case use the CRS should constrain the equals test to only the first 2 > dimensions (and ignore the 3rd ordinate regardless of what kind of > value it is?). > > I think Martin has the right idea here (for the DirectPosition.equals( > Object ) method), their may be a use for a DirectPosition.equals( > Position ) method which performs the CRS aware comparison.... > > You are in a better position to appreciate the difference than me ... > it is the same tradeoff between Geometry.equals( Object ) and > Geometry.equals( TransfiniteSet ). > > Cheers, > Jody > > Graham Davis wrote: > >> I think that we should consider positions with similar NaN ordinates >> to be equal. Currently you can create a DirectPosition without >> initializing ordinates, and they will be filled with Double.NaN. If >> you then compare these positions, or enter values for only 1 of 2 >> ordinates (or only 2of 3, etc), these positions would not be >> considered equal if we change this. This might be especially >> important for 2.5 Dimension positions. >> >> Consider this example, you have two points in 2.5 Dimensions (x, y >> and some nonspatial value to be stored in z). If you create the >> positions with the same x and y values, but do not have a value to >> enter for the z dimension yet, should these positions not be >> considered equal at this point? The z ordinates will be NaN. >> >> So, I think I should leave this last part of the DirectPosition >> equals method the same. What do you think? >> >> > >  Graham Davis Refractions Research Inc. gdavis@... 
From: Martin Desruisseaux <martin.desruisseaux@ge...>  20070527 16:35:33

Jody Garnett a écrit : > their may be a use for a DirectPosition.equals(Position) > method which performs the CRS aware comparison.... I suggest to: * keep DirectPosition.equals(Object) very strict (full CRS comparaison using crs.equals(...), not equalsIgnoreMetadata) in order to reduce the risk of unexpected behavior in HashMap. * add if needed a DirectPosition.equals(DirectPosition, double) method, with maybe more flexible rule as proposed by Jody, and a tolerance threshold explicitly specified by the user (rather than choosen in our implementation class). Martin 
Sign up for the SourceForge newsletter:
No, thanks