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> > 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. > >> 2. 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. 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. Regards, Michael Karcher
