It used `a = lst[i]` instead of taking the stride index into account (that is, it should have been `a = lst[i+idx]`). Anyway, the exact same value is in b, so use that instead.
Test case by Tapple Gao.
The official distribution of Python 2.7 on Windows is built with "narrow strings" (UTF-16 strings with no proper indexing or length). This makes some tests fail. "Fix" this by monkey-patching a few functions and using a wrapping unicode class, as we can't monkey-patch the actual unicode type.
This is very fragile code, but it's the best we could do given the limitations.
Previously, llChar formed an UTF-8-1993 string with the given code and converted that, resulting in multiple question marks when the conversion to Unicode forced by Mono caused errors in multiple characters. They have changed the implementation and now it also considers U+FFFF invalid, and only returns one U+FFFD character if the input is invalid, and LSO behaves the same as Mono (no UTF-8-1993 anymore).
We've also detected problems with Windows (who else would it be) for the Unicode "astral" planes (planes beyond the Basic Multilingual Plane), so now there are new tests that include characters > U+FFFF. And since some builds of Python 2 use UTF-16 internally, we also check llSubString and friends with positions after an astral plane character. This is currently failing under Windows, as there are numerous encoding and line ending problems happening on that OS, especially with Python 3.
llDumpList2String has changed its behaviour with respect to minus zero. Now it converts -0.0 to a string without the minus sign.
While testing this, we noticed several mismatches in the float to string conversions; the existing routine did not properly convert some values because as we discovered later, it is subject to double rounding; one of them is the built-in round-to-nearest-or-even while getting the first 7 significant digits, and the other is just an increment when the digit is a 5 or more, so round to nearest, ties away from zero, and is performed on the digit past the five or six visible digits that LSL shows.
The new code is a tad easier to understand and more robust.
A first variant of the new code is left commented out for history's sake, and will be removed in the next commit.
This annoyance and discrepancy with LSO was finally fixed by Linden Lab. The change has prompted some modifications to the test suite to accommodate for the new results. A further improvement has been to make these tests more friendly to be run in SL, making it easier to verify the results.
Fixes#17.
Reported by SaladDais@users.noreply.github.com - thanks!
vector * quaternion: Simplified by precalculating the repeated products and removing math.fsum.
quaternion * quaternion: Add more F32's to get a result closer to SL's (still not there, but we're definitively closer now).
We left out quaternion/quaternion in the tests, and the q*q test was not general enough (had many zeros). Remedied that.
(float)"1.1754944e-38" is != 0
(float)"1.1754943e-38" is == 0
Yet, 1.1754944e-38 == 1.1754943e-38.
The fix is to perform the operations as doubles, and convert to F32 *after* comparing the denormal range.
