[AccessD] miracle required apparently

[Steve Schapel]

Thanks, Stuart.

Mixing them up is definitely not impossible, e.g.
     AE-CF-DG-BH
     CG-AH-BE-DF
     DH-BG-AF-CE
     BF-DE-CH-AG

However, achieving that programmatically, where the number of 
participants, number of activities, and participants per activity are 
variables, is what's doing my head in.

Anyway, for us, the option to avoid the same participants together in 
the same activity is not a hard requirement - though minimising it is 
desirable.

Regards
Steve


On 21/10/2023 8:00:44 pm, "Stuart McLachlan" <stuart at lexacorp.com.pg> 
wrote:

>The trivial solution to that one is to put the same participants together in every slot
>
>i.e
>
>AB-CD-EF-GH
>CD-EF-GH-AB
>EF-GH-AB-CD
>GH-AB-CD-EF
>
>When you don't want AB or CD etc to be paired in more than one event is where it gets
>tricky (impossible?).
>
>
>
>On 21 Oct 2023 at 6:05, Steve Schapel wrote:
>
>>  Thanks for your comment, Bill.
>>
>>  So, given that there will always be enough slots (number of activities
>>  * number of participants per activity) to accommodate all participants
>>  at any given time ... are you of the opinion that (leaving aside for
>>  now how we arrive at the solution), there should always be a solution
>>  possible - such that participants can be assigned to activities over a
>>  number of sessions in such a way that no particpant will do the same
>>  activity more than once?
>>
>>  It seems to me that the answer must be 'yes', but I confess that my
>>  only evidence for this is "gut feel".
>>
>>  Regards
>>  Steve
>>
>>  On 21/10/2023 6:09:05 pm, "Bill Benson" <bensonforums at gmail.com>
>>  wrote:
>>
>>  >I don´t think this problem generalizes. The reason I say this is
>>  >that the parameters are just integers and no constraints except for
>>  >the very arbitrary facts that you have just enough sessions and just
>>  >fee enough activities to be successful- by brute force.
>>  >
>>  >On Sat, Oct 21, 2023 at 12:12 AM Stuart McLachlan
>>  ><stuart at lexacorp.com.pg> wrote:
>>  >
>>  >>  Ah, I was thinking of something like a  sports series where one
>>  >>  player or team played against a different player or team (i.e. two
>>  >>  participants per match) Where the "pigeonholes" are dates or times
>>  >>   and venues. . Now I'm thinking of something like a military
>>  >>  selection board where you can have say 30 candidates  where you
>>  >>  want to put them through 5 different activities so you split them
>>  >>  into 6 teams of  5 for the first activity and then into different
>>  >>  team compositions for the next activity etc  where the objective
>>  >>  is to mix the teams up for each activity. i.e. have the minimum
>>  >>  number of people together in the same team  for different
>>  >>  activities,
>>  >>
>>  >>  Is that more along the lines of what you are doing?
>>  >>
>>  >>
>>  >>  On 21 Oct 2023 at 3:13, Steve Schapel wrote:
>>  >>
>>  >>  > Many thanks for your continued interest, Paul, and for your
>>  >>  > clarifying questions.
>>  >>  >
>>  >>  > The examples I have given are simpler than we would generally
>>  >>  > expect for actual events.  But I figured that getting it working
>>  >>  > for simple configurations hopefully points our noses in the
>>  >>  > right direction for managing more compex scenarios.
>>  >>  >
>>  >>  > Anyway, to answer your questions:
>>  >>  >
>>  >>  > 1.  Yes, basically right.  Where I have used the word
>>  >>  > "participant", in practice this usually refers to a team or
>>  >>  > group rather than to an individual person - but conceptually
>>  >>  > comes down to the same thing. So yes, the same participant
>>  >>  > cannot be in the same time slot or activity more than once. The
>>  >>  > variation from what you have put, is that the number of
>>  >>  > participants per activity can be (and often would be) more than
>>  >>  > 2.  In the example database, the Teams field in the Activities
>>  >>  > table is to show the number of participants for each activity.
>>  >>  >
>>  >>  > 2.  Thankfully this would never happen.  The total number of
>>  >>  > particpant slots available across all activites for a given
>>  >>  > timeslot will always be the same as the total number of
>>  >>  > participants.  Everyone has to have a go - this is fundamental
>>  >>  > to the structure of this type of event, and will be enforced
>>  >>  > within the application.  So if there are 4 activities, each
>>  >>  > allowing the allocation of 2 participants, there will never be
>>  >>  > more than 8 participants registered.
>>  >>  >
>>  >>  > Regards
>>  >>  > Steve
>>  >>  >
>>  >>  >
>>  >>  > On 21/10/2023 3:14:03 pm, "Paul Hartland via AccessD"
>>  >>  > <accessd at databaseadvisors.com> wrote:
>>  >>  >
>>  >>  > >Hi Steve,
>>  >>  > >
>>  >>  > >I have to work overtime this weekemd, but want to try and have
>>  >>  > >a look into this making it as flexible as possible, so am I
>>  >>  > >right in thinking the basics of it are as below
>>  >>  > >
>>  >>  > >1. The time slots, activities and amount of people can vary, a
>>  >>  > >minimum of 1 person per activity, per time slot but no more
>>  >>  > >than 2, the same person cannot be in the same time slot or
>>  >>  > >activity more than once.
>>  >>  > >
>>  >>  > >2. What if you had more people than available slots take a very
>>  >>  > >simple example of 1 time slot, 1 activity and say 4 people,
>>  >>  > >will 2 people be left out ?
>>  >>  > >
>>  >>  > >Paul
>>  >>  > >
>>  >>  > >On Sat, 21 Oct 2023, 01:36 Steve Schapel,
>>  >>  > ><steve at datamanagementsolutions.biz> wrote:
>>  >>  > >
>>  >>  > >>  By the way, I have discovered that my earlier statement,
>>  >>  > >>  that I've got it working correctly in the simple case of
>>  >>  > >>  only one participant per activity, is incorrect.
>>  >>  > >>
>>  >>  > >>  I had to try with a real-life example, being 10 teams, 10
>>  >>  > >>  activites, and only 6 rotation.  And with that scope,
>>  >>  > >>  running the code in the attached database repeatedly, I
>>  >>  > >>  found it only correctly filled all 60 required slots roughly
>>  >>  > >>  20% of the time.
>>  >>  > >>
>>  >>  > >>  Increasing the number of rotations to 7, reduces the success
>>  >>  > >>  rate to the vicinty of 2%.
>>  >>  > >>
>>  >>  > >>  Regards
>>  >>  > >>  Steve
>>  >>  > >>
>>  >>
>>