Talk:BTLT
Longevity
This approach of encoding floats is fine for LSO but won't work for Mono. With Mono we will be using doubles and not floats. The underlying principals that iuf and fui depend upon will be invalid and the code will return wrong results. Writing LSO and Mono safe fui functions has turned out to be trickier then I thought. With Mono it won't be possible to store a double in an integer without truncating it to a float first; doing this goes against the design goal of BTLT which is to not corrupt or degrade the input. If I write a version of BTLT targeted for Mono (R3) then it will not be compatible with R2; further more it will not be a simple inline of fui but a new function. Looking to the future HexFloats are looking very attractive. -- Strife Onizuka 00:55, 5 November 2007 (PST)
Most of BTLT is Mono Unsafe code regardless (it means that if the source is compiled from LSL to CIL instead of LSO to CIL it will return wrong results). -- Strife Onizuka 01:05, 5 November 2007 (PST)
There would be a loss in precision by truncating the doubles to floats, and I agree that that is against the concept of BTLT, but I also think that this loss isn't so bad. So long as anyone who uses this library knows that it maxes out as a float, then there is no harm. I like doubles, but most of the time that level of precision is not needed. Hehe, most builders only use 3 decimal places... I chose this library because I was worried about the memory usage of the list of BTLT'd lists I am storing my data in, HexFloats take up a lot more space. I sure hope that they allow true arrays (as in the C/C++/D/Java concept, not the BASIC multidimensional arrays,) when we go to the Mono CIL... Cron Stardust 23:23, 5 November 2007 (PST)
A bug in stiufv/vfuist
I was trying to use BTLT in one of my projects, and I kept noticing that the vectors were not coming beck out correctly, so I built a simple test script to demo what I thought I was observing, and sure enough, the first value in every vector I gave BTLT came back out incorrect. So, after some sniffing around the code, I came up with this fix:
| Code: BTLT stiufv/vfuist fix |
vector stiufv(string in)
{ //-XXXXYYYYZZZZ
integer raw = llBase64ToInteger(llGetSubString("AAA" + in + "AAAAAA", 0, 5)) >> 2;
integer offset = 1;
integer len = raw & 7;
return <stiuf(llDeleteSubString(in, len + 2, 1)),
stiuf(llDeleteSubString(in, (len = (7 & (raw >> 3))) - ~(offset += len), offset)),
stiuf(llDeleteSubString(in, 0, offset + len)) >;
}
string vfuist(vector in)
{
string buf = fuist(in.y);
integer len = llStringLength(buf);
return llGetSubString(llIntegerToBase64(((len << 3) | llStringLength(buf)) << 2), 3, 4) + (buf = fuist(in.x)) + buf + fuist(in.z);
} //-XXXXYYYYZZZZ
|
I can't say that I understood all the code, I am still not up to the level of understanding code this optimized... But I compared these vector functions to the (working) rotation functions to come up with this fix, and found that it seems to work! Cron Stardust 21:06, 4 November 2007 (PST)
- I'm going to verify the logic of your fix before I add it officially. -- Strife Onizuka 23:55, 4 November 2007 (PST)
- Your solution is essentially R1 vfuist-stiufv, it uses two leading characters like that of rfoist-stiufr. R2 (which is what I released) uses one leading character. To write R2 I just stripped first character as it wasn't needed. Unfortunately I forgot to adjust the string offset in stiufv. Below you will find a corrected stiufv function. -- Strife Onizuka 00:55, 5 November 2007 (PST)
| Code: BTLT stiufv fix |
vector stiufv(string in) //Mono Unsafe, LSO Safe, Double Unsafe
{ //-XXXXYYYYZZZZ
integer raw = llBase64ToInteger(llGetSubString("AAAA" + in + "AA", 0, 5)) >> 2;
integer offset = 0;
integer len = raw & 7;
return <stiuf(llDeleteSubString(in, -~len, 0)),
stiuf(llDeleteSubString(in, (len = (7 & (raw >> 3))) - ~(offset += len), offset)),
stiuf(llDeleteSubString(in, 0, offset + len)) >;
}
|