Talk:BTLT - Revision history

Strife Onizuka at 16:42, 1 February 2008

2008-02-01T16:42:31Z

← Older revision		Revision as of 09:42, 1 February 2008
Line 7:		Line 7:
	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)		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)

	~~== A bug in stiufv/vfuist ==~~		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)

	~~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:

	~~{{Box Code\|BTLT stiufv/vfuist fix\|<pre>~~
	~~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~~
	~~</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)~~

	:I'm ~~going to verify~~ the ~~logic of your fix before I add~~ it ~~officially~~. ~~-- [[User:Strife Onizuka\|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~~. -- [[User:Strife Onizuka\|Strife Onizuka]] 00:55, ~~5 November 2007~~ (PST)

	~~{{Box Code\|BTLT stiufv fix\|<pre>~~
	~~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)) >;~~
	~~}</pre>}}~~

Cron Stardust: /* Longevity */ Arguments for making BTLT Mono-safe even with truncation.

2007-11-06T07:23:52Z

Longevity: Arguments for making BTLT Mono-safe even with truncation.

← Older revision		Revision as of 00:23, 6 November 2007
Line 4:		Line 4:

	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)		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)

			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)

	== A bug in stiufv/vfuist ==		== A bug in stiufv/vfuist ==

Strife Onizuka: /* Longevity */

2007-11-05T09:05:44Z

Longevity

← Older revision		Revision as of 02:05, 5 November 2007
Line 2:		Line 2:

	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)		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)

			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)

	== A bug in stiufv/vfuist ==		== A bug in stiufv/vfuist ==

Strife Onizuka: /* A bug in stiufv/vfuist */

2007-11-05T08:56:10Z

A bug in stiufv/vfuist

← Older revision		Revision as of 01:56, 5 November 2007
Line 41:		Line 41:
	stiuf(llDeleteSubString(in, (len = (7 & (raw >> 3))) - ~(offset += len), offset)),		stiuf(llDeleteSubString(in, (len = (7 & (raw >> 3))) - ~(offset += len), offset)),
	stiuf(llDeleteSubString(in, 0, offset + len)) >;		stiuf(llDeleteSubString(in, 0, offset + len)) >;
	}</pre>		}</pre>}}

Strife Onizuka at 08:55, 5 November 2007

2007-11-05T08:55:13Z

← Older revision		Revision as of 01:55, 5 November 2007
Line 1:		Line 1:
			== 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. -- [[User:Strife Onizuka\|Strife Onizuka]] 00:55, 5 November 2007 (PST)

	== A bug in stiufv/vfuist ==		== A bug in stiufv/vfuist ==

Line 25:		Line 29:

	:I'm going to verify the logic of your fix before I add it officially. -- [[User:Strife Onizuka\|Strife Onizuka]] 23:55, 4 November 2007 (PST)		:I'm going to verify the logic of your fix before I add it officially. -- [[User:Strife Onizuka\|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. -- [[User:Strife Onizuka\|Strife Onizuka]] 00:55, 5 November 2007 (PST)

			{{Box Code\|BTLT stiufv fix\|<pre>
			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)) >;
			}</pre>

Strife Onizuka at 07:55, 5 November 2007

2007-11-05T07:55:10Z

← Older revision		Revision as of 00:55, 5 November 2007
Line 23:		Line 23:

	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)		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)

			:I'm going to verify the logic of your fix before I add it officially. -- [[User:Strife Onizuka\|Strife Onizuka]] 23:55, 4 November 2007 (PST)

Cron Stardust: /* A bug in stiufv/vfuist */ Realized that there was one little grub hiding from me...

2007-11-05T06:02:29Z

A bug in stiufv/vfuist: Realized that there was one little grub hiding from me...

← Older revision		Revision as of 23:02, 4 November 2007
Line 9:		Line 9:
	integer offset = 1;		integer offset = 1;
	integer len = raw & 7;		integer len = raw & 7;
	return <stiuf(llDeleteSubString(in, -~len, 1)),		return <stiuf(llDeleteSubString(in, len + 2, 1)),
	stiuf(llDeleteSubString(in, (len = (7 & (raw >> 3))) - ~(offset += len), offset)),		stiuf(llDeleteSubString(in, (len = (7 & (raw >> 3))) - ~(offset += len), offset)),
	stiuf(llDeleteSubString(in, 0, offset + len)) >;		stiuf(llDeleteSubString(in, 0, offset + len)) >;

Cron Stardust: Info on bug in the vector conversion functions.

2007-11-05T05:06:34Z

Info on bug in the vector conversion functions.

New page

== 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:

{{Box Code|BTLT stiufv/vfuist fix|<pre>
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, 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
</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)