[AccessD] miracle required apparently
Stuart McLachlan
stuart at lexacorp.com.pg
Fri Oct 20 23:12:30 CDT 2023
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
> >>
> >>
> >> On 19/10/2023 8:57:43 am, "Steve Schapel"
> >> <steve at datamanagementsolutions.biz> wrote:
> >>
> >> >I have put together a bare-bones example database, to show one
> >> >approach I
> >> have taken to this problem. I have tried to keep it simple, hope
> >> it makes sense.
> >> >
> >> >I tried attaching it to a post to the list, not realising that it
> >> >would
> >> breach the post size limit.
> >> >
> >> >So, if you're interested, please feel free to download it from
> >>https://sportsrunner.net/files/CarnivalSchedule.zip
> >> >
> >> >Thanks a lot.
> >> >
> >> >Regards
> >> >Steve
> >> >
> >> >
> >> >
> >> >On 18/10/2023 2:13:47 pm, "Steve Schapel" <
> >>steve at datamanagementsolutions.biz> wrote:
> >> >
> >> >>Thanks again, Stuart.
> >> >>
> >> >>As I said to Paul, I will upload a simple sample database to
> >> >>illustrate
> >> the basics of what I've been trying. Maybe I'll get that done
> >> today.
> >> >>
> >> >>It's awesome getting this kind help and support from you and
> >> >>other
> >> members of the group. From the standpoint of my organisation, it
> >> is important to get it working if possible, so it would mean a lot
> >> to me if we can crack it.
> >> >>
> >> >>Regards
> >> >>Steve
> >> >>
> >> >>
> >> >>On 18/10/2023 1:38:30 pm, "Stuart McLachlan"
> >> >><stuart at lexacorp.com.pg>
> >> wrote:
> >> >>
> >> >>>I had a bit of a play with it last night, but avoiding the same
> >> >>>two
> >> people competing against
> >> >>>each other more than once is proving very tricking. I'll have
> >> >>>another
> >> go later
> >> >>>(incluindg some demo code without the limitation)
> >> >>>
> >> >>>On 17 Oct 2023 at 18:50, Steve Schapel wrote:
> >> >>>
> >> >>>> So, Stuart, are you suggesting the "very simple solution"
> >> >>>> being to abandon the project? Or do you think it's
> >> >>>> achievable?
> >> >>>>
> >> >>>> Thanks again.
> >> >>>>
> >> >>>> Regards
> >> >>>> Steve
> >> >>>>
> >> >>>> On 17/10/2023 5:46:41 pm, "Steve Schapel"
> >> >>>> <steve at datamanagementsolutions.biz> wrote:
> >> >>>>
> >> >>>> >Thank you very much, Stuart.
> >> >>>> >
> >> >>>> >Your astute observation was indeed initially a stipulation
> >> >>>> >of the project. But I have already abandoned the dream of
> >> >>>> >having that happen, and accepting the fact that at times
> >> >>>> >there will be "the luck of the draw" where the same two
> >> >>>> >teams are paired up.
> >> >>>> >
> >> >>>> >I can't even get it to work without shooting for that
> >> >>>> >limitation!
> >> >>>> >
> >> >>>> >Regards
> >> >>>> >Steve
> >> >>>> >
> >> >>>> >On 17/10/2023 3:41:48 pm, "Stuart McLachlan" <
> >>stuart at lexacorp.com.pg>
> >> >>>> >wrote:
> >> >>>> >
> >> >>>> >>There is a very simple solution to your stated problem,
> >> >>>> >>but I don't think that is what you want. I'll leave
> >> >>>> >>you to work it out.
> >> >>>> >>
> >> >>>> >>But I assume there is another unstated limitation:
> >> >>>> >>No two participants can participate together in more than
> >> >>>> >>one event.
> >> >>>> >>
> >> >>>> >>Yes?
> >> >>>> >>
> >> >>>> >>
> >> >>>> >>
> >> >>>> >>
> >> >>>> >>On 17 Oct 2023 at 1:22, Steve Schapel wrote:
> >> >>>> >>
> >> >>>> >>> Hi all
> >> >>>> >>>
> >> >>>> >>> I'm trying to do something that I initially thought
> >> >>>> >>> would be reasonably easy. But alas, so far success has
> >> >>>> >>> eluded me. Any insights accepted with much gratitude!
> >> >>>> >>>
> >> >>>> >>> The goal: Assign a number of Participants to a number
> >> >>>> >>> of Activities over a number of Sessions.
> >> >>>> >>>
> >> >>>> >>> Very simple example:
> >> >>>> >>> 4 Sessions
> >> >>>> >>> 4 Activities
> >> >>>> >>> 8 Participants (therefore 2 per Activity)
> >> >>>> >>>
> >> >>>> >>> To illustrate:
> >> >>>> >>> Let's say the sessions are 9am, 10am, 11am, 12pm.
> >> >>>> >>> Let's sat the activities are chess, tai chi, bowls,
> >> >>>> >>> diving Let's say the participants are A, B, C, D, E, F,
> >> >>>> >>> G, H
> >> >>>> >>>
> >> >>>> >>> The stipulation is that each participant should do each
> >> >>>> >>> activity one time.
> >> >>>> >>>
> >> >>>> >>> By trial and error brute force, I know that there is at
> >> >>>> >>> least
> >> one
> >> >>>> >>> solution, namely:
> >> >>>> >>>
> >> >>>> >>> chess tai chi bowls
> >> >>>> >>> diving
> >> >>>> >>> 9am A & E C & F D & G
> >> >>>> >>> B & H
> >> >>>> >>> 10am C & G A & H B & E D
> >> >>>> >>> & F 11am D & H B & G A & F
> >> >>>> >>> C & E 12pm B & F D & E C & H
> >> >>>> >>> A & G
> >> >>>> >>>
> >> >>>> >>> HOWEVER, I have tried multiple angles of looping
> >> >>>> >>> through nested (and sometimes randomised) recordsets
> >> >>>> >>> based on the core data elements (sessions, activities,
> >> >>>> >>> and participants), to write the assignments to the
> >> >>>> >>> available slots in a schedule table, and to
> >> my
> >> >>>> >>> shock (and horror) we always reach the point in the
> >> >>>> >>> procedure where it gets stuck, due to trying to assign
> >> >>>> >>> a participant to
> >> two
> >> >>>> >>> activities in the same session, but with no valid
> >> >>>> >>> alternative slot available.
> >> >>>> >>>
> >> >>>> >>> There is no problem if the model calls for the super
> >> >>>> >>> simple option of only one participant for each
> >> >>>> >>> activity. But
> >> otherwise,
> >> >>>> >>> no dice, so far.
> >> >>>> >>>
> >> >>>> >>> There MUST be a way to make this work? Surely?
> >> >>>> >>>
> >> >>>> >>> Thanks a lot.
> >> >>>> >>>
> >> >>>> >>> Regards
> >> >>>> >>> Steve
> >> >>>> >>> --
> >>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
More information about the AccessD
mailing list