SIMD test failures on non-ENU configurations.

[FiveTimesTheFun]

After pulling both of @adamralph 's pull requests dotnet/corefx#31 and dotnet/corefx#32, I'm continuing to see test failures for SIMD on a DEU (German) test environment.

Here's a representative error:
d:\oss\corefx\src\System.Numerics.Vectors\tests\GenericVectorTests.cs(545): error : System.Numerics.Tests.GenericVe
ctorTests.ToStringCurrencySByte: Assert.Equal() Failure\r\nPosition: First difference is at position 8\r\nExpected:
<97,00 ?, -108,00 ?, 22,00 ?, 29,00 ?, 49,00 ?, 60,00 ?, 103,00 ?, 58,00 ?, -62,00 ?, -124,00 ?, -117,00 ?, 48,00
?, 15,00 ?, -35,00 ?, -13,00 ?, -34,00 ?>\r\nActual: <97,00 ?. -108,00 ?. 22,00 ?. 29,00 ?. 49,00 ?. 60,00 ?. 103
,00 ?. 58,00 ?. -62,00 ?. -124,00 ?. -117,00 ?. 48,00 ?. 15,00 ?. -35,00 ?. -13,00 ?. -34,00 ?> [D:\oss\corefx\bin
tools\fxbuild.proj]

Observe that expected separates elements with a comma, actual separates elements with a dot.

[adamralph]

There's probably little more to consider here:

• the ToString(string format, IFormatProvider formatProvider) methods are using NumberFormatInfo.NumberGroupSeparator to separate the value lists. This property is supposed to be used for separating digit groups in a numeric value. It should really be using TextInfo.ListSeperator but, as of yet, I haven't found good way to get an appropriate TextInfo instance from a given IFormatProvider.
• Rather than putting all the specific bits of logic into the tests to mimick, and largely repeat, the logic of the ToString(string format, IFormatProvider formatProvider) in order to construct an expected string, I think it would be better for the tests to set the culture of the current thread explicitly (with an appropriate revert in a finally) and then test the resulting string against a fixed expected string. This will be less brittle and will guarantee success on any machine, regardless of local culture settings.

[adamralph]

OK, I'm not sure my tests idea is possible - System.Threading.Thread is not available in the target profile 😢.

[mellinoe]

Although we can't set the current culture for this, we can call the ToString overloads with explicit culture info's to use, at least for Vector2/3/4, which support that interface. In the future all of the types should probably support IFormattable, but currently that's not the case (string formatting hasn't been a high priority for these types so far :) ).

I agree with your second bullet point above as well. For now we can fix the tests as they currently behave (by just fixing them on all cultures), but we should add another test that checks against a set of known strings for different cultures. There is no such coverage right now.

[mellinoe]

The tests should now run properly on any culture, as of this morning's merges. From the above discussion we should look into adding a test case (or a couple) verifying the behavior in specific cultures (not just en-us like right now) against well-known values.