Talk:LlFrand - Revision history

Gwyneth Llewelyn: /* More Random */ whoops one of the bolds needed an explicit |1=

2023-03-13T12:48:56Z

More Random: whoops one of the bolds needed an explicit |1=

← Older revision		Revision as of 05:48, 13 March 2023
Line 20:		Line 20:
	:I agree with you, it's why I added the needs references. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 09:54, 18 February 2012 (PST)		:I agree with you, it's why I added the needs references. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 09:54, 18 February 2012 (PST)

	:It is clearly mathematically provable that it is <b>not</b> "more" random. Given the function will have a pseudo-random output that is distributed over a statistical normal curve, any stream of output from the same will result in exactly the same statistical normal curve. Therefore, if we call the bare function {{bold\|f()}} and the "more random" function {{bold\|f'()}}, the output will be identically spread out over the same distribution, therefore, {{bold\|f() = f'()}}. On the other hand, the "more random" function {{bold\|f'()}} <b>does</b> waste time in a loop.		:It is clearly mathematically provable that it is <b>not</b> "more" random. Given the function will have a pseudo-random output that is distributed over a statistical normal curve, any stream of output from the same will result in exactly the same statistical normal curve. Therefore, if we call the bare function {{bold\|f()}} and the "more random" function {{bold\|f'()}}, the output will be identically spread out over the same distribution, therefore, {{bold\|1=f() = f'()}}. On the other hand, the "more random" function {{bold\|f'()}} <b>does</b> waste time in a loop.

	:<syntaxhighlight lang="lsl2">		:<syntaxhighlight lang="lsl2">

Gwyneth Llewelyn: /* More Random */ Replaced with and preserved intended indent

2023-03-13T12:48:08Z

More Random: Replaced <source> with <syntaxhighlight> and preserved intended indent

← Older revision		Revision as of 05:48, 13 March 2023
Line 20:		Line 20:
	:I agree with you, it's why I added the needs references. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 09:54, 18 February 2012 (PST)		:I agree with you, it's why I added the needs references. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 09:54, 18 February 2012 (PST)

	:It is clearly mathematically provable that it is <b>not</b> "more" random. Given the function will have a ~~psuedo~~-random output that is distributed over a statistical normal curve, any stream of output from the same will result in exactly the same statistical normal curve. Therefore, if we call the bare function f() and the "more random" function f'(), the output will be identically spread out over the same distribution, therefore, f() = f'(). On the other hand, the "more random" function f'() <b>does</b> waste time in a loop.		:It is clearly mathematically provable that it is <b>not</b> "more" random. Given the function will have a pseudo-random output that is distributed over a statistical normal curve, any stream of output from the same will result in exactly the same statistical normal curve. Therefore, if we call the bare function {{bold\|f()}} and the "more random" function {{bold\|f'()}}, the output will be identically spread out over the same distribution, therefore, {{bold\|f() = f'()}}. On the other hand, the "more random" function {{bold\|f'()}} <b>does</b> waste time in a loop.

	<~~source~~ lang="lsl2">		:<syntaxhighlight lang="lsl2">
	integer r_seed;		integer r_seed;
	integer f_seed;		integer f_seed;
Line 29:		Line 29:
	init() {		init() {
	vector v;		vector v;
	v=llGetPos();		v = llGetPos();
	r_seed=llGetUnixTime()+((integer)v.x*(integer)v.y);		r_seed = llGetUnixTime()+((integer)v.x*(integer)v.y);
	f_seed=r_seed*(integer)(v.x-v.y);		f_seed = r_seed*(integer)(v.x-v.y);
	}		}

