[AccessD] miracle required apparently

[Steve Schapel]

Very good, Paul.  Many thanks.

I'm in New Zealand, so you and I obviously have a significant timezone 
difference.  :-)

Regards
Steve

On 22/10/2023 7:09:56 pm, "Paul Hartland via AccessD" 
<accessd at databaseadvisors.com> wrote:

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