[AccessD] miracle required apparently

Sat Oct 21 02:00:44 CDT 2023

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
> >>  > >>
> >>
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com