

Hello.
Could we have a
boolean equals(Vector3D other,
double tolerance)
method?
Or even
static boolean equals(Vector3D v1,
Vector3D v2,
double tolerance)
that would return true if the components are equal within the given
tolerance.
Best,
Gilles
P.S. It seems that checking for exact equality (as the "equal(Object)"
method does) is not very useful: If the two vectors being compared
come from different computations, they will (most of the time) be
different although, at the precisionlevel, they should be considered
equal.

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


This is a generally useful thing to have, but there are multiple definitions
for how you apply the tolerance. You should file a JIRA and add a patch!
Among the definitions that are commonly used, you will find:
L1 norm: equals(a, b, tolerance) = sum(abs(ab)) < tolerance
L2 norm: equals(a, b, tolerance) = sqrt(sum((ab)^2)) < tolerance
Linfinity norm: equals(a, b, tolerance) = max(abs(ab)) < tolerance
All are useful.
Which did you think you wanted?
On Tue, Apr 28, 2009 at 6:23 AM, Gilles Sadowski <
[hidden email]> wrote:
>
> Could we have a
>
> boolean equals(Vector3D other,
> double tolerance)
>
> method?
> Or even
>
> static boolean equals(Vector3D v1,
> Vector3D v2,
> double tolerance)
>
> that would return true if the components are equal within the given
> tolerance.
>
>
> Best,
> Gilles
>
> P.S. It seems that checking for exact equality (as the "equal(Object)"
> method does) is not very useful: If the two vectors being compared
> come from different computations, they will (most of the time) be
> different although, at the precisionlevel, they should be considered
> equal.
>
> 
> To unsubscribe, email: [hidden email]
> For additional commands, email: [hidden email]
>
>

Ted Dunning, CTO
DeepDyve
111 West Evelyn Ave. Ste. 202
Sunnyvale, CA 94086
www.deepdyve.com
8584140013 (m)
4087730220 (fax)


Ted Dunning a écrit :
> This is a generally useful thing to have, but there are multiple definitions
> for how you apply the tolerance. You should file a JIRA and add a patch!
>
> Among the definitions that are commonly used, you will find:
>
> L1 norm: equals(a, b, tolerance) = sum(abs(ab)) < tolerance
> L2 norm: equals(a, b, tolerance) = sqrt(sum((ab)^2)) < tolerance
> Linfinity norm: equals(a, b, tolerance) = max(abs(ab)) < tolerance
>
> All are useful.
I'll guess for 3D vector the L2norm is the more useful as it is
invariant when physical orthonormal frames are changed.
I'll check in the variant you prefer.
Luc
>
> Which did you think you wanted?
>
> On Tue, Apr 28, 2009 at 6:23 AM, Gilles Sadowski <
> [hidden email]> wrote:
>
>> Could we have a
>>
>> boolean equals(Vector3D other,
>> double tolerance)
>>
>> method?
>> Or even
>>
>> static boolean equals(Vector3D v1,
>> Vector3D v2,
>> double tolerance)
>>
>> that would return true if the components are equal within the given
>> tolerance.
>>
>>
>> Best,
>> Gilles
>>
>> P.S. It seems that checking for exact equality (as the "equal(Object)"
>> method does) is not very useful: If the two vectors being compared
>> come from different computations, they will (most of the time) be
>> different although, at the precisionlevel, they should be considered
>> equal.
>>
>> 
>> To unsubscribe, email: [hidden email]
>> For additional commands, email: [hidden email]
>>
>>
>
>

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


That sounds very reasonable, but I wasn't the person with the need.
Also, for equality checking, especially in 3D, all of these will be very,
very close to the same. For very high numbers of dimensions, the
differences between boxes and balls becomes fairly extreme. In particular,
the corners of unit cubes (with a side length of 1) will begin to stick out
of the unit sphere (with a DIAmeter of 2). Beyond that point, things get
very strange.
On Tue, Apr 28, 2009 at 11:41 AM, Luc Maisonobe < [hidden email]>wrote:
> Ted Dunning a écrit :
> > This is a generally useful thing to have,...
>
> I'll guess for 3D vector the L2norm is the more useful as it is
> invariant when physical orthonormal frames are changed.
> I'll check in the variant you prefer.
>


> Among the definitions that are commonly used, you will find:
>
> L1 norm: equals(a, b, tolerance) = sum(abs(ab)) < tolerance
> L2 norm: equals(a, b, tolerance) = sqrt(sum((ab)^2)) < tolerance
> Linfinity norm: equals(a, b, tolerance) = max(abs(ab)) < tolerance
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I was thinking of that one. [Actually, I use it in unit tests...]
[The L2norm is already available through the "distance" method.]
Gilles

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


