Talk:LlFrand
Known Issues
1.13.3 specifying mag < 0 always returns 0.
- 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:
include <math.h>
float llFrand(float range)
{
return copysign(new_method(fabsf(range)), range);
}
- QED Strife Onizuka 18:45, 31 January 2007 (PST)
The issue has already been corrected in the code, unit tested, through QA, and awaiting the next rolling update. Phoenix Linden 08:47, 2 February 2007 (PST)
More Random
How is this any more random? It just substitutes one predetermined sequence of numbers with another... Iain Maltz
- I agree with you, it's why I added the needs references. -- Strife (talk|contribs) 09:54, 18 February 2012 (PST)
- It is clearly mathematically provable that it is not "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'() does waste time in a loop.
<lsl> integer r_seed; integer f_seed;
//--------------------------// init() { vector v;
v=llGetPos(); r_seed=llGetUnixTime()+((integer)v.x*(integer)v.y); f_seed=r_seed*(integer)(v.x-v.y);
}
//--------------------------// float tanya_rand(float mag) { float f;
r_seed+=2454267026; f_seed+=2909493974; r_seed=(r_seed<<29)|((r_seed>>3)&536870911); f_seed=(f_seed<<27)|((f_seed>>5)&134217727); f=(float)llAbs(r_seed)/(float)llAbs(f_seed); f-=(float)llFloor(f); f*=mag; return f;
}
//--------------------------// string trim(float num,integer n) { string txt;
txt=(string)num; return llGetSubString(txt,0,llSubStringIndex(txt,".")+n);
}
//--------------------------// default {
//--------------------------//
state_entry() {
init();
}
//--------------------------//
touch_start(integer num) {
integer x;
string msg;
float avg;
float f;
msg="\n\nllFrand()::\n";
avg=0.0;
for (x=0; x<100; x++) {
f=llFrand(100.0);
avg+=f;
msg+=trim(f,3)+" ";
}
avg/=100.0;
msg+="\n\nllFrand() average: "+trim(avg,3);
llOwnerSay(msg);
msg="\n\ntanya_rand()::\n";
avg=0.0;
for (x=0; x<100; x++) {
f=tanya_rand(100.0);
avg+=f;
msg+=trim(f,3)+" ";
}
avg/=100.0;
msg+="\n\ntanya_rand() average: "+trim(avg,3);
llOwnerSay(msg);
}
} </lsl> -- Tanya Avon 13:26, 10 September 2012 (PDT)
- ^_^ then I can ax the content. The last version it will appear in is 1169816 -- Strife (talk|contribs) 13:34, 10 September 2012 (PDT)
Unclear note
What does mean "the process" in "The sequence of random numbers are shared across the entire process" in Notes. Should one expect it is SIM, object or script "wide" ?—The preceding unsigned comment was added on 18:38, 22 September 2008 by Scarabeus Kurka
Unreferenced?
it's very odd to see the unreferenced template used in a wiki this way... I get why it was put there but there's no reference for internal working of the simulators so it's really out of place... add the fact that it's trying to link to wikipedia and well... can we either fix the template or just note the contentious point (I agree, there's plenty of question just how random [or not] the native function is)?
-- Void (talk|contribs) 19:14, 11 July 2011 (PDT)
- Well it certainly doesn't make any sense. That's not how entropy works! Adeon Writer 16:14, 17 November 2011 (PST)
- As to the template, the porting of it from wikipedia turned out to be very involved. -- Strife (talk|contribs) 18:10, 17 November 2011 (PST)
Accurate range for holding an integer as a float
I have my doubts about the statement "If the integer is outside the range [-2^23, +2^23] it may not be accurately represented".
In my own tests, a float can accurately hold any integer between +/- 2^24 (-16777216 to +16277216).
Outside of that range, the value will approximate to the next higher or lower even number, then outside of -33554432 to +33554432 it will approximate to the next higher or lower multiple of 4, etc.
Omei Qunhua 10:05, 20 January 2013 (PST)
- You are correct, float format has 24 bits of actual precision float32=[1 sign bit | 8 exponent bits | 23 fractional bits (+ leading 1 assumed)], the original author probably missed the assumed bit in the specification for float32. They also misinterpreted the assumed bit as being random, but the spec says it doesn't include mag as a possible result. llFrand( llPow( 2, 24 ) ) only gives 224-1 as a max value, ie 23 bits. Corrected to use ±224 Max accuracy and 23 bits random values
-- Void (talk|contribs) 14:23, 20 January 2013 (PST)
Examples
I've been looking at the example scripts provided for llFrand. The first 2 almost identical scripts were in a non-compilable state. And do we need both of them? Or was that perhaps more an exercise in how to edit the page to place 2 scripts side by side?
The 3rd example (tossing a coin) seems to be a jumble of 2 ideas, and has extensive comments some of which don't relate to the actual application. And do we really need to know the author and earlier poster?
Do we need the last example at all? The comment under func_footer tells us to use an integer cast, and explains why. So we don't need a rambling example to prove it (IMHO).
The range terminology employed [0.0, mag) is brilliantly compact ... but really only for those with a mathematical background. Even spotting that the opening and closing parentheses differ, takes some doing for the untrained eye. Keep this terminology by all means, but I do think Joe Public needs to have it spelled out without having to click on a minuscule reference icon.
I have spent 3 years helping on various scripting forums in-world, and often hear newcomers complain that they don't understand the Wiki. My extensive scrutiny of Wiki pages over the past 6 weeks has made me realise why that complaint is so common. I have so far fixed (yes, fixed, not tweaked for the sake of it, tho' I've done a bit of that too, LOL) nearly 30 example scripts most of which wouldn't even compile. I think we lose sight of our target audience in our headlong flight towards proving our technical prowess, or our ability to do a quick off-the-cuff edit.
Omei Qunhua 02:30, 21 January 2013 (PST)
I honestly think you've misjudged the majority of editors... most of whom simply happened to notice some detail is wrong or missing and fixed just that detail... their contributions are no less important, in fact I'd guess they are more important since there are many times more of those volunteers than of the more obsessive ones. Do mistakes get made on occasion? of course. but overall the system improves at a much more rapid rate if you train them up from their mistakes rather than beating them down for them. Even old pro's make mistakes, it happens. we've already been down the road of only allowing 'perfect' edits... it ended up with a very empty/outdated wiki because the inexperienced didn't bother any more, and the experienced mostly quit because they were doing it all themselves and unable to keep up. please, ease up a little, forgive and forget, more flies with honey and all that = )
I find it kind of amusing (not sarcastically) that you'd complain about not spelling things out to 'joe public' user, while consistently replacing references to PUBLIC_CHANNEL (which is auto linked to it's value) with 0. if your goal is to make things explicit for those unfamiliar with coding, named constants are much more newbie friendly.
I (and I'm sure quite a few people we'll never meet) appreciate the corrections and additions you have made, but the negative editorializing is a big turn off. It's a missed opportunity to encourage others to participate. even bad edits can be helpful by bringing attention to pages that lack care, and provide a starting point to build from.
-- Void (talk|contribs) 21:52, 22 January 2013 (PST)