Line 49:		Line 49:
	//--------------------------//		//--------------------------//
	string trim(float num,integer n) {		string trim(float num,integer n) {
	string txt;		string txt;
	txt=(string)num;		txt=(string)num;
	return llGetSubString(txt,0,llSubStringIndex(txt,".")+n);		return llGetSubString(txt,0,llSubStringIndex(txt,".")+n);
Line 64:		Line 64:
	//--------------------------//		//--------------------------//
	touch_start(integer num) {		touch_start(integer num) {
	integer x;		integer x;
	string msg;		string msg;
	float avg;		float avg;
	float f;		float f;

	msg="\n\nllFrand()::\n";		msg="\n\nllFrand()::\n";
Line 90:		Line 90:
	msg+="\n\ntanya_rand() average: "+trim(avg,3);		msg+="\n\ntanya_rand() average: "+trim(avg,3);
	llOwnerSay(msg);		llOwnerSay(msg);

	}		}

	}		}
	</~~source~~>		</syntaxhighlight>
	-- [[User:Tanya Avon\|Tanya Avon]] 13:26, 10 September 2012 (PDT)		-- [[User:Tanya Avon\|Tanya Avon]] 13:26, 10 September 2012 (PDT)

Gwyneth Llewelyn: /* Known Issues */ Replaced

 with , preserved intended indent

2023-03-13T00:26:14Z

Known Issues: Replaced <pre> with <syntaxhighlight>, preserved intended indent

← Older revision		Revision as of 17:26, 12 March 2023
Line 3:		Line 3:

	:ummm thats not good. I was rather fond of the old method. Why not use the copysign function found in "math.h" after stripping the sign to put it back on? (C99 revisions of glibc will support it aka, won't be in windows but will be in any recent version of linux GCC). Something like:		:ummm thats not good. I was rather fond of the old method. Why not use the copysign function found in "math.h" after stripping the sign to put it back on? (C99 revisions of glibc will support it aka, won't be in windows but will be in any recent version of linux GCC). Something like:
	<~~pre~~>		:<syntaxhighlight lang="c">
	include ~~<~~math.h~~>~~		include <math.h>

	float llFrand(float range)		float llFrand(float range)
	{		{
	return copysign(new_method(fabsf(range)), range);		return copysign(new_method(fabsf(range)), range);
	}		}</syntaxhighlight>
	</~~pre~~>
	:QED [[User:Strife Onizuka\|Strife Onizuka]] 18:45, 31 January 2007 (PST)		:QED [[User:Strife Onizuka\|Strife Onizuka]] 18:45, 31 January 2007 (PST)

Kadah Coba: Fixed source tags

2023-01-24T08:21:35Z

Fixed source tags

← Older revision		Revision as of 01:21, 24 January 2023
Line 23:		Line 23:
	:It is clearly mathematically provable that it is <b>not</b> "more" random. Given the function will have a psuedo-random output that is distributed over a statistical normal curve, any stream of output from the same will result in exactly the same statistical normal curve. Therefore, if we call the bare function f() and the "more random" function f'(), the output will be identically spread out over the same distribution, therefore, f() = f'(). On the other hand, the "more random" function f'() <b>does</b> waste time in a loop.		:It is clearly mathematically provable that it is <b>not</b> "more" random. Given the function will have a psuedo-random output that is distributed over a statistical normal curve, any stream of output from the same will result in exactly the same statistical normal curve. Therefore, if we call the bare function f() and the "more random" function f'(), the output will be identically spread out over the same distribution, therefore, f() = f'(). On the other hand, the "more random" function f'() <b>does</b> waste time in a loop.

	<~~lsl~~>		<source lang="lsl2">
	integer r_seed;		integer r_seed;
	integer f_seed;		integer f_seed;
Line 95:		Line 95:

	}		}
	</~~lsl~~>		</source>
	-- [[User:Tanya Avon\|Tanya Avon]] 13:26, 10 September 2012 (PDT)		-- [[User:Tanya Avon\|Tanya Avon]] 13:26, 10 September 2012 (PDT)

Pedro Oval: /* Accurate range for holding an integer as a float */

2013-10-03T19:14:29Z

Accurate range for holding an integer as a float

