Upper and Lower Bounds for Randomizer

It would be nice to be able to specify an upper and lower bound for a random number.

I know this can be simulated. But a straight call like llFrand(10.0, 3, would be nice.

No offence at all Tcoz... but why?

float randBetween(float min, float max)
{
    return llFrand(max - min) + min;
}

I honestly dont think LL should waste time on something that can be implimented by the users this simply.

Did you have a different reason for it?

Chris.

I stated that I AM AWARE it can be simulated in code. Posting a code sample as a response to a request in Features is inappropriate.

Yes, I have my reasons. Your function also does not provide the numerical odds I require, and once it does actually do what I posted above, would take up considerably more memory as a globally declared function than if this very simple capability were added. *buzzer* thank you play again.

If you must know, this has to do with sliding odds tables and dynamically generated difficulty. It is also generally desirable to incorporate into an API any utility function that would otherwise be boilerplated by users. Considering memory restrictions, this seems a prime candidate.

Why don't you let the Lindens worry about what they consider a waste of time.

I can't see anything in your post that Chris's code can't do. Would you care to elaborate?

::makes funny stick-out tounge kawaii anime face::




Why have globally declarable functions then? I mean, They take up memory, thats a given. But then we can make an argument that *every* global function should be implimented at the back end... that seems like a paradox and a bigger problem to me.



I would, but Im an impatient bastid; I want my llWriteNotecardLine()!!



I dont either, and thats why I posted the snippet, I also asked why wouldnt it function in the way you requested it to in the thread starter post.




Eh? I thought you needed a random number between a minimum and maximum, I posted the mathematicly correct way to do something like that, I think.

If not, could you more clearly state what you needed implimented? I looked at your example in the first post, and I saw a 3 argument function... is there a reason for 3 arguments?

==Chris

EDIT: Oopsie, missed this part:



Um. Whatcha mean? What I interpreted as your request would have been relitavely fufilled by the function I posted. If you needed something different, explain more clearly

I think to me it sounds like Tcoz is asking for something that clamps the value from llFrand(10) to between 3 and 8, where anything under 3 becomes 3, and anything over 8 becomes 8? Thus you have a roughly 30% chance of 3, 10% chance each of 4-7, and 30% chance of 8.

Ah, in that case, it seems like a good idea

Yes. Having the ability to specify a range, and an upper and lower bound within it, adds a great deal of flexibility if you are computing odds and generating difficulty based on them. This would otherwise require a fairly large global function, which would be standard boilerplate in any script that utilizes such technique.

llFrand(10,0,0, FALSE) = Full range.
llFrand(10,3,8, FALSE) = modified range with caps on top and bottom.
llFrand(10,3,8, TRUE) = failure to generate a number in the desired range returns -1.

The application is to enhance the instanced missions structure I have completed for my game. The higher your rank, the harder or easier the odds that certain things will happen or not happen, and thereby the greater or lesser the prize...all computed off an identical scale. Considering the usefulness, a large global function, or linked script, or whatever, seems excessive.

Thus, why I submitted the argument 10 as the range, and 3 to 8 as the bounds. Which the posted code here does not do. Save it for scripts and scripting.

The point of LSL is not to demonstrate coding prowess persay, as LSL is relatively easy to master for anybody with a coding background. The point is to implement things that work and are useful/fun. I have no desire to write global routines to generate random numbers based on a range. It's easy, but a waste of memory. What I do desire is an easy to use, memory efficient, canned operation to do it.

::annoying emote::

Ahh, I get this now. Yeah, that's a good idea. Stacking the odds for certain things would be a good thing.

Even better would be a randomizer function that used a standard deviation to make a bell-curve distribution.

actually you'd do better 'adding dice'... but a pseudo code approach currently would just look like

Bounder(Seed, Min, Max, Cap)
{
dummy=llFrand(10);
if Cap
{
if dummy<Min dummy=Min;
if dummy>Max dummy=Max;
}
else
{
if dummy<Min dummy=-1;
if dummy>Max dummy=-1;
}
}

if you really like that idea i'd almost suggest letting the lindens create a user-addable sort of 'codelet' repository where users could add properly documented and checked quickie functions for pseudo-common operations, mebbe sorted by categories, and add them to the bottom of the accepted function list and copy/paste the full code and comment writeout to a doc file similar to the current LSL one

(think of it like working on a user-created common API for LSL)

I still don't understand the problem.

float newRand(float fRange, float fLower, float fUpper, integer bCap)
{
    float fRet = llFrand(fRange);
    if (fRet < fLower) 
        if(bCap) return -1; else return fLower;
    if (fRet> fUpper) 
        if (bCap) return -1; else return fUpper;
    return fRet;
}

I think this does what you describe in around 14 statements, it's not heavy math, so there wouldn't be much gained by moving it out of LSL in to a system function. What extra functionality is desired?

Edit: Curse you eltee and you're Me-Not-Reading-To-The-End-Of-Your-Post powers!!!

hee ^.^ i am so talented.... too bad i forgot to RETURN the value in any way hehe

/cough

#include or #import

/cough



[note I'm referencing another feature request, not an existing feature]

On the topic though, first I'm not saying this idea would or wouldn't be a good idea. I can see it would have its uses.

For my purposes in games I have always used rand = llFrand(1); if(rand < oddsX) ... etc. That lets me set an exact % chance of something happening but is specific to the application in all cases. Something more generic, and potentially faster I think, would of course be good.

<shrug>

well for games you really *usually* want dice throw style odds... they're statistically provable, and yet satisfactorily 'random' enough in wins/payouts versus losses that people keep playing

You are of course right, I used both methods depending on the game. Several of my games were not 'standard' casino games and dice throw style (I assume you mean 1 in 6, 2 on 20 or some variation there of? or am I missing something?) didn't make sense for them.

yeah dice style simply means you skew the odds not in a linear manner by shifting or cutting values out of a random number throw, but rather you adjust the odds by adding multiple random throws together (which weights the odds towards the middle of the potential range of values, but in a smoother polynomial kinda curve way)

Back to the "feature request" aspect, this is sort of like the request for better sorting in LSL. LSL is a scripting language, not a full-fledged programming language. I think because the richer the language, the more effort has to go into parsing it at runtime. LSL scripts are compiled into bytecode on save, but there is still some runtime interperetation required to call the correct library routine, unlike a compiled C++ program where everything is in there in the binary executable.

Plus, as someone has already pointed out, these things are either trivial to implement (at least to computer programmers) or ubiquitous.

Of course, it never hurts to ask. Just don't get your hopes to high.

think of it like this... a linear skew would be a box that took yer money, threw a float (1.0) and if the throw was >0.95 you win 9x yer money back, a simple game that wouldn be very fun or addictive really because its a flat sort of game that you wouldn't really get any perception of how the odds worked or how much you'd have to play to score


a die throw based random game is alot more engaging if worked properly, say you have a game that you pay $10 and then internally the game throws two 'standard' 6 sided dice

this gives you a range of possible values from 2 to 12, weighted on 7 and with each number further from 7 yer odds get less likely (7 has a one in six chance of being rolled, 12 has a one in 36 chance, and all the ones inbetween gradually change odds as they go)

You win back the difference from 7 of your roll then multiplied by four lets say

so a roll of seven, you loose... a roll of two or twelve and your $10 play returns $20.. a roll of three or eleven and yer roll is $16, then 12 for a ten or a four... 8 for nine or five, 4 for six or eight.. and ya loose it all on a 7

this game would 'feel' much better for a player cause they would get a more palpable sense of win/loss than with a simple 'you win/you loose' single random call


this is actually how real casino machines generally calculate odds, keeping a smooth but increasing curve between the chance of payout and the actual sum returned. So you win little things often enough to keep you playing, and the big money jackpots remain tantalizingly out of reach.

Now its obviously possible to do something like that with one random number, but it gets increasingly time consuming for each possible pertubation of odds you want to include... dice throw based games (yes even slot machines in their electronics 'throw dice') are much simpler to execute and tend to 'feel' more proper for a user

the more dice you add, the more predictable the outcome at the center, and the less likely the outcome at the extremes

sorry about all the detail but i tend to get abit carried away with stuff like this ^.^

heh ama think i should get into the casino game makin business here?

The dice in the NwN API are excellent and foster a lot of game making--a newish game scripter understands "roll a six sided dice" more intuitively than "generate a random float from 0 to 5, cast to int and add 1"--I use them whenever I can instead of random number generation...but for what I'm working on it's not exactly what I'm looking for, as there is no 7 or 11 sided dice...unless you wanted to implement them as well...which gets muddy. I could, however, retool to use dice. Interesting.

llDnDDice(integer num).

well a general way of implementing a dice function has nothing to do with actual rolling, not on computers anyway... a computer can 'roll' a 37 sided die as easily as a 6

heres a pseudo-coded dice roller that shouldn be too hard to add into LSL (i jus don't remember exact loop conventions and such as its been a while since i've programmed in c)
diceRoll(integer numDice, integer numSides, integer skew) as integer
{
integer total=0;
for(integer curr=0;cur<numDice)
{
total+=(integer)llFrand(numSides)+0.49999;
}
return(total+skew);
}


or something to that effect... it'd let you roll any number of any sided dice and return the total (useful called in masse for combined odds, useful called individually for any in-game 'die') the 0.4999 is only needed if its a rounding integer call so that you don't end up rounding to a 0 on a 6 sided die.. if its a truncing integer call ya can jus add +1 and go from 0-5

If you measure output from llFrand(), I believe you will see a normally distributed curve where (μ=0.5, σ=0.5).

Assuming LL doesn't want to do a specialized function for this, and assuming you want to do that anyway: Take llFrand() output and do a slightly modified inverse Z transformation (since Z is μ=0 and σ=1, rather than .5 and .5) to turn this into (pseudo-)random samples approximating a probability distribution curve with any given (μ,σ ).

But then that wouldn't work if you wanted T distributions...

edit: I may be wrong about llFrand() producing normally distributed results. If that is the case, a sinus can be applied to the data to produce a curve.

Actually, I'm not sure that saying that a computer could roll a 37 side dice as easy as a six is accurate. This has to do with how the numbers are distributed on a dice; there is a reason that a six sided dice always has the numbers on the same faces. You would have to take this into account when using your 37 sided dice, which may not offer you the same opposite side/adjacent side structure (i.e. opposite sides of a six sided dice always add to 7), and thus odds, as traditional dice; simply distributing 37 numbers haphazardly would undoubtedly not bear the same results. The same would go for a seven sided dice; you could not find the same distribution of numbers/opposite side addition as a six, or eight (where opposite sides could add to 9), which is why the seven sided "planetary" dice used in some forms of backgammon has been the subject of some debate in the board gaming world. Again from what I've read, there are specific reasons why n-sided dice exist/don't exist.

Or is that all just bunk.

heh its mostly bunk.. the reason the dice have opposing carvings the way they do is there are 7 holes worth of material drilled on every axis so that no one axis is heavier than the others and affects the way they roll...

Was gonna say, the whole point is to be as random as possible. The reason you don't have n-sided dice in RL is just because odd shapes are hard to make truely evenly random, they can tend to favor a side or range of sides and thus skew the odds. When dealing with a computer it *should* be equal chances of all.

However! Someone did mention that the distribution seems to match a particular curve, which isn't very random. Idealy it should be a pretty flat distribution. So a better "dice" may take more work than llFrand(5) + 1. Perhaps some combination of llFrand(1)s ... ew the performance hit of that would suck.