[AccessD] miracle required apparently
Steve Schapel
steve at datamanagementsolutions.biz
Sun Oct 22 22:22:23 CDT 2023
Paul H, Paul W, Stuart, Jack, and anyone else still interested,
I'm just off on a by-way, based on the input of a guy that I met a
couple of days ago at a meeting.
This guy told me I should look into these topics:
- Monte Carlo Tree Search Algorithm
- Evolutionary Method/Algorithms
Another guy at the same meeting said he thought that Indexed Vector Maps
might provide a foothold.
I was unfamiliar with all of these terms, but I've had a bit of an
initial poke around, as time allows. So far it is still not clear to me
how steep the leaning curve would be, or what I would in practice need
to do in order to make effective use of these concepts, and incorporate
them into my application.
But anyway, just wondering whether any of you have any experience with
this corner of the universe?
Thanks.
Regards
Steve
On 22/10/2023 9:24:40 pm, "Paul Hartland via AccessD"
<accessd at databaseadvisors.com> wrote:
>Yes, think its around 12 hours, I am working again today, I have quickly
>taken a copy of your database in case I need it, hopefully will get some
>freetime,if not I wont get time to look at it again until about 31st
>
>Paul
>
>On Sun, 22 Oct 2023, 08:44 Steve Schapel, <steve at datamanagementsolutions.biz>
>wrote:
>
>> 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
>> --
>> 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