← Older revision		Revision as of 12:14, 3 October 2013
Line 169:		Line 169:

	>(the 2<sup>25</sup> comes from 2<sup>24</sup> in [0,2<sup>24</sup>) + 2<sup>23</sup> in [2<sup>24</sup>,2<sup>25</sup>) + ... + 2<sup>17</sup> in [2<sup>30</sup>,2<sup>31</sup>) which sums up to 2<sup>25</sup>-2<sup>17</sup>=33423360 but the sentence holds true). I'm in doubt about including the last sentence about the method to extend the range; it might sound too confusing, though it gives a practical solution. (Edit: a reference to an example would be a solution; something like: "Two llFrand calls may be needed to obtain the desired range; see examples below"). --[[User:Pedro Oval\|Pedro Oval]] 03:53, 30 September 2013 (PDT)		>(the 2<sup>25</sup> comes from 2<sup>24</sup> in [0,2<sup>24</sup>) + 2<sup>23</sup> in [2<sup>24</sup>,2<sup>25</sup>) + ... + 2<sup>17</sup> in [2<sup>30</sup>,2<sup>31</sup>) which sums up to 2<sup>25</sup>-2<sup>17</sup>=33423360 but the sentence holds true). I'm in doubt about including the last sentence about the method to extend the range; it might sound too confusing, though it gives a practical solution. (Edit: a reference to an example would be a solution; something like: "Two llFrand calls may be needed to obtain the desired range; see examples below"). --[[User:Pedro Oval\|Pedro Oval]] 03:53, 30 September 2013 (PDT)

			:::::::Sorry, the above is incorrect. There are 2<sup>23</sup> integers in the floats in [2<sup>25</sup>,2<sup>26</sup>), not 2<sup>22</sup>, and so on. They add up to 9*2<sup>23</sup> = 2<sup>26</sup>+2<sup>23</sup>, not to under 2<sup>25</sup>.

			:::::::I'll make the above change (with that correction) in a week if there are no objections. --[[User:Pedro Oval\|Pedro Oval]] 12:14, 3 October 2013 (PDT)

	== Examples ==		== Examples ==

Pedro Oval: /* Accurate range for holding an integer as a float */ Add possible fix

2013-09-30T11:04:54Z

Accurate range for holding an integer as a float: Add possible fix

← Older revision		Revision as of 04:04, 30 September 2013
Line 168:		Line 168:
	> Integers outside the range {{Interval\|lte=+2<sup>24</sup>\|gte=-2<sup>24</sup>\|gteh=-2^24\|lteh=+2^24\|center=integer}} may not be accurately represented (this is an inherent limitation of the float type); for example, outside that range no odd integers will appear. For that reason, when converting the resulting float to integer, it is not possible to generate more than 2<sup>25</sup> different integers. Two llFrand calls may be needed to obtain the desired range using a scheme like <code>(integer)llFrand(a)*b+(integer)llFrand(b)</code> with both <code>a</code> and <code>b</code> less than 2<sup>24</sup>, where the product of <code>a</code> and <code>b</code> equals the target number of values.</li></ul		> Integers outside the range {{Interval\|lte=+2<sup>24</sup>\|gte=-2<sup>24</sup>\|gteh=-2^24\|lteh=+2^24\|center=integer}} may not be accurately represented (this is an inherent limitation of the float type); for example, outside that range no odd integers will appear. For that reason, when converting the resulting float to integer, it is not possible to generate more than 2<sup>25</sup> different integers. Two llFrand calls may be needed to obtain the desired range using a scheme like <code>(integer)llFrand(a)*b+(integer)llFrand(b)</code> with both <code>a</code> and <code>b</code> less than 2<sup>24</sup>, where the product of <code>a</code> and <code>b</code> equals the target number of values.</li></ul

	>(the 2<sup>25</sup> comes from 2<sup>24</sup> in [0,2<sup>24</sup>) + 2<sup>23</sup> in [2<sup>24</sup>,2<sup>25</sup>) + ... + 2<sup>17</sup> in [2<sup>30</sup>,2<sup>31</sup>) which sums up to 2<sup>25</sup>-2<sup>17</sup>=33423360 but the sentence holds true). I'm in doubt about including the last sentence about the method to extend the range; it might sound too confusing, though it gives a practical solution. --[[User:Pedro Oval\|Pedro Oval]] 03:53, 30 September 2013 (PDT)		>(the 2<sup>25</sup> comes from 2<sup>24</sup> in [0,2<sup>24</sup>) + 2<sup>23</sup> in [2<sup>24</sup>,2<sup>25</sup>) + ... + 2<sup>17</sup> in [2<sup>30</sup>,2<sup>31</sup>) which sums up to 2<sup>25</sup>-2<sup>17</sup>=33423360 but the sentence holds true). I'm in doubt about including the last sentence about the method to extend the range; it might sound too confusing, though it gives a practical solution. (Edit: a reference to an example would be a solution; something like: "Two llFrand calls may be needed to obtain the desired range; see examples below"). --[[User:Pedro Oval\|Pedro Oval]] 03:53, 30 September 2013 (PDT)

	== Examples ==		== Examples ==