How about:
Vector3D {
...
enum Norm { L_0, L_1, L_2, L_infinity};
static double distance(Vector3D a, Vector3D b, Norm n);
...
}
?
You can then use distance(a, b, Vector3D.Norm.L_infinity) < epsilon
It gives you what you want and it should be very recognizable to the reader
of the code (subject to verification by all the readers out there).
On Tue, Apr 28, 2009 at 1:55 PM, Gilles Sadowski <
[hidden email]> wrote:
> > Among the definitions that are commonly used, you will find:
> >
> > L1 norm: equals(a, b, tolerance) = sum(abs(ab)) < tolerance
> > L2 norm: equals(a, b, tolerance) = sqrt(sum((ab)^2)) < tolerance
> > Linfinity norm: equals(a, b, tolerance) = max(abs(ab)) < tolerance
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> I was thinking of that one. [Actually, I use it in unit tests...]
>
> [The L2norm is already available through the "distance" method.]
>
>
> Gilles
>
> 
> To unsubscribe, email: [hidden email]
> For additional commands, email: [hidden email]
>
>

Ted Dunning, CTO
DeepDyve
111 West Evelyn Ave. Ste. 202
Sunnyvale, CA 94086
www.deepdyve.com
8584140013 (m)
4087730220 (fax)


> > L1 norm: equals(a, b, tolerance) = sum(abs(ab)) < tolerance
> > L2 norm: equals(a, b, tolerance) = sqrt(sum((ab)^2)) < tolerance
> > Linfinity norm: equals(a, b, tolerance) = max(abs(ab)) < tolerance
> >
> > All are useful.
>
> I'll guess for 3D vector the L2norm is the more useful as it is
> invariant when physical orthonormal frames are changed.
> I'll check in the variant you prefer.
[Cf. my other reply.]
Should I still create an issue?
Best,
Gilles

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


Absolutely.
On Tue, Apr 28, 2009 at 2:10 PM, Gilles Sadowski <
[hidden email]> wrote:
> > I'll guess for 3D vector the L2norm is the more useful as it is
> > invariant when physical orthonormal frames are changed.
> > I'll check in the variant you prefer.
>
> [Cf. my other reply.]
> Should I still create an issue?
>
>


Gilles Sadowski schrieb:
>>> L1 norm: equals(a, b, tolerance) = sum(abs(ab)) < tolerance
>>> L2 norm: equals(a, b, tolerance) = sqrt(sum((ab)^2)) < tolerance
>>> Linfinity norm: equals(a, b, tolerance) = max(abs(ab)) < tolerance
>>>
>>> All are useful.
>> I'll guess for 3D vector the L2norm is the more useful as it is
>> invariant when physical orthonormal frames are changed.
>> I'll check in the variant you prefer.
>
> [Cf. my other reply.]
> Should I still create an issue?
I'm currently not invovled in commonsmath, but I've written substatntial amount
of numeric software.
My thought on this point is, that it is generally more feasible to implement a
bunch on distance methods like
a.distance1(b) ... L1Norm
a.distance(b) ... L1Norm (this is usually what the user wants as default)
a.distanceInf(b) ... L∞Norm
and have the user decide on what is equal in his particular situation.
There is a very good article on ieee754 equality under
http://www.cygnussoftware.com/papers/comparingfloats/comparingfloats.htmwhich contains an excessive discussion about various "equality" approaches.
IMHO it should be moreover considered to include the "AlomostEquals2sComplement"
method of this paper into commonsmath if not done so far.
Best regards,
Wolfgang

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


Hi.
> There is a very good article on ieee754 equality under
>
> http://www.cygnussoftware.com/papers/comparingfloats/comparingfloats.htm>
> which contains an excessive discussion about various "equality" approaches.
>
> IMHO it should be moreover considered to include the "AlomostEquals2sComplement"
> method of this paper into commonsmath if not done so far.
It would be a nice addition to "util.MathUtils".
I'll open another JIRA issue.
Thanks,
Gilles

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


Gilles Sadowski schrieb:
> Hi.
>
>> There is a very good article on ieee754 equality under
>>
>> http://www.cygnussoftware.com/papers/comparingfloats/comparingfloats.htm>>
>> which contains an excessive discussion about various "equality" approaches.
>>
>> IMHO it should be moreover considered to include the "AlomostEquals2sComplement"
>> method of this paper into commonsmath if not done so far.
>
> It would be a nice addition to "util.MathUtils".
> I'll open another JIRA issue.
Could you please CC me to this issue. I'm surrentyl not involved in
commonsmath, but I'm going to use it in a few weeks. Maybe I can contribute
code and/or testcases to this issue ;)
Regards,
Wolfgang

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


Wolfgang Glas a écrit :
> Gilles Sadowski schrieb:
>> Hi.
>>
>>> There is a very good article on ieee754 equality under
>>>
>>> http://www.cygnussoftware.com/papers/comparingfloats/comparingfloats.htm>>>
>>> which contains an excessive discussion about various "equality" approaches.
>>>
>>> IMHO it should be moreover considered to include the "AlomostEquals2sComplement"
>>> method of this paper into commonsmath if not done so far.
>> It would be a nice addition to "util.MathUtils".
>> I'll open another JIRA issue.
>
> Could you please CC me to this issue. I'm surrentyl not involved in
> commonsmath, but I'm going to use it in a few weeks. Maybe I can contribute
> code and/or testcases to this issue ;)
Gilles sent me directly the patch, including tests, and I have checked
it in. If you want to check the implementation and the tests, you can
retrieve them from subversion.
Thanks for the help
Luc
>
> Regards,
>
> Wolfgang
>
> 
> To unsubscribe, email: [hidden email]
> For additional commands, email: [hidden email]
>
>

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]

