[AccessD] miracle required apparently

[Paul Hartland]

Hi Steve,

Never got chance to try anything yesterday, hopefully may get some time
today to have a quick look.

Paul

On Sat, 21 Oct 2023, 21:34 Steve Schapel, <steve at datamanagementsolutions.biz>
wrote:

> Thanks, Paul.
>
> Your illustration didn't come through to me, but I think I've got the
> idea.
>
> Ideally and conceptually, we would have every combination of
> participants for every time/activity slot unique.
>
> However, achieving that in most instances seems like a dreamland wish,
> and is therefore a lower priority. So on that score, I think we are
> shooting for minimising, rather than eliminating, crossover combinations
> wherever possible.
>
> The other specifications, i.e. a participant can't be assigned to more
> than one activity in the same timeslot, and a participant can't be
> assigned to the same activity more than once, are obviously stricter
> requirements.
>
> Regards
> Steve
>
>
> On 21/10/2023 10:10:03 pm, "Paul Hartland via AccessD"
> <accessd at databaseadvisors.com> wrote:
>
> >Hi Steve,
> >
> >At work and just thought of a quick question about this not having the
> same
> >group of participants in any other time/activity slot, your example in the
> >previous email shows just two participants in each time/activity slot,
> what
> >if we have upto four participants in each time\activity slot can any of
> >them be put together again as in the example below or regardless of
> >participants every time slot/activity has to be unique, forgive the very
> >quick excel snapshot, but hopefully will give you an idea of what I am on
> >about would the 09:30 time slot activity A1 be allowed, I am assuming not
> >at the moment while at work 😀
> >
> >[image: image.png]
> >
> >Paul
> >
> >
> >
> >
> >
> >On Sat, 21 Oct 2023 at 08:38, Steve Schapel <
> >steve at datamanagementsolutions.biz> wrote:
> >
> >>  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?
> >>  >>  >>
> >>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>