Pedro Oval: /* Accurate range for holding an integer as a float */ Remove unnecessary repetition

2013-09-30T10:55:37Z

Accurate range for holding an integer as a float: Remove unnecessary repetition

← Older revision		Revision as of 03:55, 30 September 2013
Line 166:		Line 166:

	><li> It should be remembered that when passing llFrand an [[integer]] as the {{LSLP\|mag}}, it will be implicitly [[typecast]] to a [[float]].</li><li		><li> It should be remembered that when passing llFrand an [[integer]] as the {{LSLP\|mag}}, it will be implicitly [[typecast]] to a [[float]].</li><li
	> Integers outside the range {{Interval\|lte=+2<sup>24</sup>\|gte=-2<sup>24</sup>\|gteh=-2^24\|lteh=+2^24\|center=integer}} may not be accurately represented (this is an inherent limitation of the float type); for example, outside ~~the~~ range ~~{{Interval\|lte=+2<sup>24</sup>\|gte=-2<sup>24</sup>\|gteh=-2^24\|lteh=+2^24\|center=integer}}~~ no odd integers will appear. For that reason, when converting the resulting float to integer, it is not possible to generate more than 2<sup>25</sup> different integers. Two llFrand calls may be needed to obtain the desired range using a scheme like <code>(integer)llFrand(a)*b+(integer)llFrand(b)</code> with both <code>a</code> and <code>b</code> less than 2<sup>24</sup>, where the product of <code>a</code> and <code>b</code> equals the target number of values.</li></ul		> Integers outside the range {{Interval\|lte=+2<sup>24</sup>\|gte=-2<sup>24</sup>\|gteh=-2^24\|lteh=+2^24\|center=integer}} may not be accurately represented (this is an inherent limitation of the float type); for example, outside that range no odd integers will appear. For that reason, when converting the resulting float to integer, it is not possible to generate more than 2<sup>25</sup> different integers. Two llFrand calls may be needed to obtain the desired range using a scheme like <code>(integer)llFrand(a)*b+(integer)llFrand(b)</code> with both <code>a</code> and <code>b</code> less than 2<sup>24</sup>, where the product of <code>a</code> and <code>b</code> equals the target number of values.</li></ul

	>(the 2<sup>25</sup> comes from 2<sup>24</sup> in [0,2<sup>24</sup>) + 2<sup>23</sup> in [2<sup>24</sup>,2<sup>25</sup>) + ... + 2<sup>17</sup> in [2<sup>30</sup>,2<sup>31</sup>) which sums up to 2<sup>25</sup>-2<sup>17</sup>=33423360 but the sentence holds true). I'm in doubt about including the last sentence about the method to extend the range; it might sound too confusing, though it gives a practical solution. --[[User:Pedro Oval\|Pedro Oval]] 03:53, 30 September 2013 (PDT)		>(the 2<sup>25</sup> comes from 2<sup>24</sup> in [0,2<sup>24</sup>) + 2<sup>23</sup> in [2<sup>24</sup>,2<sup>25</sup>) + ... + 2<sup>17</sup> in [2<sup>30</sup>,2<sup>31</sup>) which sums up to 2<sup>25</sup>-2<sup>17</sup>=33423360 but the sentence holds true). I'm in doubt about including the last sentence about the method to extend the range; it might sound too confusing, though it gives a practical solution. --[[User:Pedro Oval\|Pedro Oval]] 03:53, 30 September 2013 (PDT)

