Can you explain your need for randomness in this scenario?
I would consider simply numbering the seats and assigning the people to seats that match their order of registration, based on a full timestamp in their registration record. That would have some appearance of randomness -- maybe arbitrariness -- to it, but maybe you need more...?
The need for the Randomness is to make sure if 2+ persons come together they are not automatcily sitting next to one another.
So if Bill came in with Jack I need to make sure that Bill and Jack are Not sitting close to one another.
And that The # assigned to either are not assigned to someone that comes in afterward.
Thank you in adv for your help.
How about numbering the seats out of order from their physical location order, and then assign matching based on registration order, per my earlier suggestion. That should reduce the risk of people who register together being seated together.
Keep in mind that the very nature of randomness means: if you do it for a specific reason -- it ceases to be truly random.
But I need to generate a report simular to this:
Table #1 Table#2 Table#3
Bill ID# 13 Ann ID#6 Jack #14
Sam ID#2 Bubba ID#20 Joe ID#9
Not sure how I would acheive that with out some sorta of RND(X) function right?
Also I need to be able to state how many tables to setup, So if I get 150 Donors and they come to the event
I need to know how many tables I need to setup as well as being able to add a few spare seats to each table
incase we have late arrivals.
From what I am thinking of yours I would have to know how many tables I have in adv.
But seeing we do not want to seem like we are empty and start removing tables..
we kinda want to set them up on the fly at the event while they are mengling before the main event.
And now there are even more reasons driving what you want -- each making randomness less of an option.
This raises additional questions:
- How many seats at a table?
- How many is the minimum number of tables, and is there a maximum?
You could then assign numbers to seats out of order but by Row, Track which seat is at which table from a set list you know in advance, and report out by table number without needing to have seats numbered on the report, just for the assignment process.
Or maybe a system where when you decide how many tables (say 100 for this example), the seats are renumbered (say 3 to a table for this example) something like:
- Table 1: seats 1, 101, 201
- Table 2: seats 2, 102, 202
- Table 3: seats 3, 103, 203...
- Table 99: seats 99, 199, 299
- Table 100: seats 100, 200, 300
You could still assign seats based on registration order, but...
True Randomness remains a factor -- you might still end up with people who know each other well sitting next to each other just by chance, even though you worked against it intentionally.
An alternate approach that can work equally well for both small and large numbers of remaining seats is to achieve randomness by shuffling the remaining seats and choosing the first one from the resulting list, rather than picking one at random and hoping it hasn't already been assigned. (This was written in reply to a comment by Bruce, who appears to have removed his post describing the technique I'm responding to. My own suggestion is very similar in effect to Stephen's first idea.)
If you have (or can get) a return-delimited list of seats in a variable, you can shuffle that list with the ValueShuffle custom function (or a script with the same effect). If you'd rather shuffle a found set, you can add an unstored calculation field to your seats — Seat::unstored_sortRandom = Random — and sort on that field. Then you can assign a set of registered attendees by simply matching seat 1 (of the shuffled list) to attendee 1, seat 2 to attendee 2, and so on. (It doesn't do any good to also shuffle the attendee list; that wouldn't do anything to add any more randomness to the assignment.)
I don't share Stephen's concern with any seating assignment constraints making the assignments any less truly random. What constitutes "true" randomness is a deep and entertaining intellectual rabbit hole, and not a settled question. Folks often use the word "random" when they mean something more along the lines of "well dispersed" or "uncertain," neither of which are necessarily qualities of randomness, depending on what definition of randomness you're working with and what day of the week it is.
Practically, there's a balance to be struck between ease of implementation and the consequences of getting it wrong. In your situation, you'd like to prevent attendees who registered together from sitting together. But my guess is that it's not the end of the world if an occassional pair of successive registrants do wind up at the same table. (Depending on how many tables you have and what patterns of folks registering together you get, it may not be possible to completely avoid it anyway.) In that case, the solutions outlined above are enough to make it improbable enough for practical purposes.
If you really need to make sure certain conditions are definitely met, a programmatically lazy (and potentially computationally expensive) method to achieve that might be to do rejection sampling. Do one of the random seat assignments we've described above, then check if that overall assignment pattern violates any conditions you have; if it does, re-randomize the assignments, and keep doing that until you get a satisfactory result. You should build a time cut-off into this, in case your conditions are impossible or very improbable.
You say: "make sure that Bill and Jack are Not sitting close to one another"
As others have already pointed out, randomness cannot, by its very nature, guarantee this—or any other specific outcome for that matter. You need to look to ways of scrambling other than hoping that randomness will do it for you.
I've already stated that I don't agree that every problem presented like this needs a strong guarantee. For practical purposes, naively random seat assignment can be very effective is the requirement is interpreted as less than an absolute guarantee. But another approach that will appear random but gets more to the point of keeping attendees that register together from sitting together as much as possible would be to assign seating based on a low discrepancy sequence, for which this custom function might come in handy.
Can I use the following to generate a random seating printout
Randompk ( start ; stop)
// If zero is random interval the start parameter has to be increased
start = If ( start < 0 ; start - 1 ; start );
// If interval is below zero the stop parameter must be decreased
stop = If ( start < 0 and stop < 0 ; stop - 1 ; stop );
// Calculates random interger value
result = Truncate ( ( Random * ( stop - ( start - 1 ))) + start ; 0 )
// Return result
Us it in a loop script to print out my sheet of available seating.
So If I have 150 RS = Reg Seats and 20 ES = Empty Seats I have a total of 170 Seats and I
random from 1-170 and print then sub 1 during the loop
Is my understanding on how FM will do this correct?