Both tests are giving opposite results of what you would expect. I have a few other unit tests that check a variety of different things, so I'm sure the problem is just within these tests.
As near as I can tell, the equality/inequality operators only check the first elements of vectors. Can someone confirm that that is true? Is it also true for matrices?
[size=2]Darwinbots - [size=2]Artificial life simulation
The comparison operators are: <, >, ==, !=, <=, >=.
Each of these comparisons can be done with any scalar data type. Comparison operators do not support the complex data types such as vector, matrix, or the object types.[/quote]Off the top of my head, I'd try something like:bool VectorNotEqual( float4 a, float4 b )
{
float4 diff = a-b;
return any(diff);
}
As always with floating-point though, equality tests are dangerous, so don't do this in any places where representation errors can have an effect.
Yeah, I was hoping I could get away with strict equality since it meant I could treat all data types the same and just use ==. But looks like that doesn't work.
Is there a clever way to set things up so that I don't have to know if a data type is a scalar, vector, or matrix? I don't want to have to build unique CheckEqual functions for each possible combination. eg: float2, float3, float4, float1x2, float 1x3, etc. etc.
[size=2]Darwinbots - [size=2]Artificial life simulation
Assuming that the minus operator is per-component on matrix types (it is for vector types), then the [font="'Courier New"]any(a-b)[/font] snippet should actually work for all types.
This test passes:
void Test()
{
float4 diff = (float4(1,1,1,0))-(float4(1,1,1,1));
Check(any(diff));
}
Bu this test does not:
void Test()
{
Check(any((float4(1,1,1,0))-(float4(1,1,1,1))));
}
The only difference, as far as I know, is that the first test stores the result of the subtraction in a temporary variable and the second does not.
The Check macro is defined thusly:
#define Check(isTrue) __unitTestSharpHLSL_isPassing = (__unitTestSharpHLSL_isPassing && (isTrue))
My understanding of HLSL would indicate that these two tests should be the same. I haven't peeked at the assembly yet (that would be the next logical step) but I'm wondering if the issue is obvious and I'm just being dense.
[size=2]Darwinbots - [size=2]Artificial life simulation
This is the generated assembly code for the failing test above. It's precomputed the computation (that's great) but it looks like it's calculated it wrong (that's bad). The test that works is storing the result off to registers. and doing the calculation correctly.
// Not working:
//listing of all techniques and passes with embedded asm listings
Nothing too fancy, just a global at the top of the function.
Here's the complete HLSL which should be compilable yourself, if you want to give it a try (it's modified slightly, so the new asm is at the end of the code. But same problem). The weird white space is because this is actually a composite of files from a few different places.
I confirmed this as a compiler bug with Microsoft.
The fixed version of CheckEqual uses a dummy variable to trick the compiler into using a different code path:
static bool __unitTestSharpHLSL_isPassing;
static float __unitTestSharpHLSL_dummy = 0; // to work around a compiler bug in HLSL