Pedro Oval: /* Accurate range for holding an integer as a float */

2013-09-30T10:53:40Z

Accurate range for holding an integer as a float

← Older revision		Revision as of 03:53, 30 September 2013
Line 162:		Line 162:

	::::::You want to use 0x1000002 not 0x1000001, 0x1000001 invokes rounding (I think 0x1000000 will be twice as probable in this case to come up than any other number). If it makes things easier I agree, it should be deleted. As to the distribution, to give an even distribution of integers, as the exponent portion of the float increases, the probability for that range doubles. If that is the case, if you pick a really large number llRand(1.7014118346E+38), half the values will be greater than or equal to 8.5070591730E+37, of which there are only 8388608 distinct choices, which leads to a huge likely hood of repeats. Or if the uniform probability stops at 0x1000000 to keep high probability repeats from happening, then you end up with an nonuniform probability. I don't know how to document this nicely without taking the reader quite far down the rabbit hole. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 22:15, 29 September 2013 (PDT)		::::::You want to use 0x1000002 not 0x1000001, 0x1000001 invokes rounding (I think 0x1000000 will be twice as probable in this case to come up than any other number). If it makes things easier I agree, it should be deleted. As to the distribution, to give an even distribution of integers, as the exponent portion of the float increases, the probability for that range doubles. If that is the case, if you pick a really large number llRand(1.7014118346E+38), half the values will be greater than or equal to 8.5070591730E+37, of which there are only 8388608 distinct choices, which leads to a huge likely hood of repeats. Or if the uniform probability stops at 0x1000000 to keep high probability repeats from happening, then you end up with an nonuniform probability. I don't know how to document this nicely without taking the reader quite far down the rabbit hole. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 22:15, 29 September 2013 (PDT)

			:::::::Right, sorry. To give an uniform distribution of integers, you certainly can't use more than llFrand(0x1000002) and probably neither more than llFrand(0x1000000), or there will be integers you won't ever get or that you will get more often than the rest. But let's not miss the forest of utility to the users for the trees of academic correctness; the intention is to add a caveat for those who think they can do (integer)llFrand(999999999) for channel numbers, thinking they are getting 999,999,999 possible channels a possible attacker would need to search through. when they are getting only ~32M; they need two llFrand calls to get the whole range. For example, in that case (integer)llFrand(2997)*333667+(integer)llFrand(333667) would do the job. I think that it's better to remove that sentence and use one similar to the preceding one. After rereading, I think it deserves its own bullet point at the main level, not as part of the one that discusses how mag is inherently converted to float. Here's my proposed wording:<ul

			><li> It should be remembered that when passing llFrand an [[integer]] as the {{LSLP\|mag}}, it will be implicitly [[typecast]] to a [[float]].</li><li
			> Integers outside the range {{Interval\|lte=+2<sup>24</sup>\|gte=-2<sup>24</sup>\|gteh=-2^24\|lteh=+2^24\|center=integer}} may not be accurately represented (this is an inherent limitation of the float type); for example, outside the range {{Interval\|lte=+2<sup>24</sup>\|gte=-2<sup>24</sup>\|gteh=-2^24\|lteh=+2^24\|center=integer}} no odd integers will appear. For that reason, when converting the resulting float to integer, it is not possible to generate more than 2<sup>25</sup> different integers. Two llFrand calls may be needed to obtain the desired range using a scheme like <code>(integer)llFrand(a)*b+(integer)llFrand(b)</code> with both <code>a</code> and <code>b</code> less than 2<sup>24</sup>, where the product of <code>a</code> and <code>b</code> equals the target number of values.</li></ul

			>(the 2<sup>25</sup> comes from 2<sup>24</sup> in [0,2<sup>24</sup>) + 2<sup>23</sup> in [2<sup>24</sup>,2<sup>25</sup>) + ... + 2<sup>17</sup> in [2<sup>30</sup>,2<sup>31</sup>) which sums up to 2<sup>25</sup>-2<sup>17</sup>=33423360 but the sentence holds true). I'm in doubt about including the last sentence about the method to extend the range; it might sound too confusing, though it gives a practical solution. --[[User:Pedro Oval\|Pedro Oval]] 03:53, 30 September 2013 (PDT)

	== Examples ==		== Examples ==

