Talk:Float2Hex - Revision history

Strife Onizuka: /* crash */

2015-09-14T20:32:30Z

crash

← Older revision		Revision as of 13:32, 14 September 2015
Line 165:		Line 165:

	[[User:Miranda Umino\|Miranda Umino]] ([[User talk:Miranda Umino\|talk]]) 17:40, 13 September 2015 (PDT)		[[User:Miranda Umino\|Miranda Umino]] ([[User talk:Miranda Umino\|talk]]) 17:40, 13 September 2015 (PDT)

			:I'll work on fixing this. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 13:32, 14 September 2015 (PDT)

Miranda Umino at 00:40, 14 September 2015

2015-09-14T00:40:57Z

← Older revision		Revision as of 17:40, 13 September 2015
Line 164:		Line 164:
	It creates a division by 0		It creates a division by 0

	[[User:Miranda Umino\|Miranda Umino]] ([[User talk:Miranda Umino\|talk]])		[[User:Miranda Umino\|Miranda Umino]] ([[User talk:Miranda Umino\|talk]]) 17:40, 13 September 2015 (PDT)

Miranda Umino at 23:44, 13 September 2015

2015-09-13T23:44:19Z

← Older revision		Revision as of 16:44, 13 September 2015
Line 149:		Line 149:

	:Yeah, maybe that wasn't a good idea. -- [[User:Kireji Haiku\|Kireji Haiku]] 23:15, 8 October 2013 (PDT)		:Yeah, maybe that wasn't a good idea. -- [[User:Kireji Haiku\|Kireji Haiku]] 23:15, 8 October 2013 (PDT)



			== crash ==

			<source lang="lsl2">
			float a = iuf(1 << 21);
			string s=Float2Hex( a);
			</source>
			makes crash the script at line ( and with input of iuf every values inferior to 2 097 152 )
			unsigned /= (float)("0x1p"+(string)(exponent -= ((exponent >> 31) \| 1)));

			exponent in input of this line is valued to -128.
			It creates a division by 0

			[[User:Miranda Umino\|Miranda Umino]] ([[User talk:Miranda Umino\|talk]])

Kireji Haiku: /* count: -1 vs ERR_GENERIC */

2013-10-09T06:15:13Z

count: -1 vs ERR_GENERIC

