Difference between revisions of "Talk:BTLT"

From Second Life Wiki
Jump to navigation Jump to search
(→‎A bug in stiufv/vfuist: Realized that there was one little grub hiding from me...)
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== A bug in stiufv/vfuist ==
== Longevity ==


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:
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. -- [[User:Strife Onizuka|Strife Onizuka]] 00:55, 5 November 2007 (PST)


{{Box Code|BTLT stiufv/vfuist fix|<pre>
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). -- [[User:Strife Onizuka|Strife Onizuka]] 01:05, 5 November 2007 (PST)
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)
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... [[User:Cron Stardust|Cron Stardust]] 23:23, 5 November 2007 (PST)
{
    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
</pre>}}


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!  [[User:Cron Stardust|Cron Stardust]] 21:06, 4 November 2007 (PST)
Good news, Mono doesn't use doubles. I will be releasing a new version shortly (I'm just putting the finishing touches on it). It will be faster and better support mono. I have some fresh ideas that I want to try, the format won't change but the functions will. -- [[User:Strife Onizuka|Strife Onizuka]] 08:42, 1 February 2008 (PST)

Latest revision as of 08:42, 1 February 2008

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)

Good news, Mono doesn't use doubles. I will be releasing a new version shortly (I'm just putting the finishing touches on it). It will be faster and better support mono. I have some fresh ideas that I want to try, the format won't change but the functions will. -- Strife Onizuka 08:42, 1 February 2008 (PST)

Retrieved from "https://wiki.secondlife.com/w/index.php?title=Talk:BTLT&oldid=52299"