[AccessD] miracle required apparently

[Steve Schapel]

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
>>  > >>
>>