Strife Onizuka at 05:15, 30 September 2013

2013-09-30T05:15:25Z

← Older revision		Revision as of 22:15, 29 September 2013
Line 160:		Line 160:

	:::::The sentence being discussed reads: "''Integers generated with this function cannot contain more than X random bits'' [...]" where X was 23 according to Void and 24 according to you and me. There is an implicit assumption in it, namely the assumption of uniformity of the resulting distribution. Without that assumption, it's indeed certainly possible that you can get more than 24 bits of information on average depending on the underlying implementation. Actually, to be extra-picky, you can most likely get ~24.000000086 bits of near-uniformly distributed integers using llFrand(0x1000001). Perhaps that sentence should just be deleted and the non-uniformity explained in the preceding one that talks about the float range. --[[User:Pedro Oval\|Pedro Oval]] 10:18, 29 September 2013 (PDT)		:::::The sentence being discussed reads: "''Integers generated with this function cannot contain more than X random bits'' [...]" where X was 23 according to Void and 24 according to you and me. There is an implicit assumption in it, namely the assumption of uniformity of the resulting distribution. Without that assumption, it's indeed certainly possible that you can get more than 24 bits of information on average depending on the underlying implementation. Actually, to be extra-picky, you can most likely get ~24.000000086 bits of near-uniformly distributed integers using llFrand(0x1000001). Perhaps that sentence should just be deleted and the non-uniformity explained in the preceding one that talks about the float range. --[[User:Pedro Oval\|Pedro Oval]] 10:18, 29 September 2013 (PDT)

			::::::You want to use 0x1000002 not 0x1000001, 0x1000001 invokes rounding (I think 0x1000000 will be twice as probable in this case to come up than any other number). If it makes things easier I agree, it should be deleted. As to the distribution, to give an even distribution of integers, as the exponent portion of the float increases, the probability for that range doubles. If that is the case, if you pick a really large number llRand(1.7014118346E+38), half the values will be greater than or equal to 8.5070591730E+37, of which there are only 8388608 distinct choices, which leads to a huge likely hood of repeats. Or if the uniform probability stops at 0x1000000 to keep high probability repeats from happening, then you end up with an nonuniform probability. I don't know how to document this nicely without taking the reader quite far down the rabbit hole. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 22:15, 29 September 2013 (PDT)

	== Examples ==		== Examples ==

Pedro Oval: /* Accurate range for holding an integer as a float */

2013-09-29T17:18:36Z

Accurate range for holding an integer as a float

