Michael Karcher wrote:
Am Sonntag, den 13.07.2008, 13:51 +0400 schrieb Nikolay Sivov:
Reece Dunn wrote:
Is this the way it works on Windows? You have 4 basic cases: a. exactly equal; b. equal + epsilon for rounding/representation errors; c. equal - epsilon for rounding/representation errors; d. not equal.
I don't see a difference between b and c. A matrix has four elements. Some might be slightly too big and others slightly too small. Would this make b or c? It's just one case: equal +/- epsilon.
Exactly, so I plan to test this deeper on native. As I see now after some basic tests, most probably native call does a bitwise comparison cause the result is affected by a smallest matrix element change (e.g. 1.0000000f -> 1.0000001f). But I'll test it more.
1+FLT_EPSILON is the value to use for the "smallest matrix element change". But sour test already is a very strong indication that it really is strict equality test. FLT_EPSILON is in <float.h>
This header is optional, isn't it? I've used FLT_EPSILON in call PlgBlt of gdi32, but it was replaced with 1e-5 on commit (it was fabs(det) < FLT_EPSILON). So am I right that we can't use it on portability reason?
Reece, do you have any suggestions to do some bounds test (I mean test is call affected by representation or round errors or not)?
Another thing you could test is: Is the Matrix (1,FLT_EPSILON/2,0,1) equal to (1,0,0,1). A matrix like te former can easily be the result of multiplying a matrix by its inverse matrix (if represented as floating point numbers). One might expect that the product of a matrix and its inverse always is the identity matrix.
I'll try that.
- GdipIsMatrixInvertible which contains a check for 'not above zero'
determinant.
a. det(A) > 0 b. det(A) == 0 c. det(A) < 0
So does Windows match your assumption for the answer to these (a ==> yes; b, c ==> no).
What do you mean here by (c => no)? Native allows negative det and I do so.
He implied it form your "not above zero" quote.
Yes, I meant absolute value of course.
A hint how I would implement that test (if it turns out that a strict comparison to 0 is not the right result): Do not calculate the sum of a*d and -b*c, but compare these numbers in a sensible way.
Here I something like FLT_EPSILON constant. So it's the same like above.
Regards, Michael Karcher