← Older revision		Revision as of 23:15, 8 October 2013
Line 147:		Line 147:
	The implied type of "count", eg what "count" represents is not error, so using [[ERR_GENERIC]] for it's default state is not valid. The reason it starts at -1 instead of zero has everything to do with optimization. Using ERR_GENERIC in this case confuses and obfuscates the meaning of the code.		The implied type of "count", eg what "count" represents is not error, so using [[ERR_GENERIC]] for it's default state is not valid. The reason it starts at -1 instead of zero has everything to do with optimization. Using ERR_GENERIC in this case confuses and obfuscates the meaning of the code.
	'''tl:dr;''' -1 is the value I'm using. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 14:01, 8 October 2013 (PDT)		'''tl:dr;''' -1 is the value I'm using. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 14:01, 8 October 2013 (PDT)

			:Yeah, maybe that wasn't a good idea. -- [[User:Kireji Haiku\|Kireji Haiku]] 23:15, 8 October 2013 (PDT)

Strife Onizuka: /* count: -1 vs ERR_GENERIC */ new section

2013-10-08T21:01:58Z

count: -1 vs ERR_GENERIC: new section

← Older revision		Revision as of 14:01, 8 October 2013
Line 142:		Line 142:

	:You want my other function [[User:Strife_Onizuka/Float_Functions#Float_.3C-Union-.3E_Integer\|FUI]]. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 22:03, 17 April 2013 (PDT)		:You want my other function [[User:Strife_Onizuka/Float_Functions#Float_.3C-Union-.3E_Integer\|FUI]]. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 22:03, 17 April 2013 (PDT)

			== count: -1 vs [[ERR_GENERIC]] ==

			The implied type of "count", eg what "count" represents is not error, so using [[ERR_GENERIC]] for it's default state is not valid. The reason it starts at -1 instead of zero has everything to do with optimization. Using ERR_GENERIC in this case confuses and obfuscates the meaning of the code.
			'''tl:dr;''' -1 is the value I'm using. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 14:01, 8 October 2013 (PDT)

Strife Onizuka: /* Float2String w/o Rounding */

2013-09-23T04:18:36Z

Float2String w/o Rounding

← Older revision		Revision as of 21:18, 22 September 2013
Line 20:		Line 20:
	::I'll also go into the literature for float to string conversion algorithms and see if, perhaps, a better one could be found. I've found most C implementations are usually portable to LSL, it's just a matter of finding one that is documented well. If worse comes to worse, I'll delve into the sprintf() library. lol		::I'll also go into the literature for float to string conversion algorithms and see if, perhaps, a better one could be found. I've found most C implementations are usually portable to LSL, it's just a matter of finding one that is documented well. If worse comes to worse, I'll delve into the sprintf() library. lol
	::Thank you for your help! --[[User:LepreKhaun Resident\|LepreKhaun Resident]] 17:50, 22 September 2013 (PDT)		::Thank you for your help! --[[User:LepreKhaun Resident\|LepreKhaun Resident]] 17:50, 22 September 2013 (PDT)
	:::Once upon a time I did dive into the various libraries to see how they worked, because I didn't want to have to write my own implementation, I ended up writing my own. ~~My experience was that~~ I didn't find one that maintain the precision.		:::Once upon a time I did dive into the various libraries to see how they worked, because I didn't want to have to write my own implementation, I ended up writing my own. I didn't find one that maintain the precision.-- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 21:17, 22 September 2013 (PDT)

	:I'd be interested to know if llJson2List is susceptible to an analog of the Mono denormalized range (float) bug. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:55, 21 September 2013 (PDT)		:I'd be interested to know if llJson2List is susceptible to an analog of the Mono denormalized range (float) bug. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:55, 21 September 2013 (PDT)

Strife Onizuka: /* Float2String w/o Rounding */

2013-09-23T04:17:52Z

Float2String w/o Rounding

← Older revision		Revision as of 21:17, 22 September 2013
Line 20:		Line 20:
	::I'll also go into the literature for float to string conversion algorithms and see if, perhaps, a better one could be found. I've found most C implementations are usually portable to LSL, it's just a matter of finding one that is documented well. If worse comes to worse, I'll delve into the sprintf() library. lol		::I'll also go into the literature for float to string conversion algorithms and see if, perhaps, a better one could be found. I've found most C implementations are usually portable to LSL, it's just a matter of finding one that is documented well. If worse comes to worse, I'll delve into the sprintf() library. lol
	::Thank you for your help! --[[User:LepreKhaun Resident\|LepreKhaun Resident]] 17:50, 22 September 2013 (PDT)		::Thank you for your help! --[[User:LepreKhaun Resident\|LepreKhaun Resident]] 17:50, 22 September 2013 (PDT)
			:::Once upon a time I did dive into the various libraries to see how they worked, because I didn't want to have to write my own implementation, I ended up writing my own. My experience was that I didn't find one that maintain the precision.

	:I'd be interested to know if llJson2List is susceptible to an analog of the Mono denormalized range (float) bug. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:55, 21 September 2013 (PDT)		:I'd be interested to know if llJson2List is susceptible to an analog of the Mono denormalized range (float) bug. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:55, 21 September 2013 (PDT)
	<lsl>		<lsl>
	llOwnerSay("Typecast: "+llList2String(["Bad", "Good"], 0.0 != (float)"1.~~175494351E~~-38"));		llOwnerSay("Typecast: "+llList2String(["Bad", "Good"], 0.0 != (float)"1.5e-45"));
	llOwnerSay("llJson2List: "+llList2String(["Bad", "Good"], 0.0 != llList2Float(llJson2List("1.~~175494351E~~-38"), 0)));		llOwnerSay("llJson2List: "+llList2String(["Bad", "Good"], 0.0 != llList2Float(llJson2List("1.5e-45"), 0)));
	</lsl>		</lsl>
	::Both return "Good", so that shouldn't be a problem. (took the liberty of adding the missing parenthesis to your code). -- [[User:LepreKhaun Resident\|LepreKhaun Resident]] 17:50, 22 September 2013 (PDT)		::Both return "Good", so that shouldn't be a problem. (took the liberty of adding the missing parenthesis to your code). -- [[User:LepreKhaun Resident\|LepreKhaun Resident]] 17:50, 22 September 2013 (PDT)

			:::Thanks for the fix. I just realized I used the wrong value. Random link [[http://babbage.cs.qc.cuny.edu/IEEE-754/]]. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 21:17, 22 September 2013 (PDT)

	== Ok, well, let's see. ==		== Ok, well, let's see. ==

LepreKhaun Resident: /* Float2String w/o Rounding */

2013-09-23T00:50:56Z

Float2String w/o Rounding

← Older revision		Revision as of 17:50, 22 September 2013
Line 17:		Line 17:

	:But this is irrelevant, JSON does not support hex-floats. You want [[Float2Sci]], which is dreadfully slow. I should really try to find a better way of doing it (without a loop). I wonder if optical error correction would be faster? If you don't care about having to do some processing to read your data, I might suggest [[User:Strife_Onizuka/Float_Functions#Base64-Float\|Base64-Float]]. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:33, 21 September 2013 (PDT)		:But this is irrelevant, JSON does not support hex-floats. You want [[Float2Sci]], which is dreadfully slow. I should really try to find a better way of doing it (without a loop). I wonder if optical error correction would be faster? If you don't care about having to do some processing to read your data, I might suggest [[User:Strife_Onizuka/Float_Functions#Base64-Float\|Base64-Float]]. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:33, 21 September 2013 (PDT)
			:: I was afraid that [[Float2Sci]] would be what I needed, sigh. I'll try to modify it to take an integer of desired precision, where it won't necessarily return 47 decimal places if only 10 are required by the user and that may speed execution. But this utility could not be used in time critical apps in any sense since Json text manipulations in LSL are very slow to begin with!
			::I'll also go into the literature for float to string conversion algorithms and see if, perhaps, a better one could be found. I've found most C implementations are usually portable to LSL, it's just a matter of finding one that is documented well. If worse comes to worse, I'll delve into the sprintf() library. lol
			::Thank you for your help! --[[User:LepreKhaun Resident\|LepreKhaun Resident]] 17:50, 22 September 2013 (PDT)
	:I'd be interested to know if llJson2List is susceptible to an analog of the Mono denormalized range (float) bug. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:55, 21 September 2013 (PDT)		:I'd be interested to know if llJson2List is susceptible to an analog of the Mono denormalized range (float) bug. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:55, 21 September 2013 (PDT)
	<lsl>		<lsl>
	llOwnerSay("Typecast: "+llList2String(["Bad", "Good"], 0.0 != (float)"1.175494351E-38"));		llOwnerSay("Typecast: "+llList2String(["Bad", "Good"], 0.0 != (float)"1.175494351E-38"));
	llOwnerSay("llJson2List: "+llList2String(["Bad", "Good"], 0.0 != llList2Float(llJson2List("1.175494351E-38"), 0));		llOwnerSay("llJson2List: "+llList2String(["Bad", "Good"], 0.0 != llList2Float(llJson2List("1.175494351E-38"), 0)));
	</lsl>		</lsl>
			::Both return "Good", so that shouldn't be a problem. (took the liberty of adding the missing parenthesis to your code). -- [[User:LepreKhaun Resident\|LepreKhaun Resident]] 17:50, 22 September 2013 (PDT)

	== Ok, well, let's see. ==		== Ok, well, let's see. ==

Strife Onizuka: /* Float2String w/o Rounding */

2013-09-22T07:09:03Z

Float2String w/o Rounding

← Older revision		Revision as of 00:09, 22 September 2013
Line 16:		Line 16:
	:But then I realized that it didn't matter because for the vast majority of integer values the integer encoding was smaller than the hex encoding, be it integer or float. Yes it would be possible to catch those cases where hex float encoding would be superior to integer encoding but it would bloat the code and make it slower.		:But then I realized that it didn't matter because for the vast majority of integer values the integer encoding was smaller than the hex encoding, be it integer or float. Yes it would be possible to catch those cases where hex float encoding would be superior to integer encoding but it would bloat the code and make it slower.

	:But this is irrelevant, JSON does not support hex-floats. You want [[Float2Sci]], which is dreadfully slow. I should really try to find a better way of doing it (without a loop). I wonder if optical error correction would be faster? If you don't care about having to do some processing to read your data, I might suggest [[User:Strife_Onizuka/Float_Functions#Base64-Float]]. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:33, 21 September 2013 (PDT)		:But this is irrelevant, JSON does not support hex-floats. You want [[Float2Sci]], which is dreadfully slow. I should really try to find a better way of doing it (without a loop). I wonder if optical error correction would be faster? If you don't care about having to do some processing to read your data, I might suggest [[User:Strife_Onizuka/Float_Functions#Base64-Float\|Base64-Float]]. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:33, 21 September 2013 (PDT)

	:I'd be interested to know if llJson2List is susceptible to an analog of the Mono denormalized range (float) bug. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:55, 21 September 2013 (PDT)		:I'd be interested to know if llJson2List is susceptible to an analog of the Mono denormalized range (float) bug. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:55, 21 September 2013 (PDT)

Strife Onizuka: /* Float2String w/o Rounding */

2013-09-22T06:55:03Z

Float2String w/o Rounding

← Older revision		Revision as of 23:55, 21 September 2013
Line 17:		Line 17:

	:But this is irrelevant, JSON does not support hex-floats. You want [[Float2Sci]], which is dreadfully slow. I should really try to find a better way of doing it (without a loop). I wonder if optical error correction would be faster? If you don't care about having to do some processing to read your data, I might suggest [[User:Strife_Onizuka/Float_Functions#Base64-Float]]. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:33, 21 September 2013 (PDT)		:But this is irrelevant, JSON does not support hex-floats. You want [[Float2Sci]], which is dreadfully slow. I should really try to find a better way of doing it (without a loop). I wonder if optical error correction would be faster? If you don't care about having to do some processing to read your data, I might suggest [[User:Strife_Onizuka/Float_Functions#Base64-Float]]. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:33, 21 September 2013 (PDT)

			:I'd be interested to know if llJson2List is susceptible to an analog of the Mono denormalized range (float) bug. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:55, 21 September 2013 (PDT)
			<lsl>
			llOwnerSay("Typecast: "+llList2String(["Bad", "Good"], 0.0 != (float)"1.175494351E-38"));
			llOwnerSay("llJson2List: "+llList2String(["Bad", "Good"], 0.0 != llList2Float(llJson2List("1.175494351E-38"), 0));
			</lsl>

	== Ok, well, let's see. ==		== Ok, well, let's see. ==