[AccessD] miracle required apparently
Paul Hartland
paul.hartland at googlemail.com
Fri Oct 20 21:14:03 CDT 2023
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
> --
> 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