← Older revision		Revision as of 10:18, 29 September 2013
Line 158:		Line 158:

	::::It appears that, at least at one time (I am -- perhaps mistakenly -- going by [http://forge.opensimulator.org/gf/project/opensim-viewer/scmsvn/?action=browse&path=%2Flinden_release%2Flinden%2Findra%2Fllcommon%2Fllrand.cpp&view=markup&revision=100 this source]), this was the case, and that the underlying implementation was to use one of Boost's lagged Fibonacci generators. I can't say that I like the approach, as it does all the arithmetic in doubles and thereby loses bits of information on occasion; the approach suggested by Void Singer, applied to doubles, would be preferable. -- [[User:Natasja Kiranov\|Natasja Kiranov]] 22:56, 27 September 2013 (PDT)		::::It appears that, at least at one time (I am -- perhaps mistakenly -- going by [http://forge.opensimulator.org/gf/project/opensim-viewer/scmsvn/?action=browse&path=%2Flinden_release%2Flinden%2Findra%2Fllcommon%2Fllrand.cpp&view=markup&revision=100 this source]), this was the case, and that the underlying implementation was to use one of Boost's lagged Fibonacci generators. I can't say that I like the approach, as it does all the arithmetic in doubles and thereby loses bits of information on occasion; the approach suggested by Void Singer, applied to doubles, would be preferable. -- [[User:Natasja Kiranov\|Natasja Kiranov]] 22:56, 27 September 2013 (PDT)

			:::::The sentence being discussed reads: "''Integers generated with this function cannot contain more than X random bits'' [...]" where X was 23 according to Void and 24 according to you and me. There is an implicit assumption in it, namely the assumption of uniformity of the resulting distribution. Without that assumption, it's indeed certainly possible that you can get more than 24 bits of information on average depending on the underlying implementation. Actually, to be extra-picky, you can most likely get ~24.000000086 bits of near-uniformly distributed integers using llFrand(0x1000001). Perhaps that sentence should just be deleted and the non-uniformity explained in the preceding one that talks about the float range. --[[User:Pedro Oval\|Pedro Oval]] 10:18, 29 September 2013 (PDT)

	== Examples ==		== Examples ==

← Older revision		Revision as of 03:55, 30 September 2013
Line 166:		Line 166:

	><li> It should be remembered that when passing llFrand an [[integer]] as the {{LSLP\|mag}}, it will be implicitly [[typecast]] to a [[float]].</li><li		><li> It should be remembered that when passing llFrand an [[integer]] as the {{LSLP\|mag}}, it will be implicitly [[typecast]] to a [[float]].</li><li
	> Integers outside the range {{Interval\|lte=+2<sup>24</sup>\|gte=-2<sup>24</sup>\|gteh=-2^24\|lteh=+2^24\|center=integer}} may not be accurately represented (this is an inherent limitation of the float type); for example, outside ~~the~~ range ~~{{Interval\|lte=+2<sup>24</sup>\|gte=-2<sup>24</sup>\|gteh=-2^24\|lteh=+2^24\|center=integer}}~~ no odd integers will appear. For that reason, when converting the resulting float to integer, it is not possible to generate more than 2<sup>25</sup> different integers. Two llFrand calls may be needed to obtain the desired range using a scheme like <code>(integer)llFrand(a)*b+(integer)llFrand(b)</code> with both <code>a</code> and <code>b</code> less than 2<sup>24</sup>, where the product of <code>a</code> and <code>b</code> equals the target number of values.</li></ul		> Integers outside the range {{Interval\|lte=+2<sup>24</sup>\|gte=-2<sup>24</sup>\|gteh=-2^24\|lteh=+2^24\|center=integer}} may not be accurately represented (this is an inherent limitation of the float type); for example, outside that range no odd integers will appear. For that reason, when converting the resulting float to integer, it is not possible to generate more than 2<sup>25</sup> different integers. Two llFrand calls may be needed to obtain the desired range using a scheme like <code>(integer)llFrand(a)*b+(integer)llFrand(b)</code> with both <code>a</code> and <code>b</code> less than 2<sup>24</sup>, where the product of <code>a</code> and <code>b</code> equals the target number of values.</li></ul

	>(the 2<sup>25</sup> comes from 2<sup>24</sup> in [0,2<sup>24</sup>) + 2<sup>23</sup> in [2<sup>24</sup>,2<sup>25</sup>) + ... + 2<sup>17</sup> in [2<sup>30</sup>,2<sup>31</sup>) which sums up to 2<sup>25</sup>-2<sup>17</sup>=33423360 but the sentence holds true). I'm in doubt about including the last sentence about the method to extend the range; it might sound too confusing, though it gives a practical solution. --[[User:Pedro Oval\|Pedro Oval]] 03:53, 30 September 2013 (PDT)		>(the 2<sup>25</sup> comes from 2<sup>24</sup> in [0,2<sup>24</sup>) + 2<sup>23</sup> in [2<sup>24</sup>,2<sup>25</sup>) + ... + 2<sup>17</sup> in [2<sup>30</sup>,2<sup>31</sup>) which sums up to 2<sup>25</sup>-2<sup>17</sup>=33423360 but the sentence holds true). I'm in doubt about including the last sentence about the method to extend the range; it might sound too confusing, though it gives a practical solution. --[[User:Pedro Oval\|Pedro Oval]] 03:53, 30 September 2013 (PDT)