Bubble sort'ish conflict catcher

[Søren Dyhr]

In order to make such as "Each monday" do I use of multilinekeys instead of inner join records, because it's easier to change to "Each Tuesday" if the key is made by a repeating field exploiting Get ( CalculationRepetitionNumber ) for generating each date in the key instead of Ray's recursively defined

RangeKey( ) from his template http://www.nightwing.com.au/FileMaker/demos7/demo705.html

Now I do not in this case work with the freestored principle as Ray does in his, but instead with an Albert Albert Harum-Alvarez scratchpad to make conflicts show up in either overlapping dates or matches in a returndelimited field of resources. This is a stacked relation two multiline fields matching multiline on the other side ...so it's AND instead of "or" as I just wrote.

It's these returndelimited ID for resources being booked, that I seek a faster algorithm than what it is at present, where I first try the entire set of ID's to get a matching related record or more. If a conflict occures do I a bit silly tryout each of the ID's succesively ...but I do only in the mist remember the "Tower of Hanoi" and "Bubble Sort" which is the way it should be speeded up ...if I just could get my mind straightned slighly...

So the aim is via a clever algorithm to sort the conflicting ID's to one of the ends of the returndelimited and knowing how many allowed ID's can be booked. You could say that the repeating field key is far fetched as principle but all alterations are utterly fast, instead of loops inside loops to make records for each Monday and say friday in a span of two months.

Well it works as it is, but it annoys me to have such a half-witted algorithm!!!

--sd

[Rob 7 Collins]

If this is a "how do I organize all of a group of reucrring events" it's best to define your recurrence options exclusively. "Each Monday" and "First and Third Tuesday of the month" can only conflict, with other events in their (day) categories.

Events like "First weekday of the month", "the 15th and last day of each month" work just as well in an all-out assault on scheduling (like maybe what you're doing), but fall short of any worth-while short cut.

You can schedule those directly as one time events, rather than recurrences, after all the recurrenct events have resolved. Don't worry about the end-user not being able to say "15th and last day of each month" -- those are important, like, people get paid on those days! You can write your main app, build in the GUI to let the user schedule those kinds of recurrences and pass those on to a routine to split those recurrences into individual events.

The only thing that'll sound like a restriction is there is a ceiling to what year you can schedule to ... the "false" recurrences you build need a stopping point. But you could make that one hundred years from now if you wanted and the program would still be uneffected by the processing involved (until you had around one million simultaneous recurring events).

Now, how to process the recurrent events.

With a set of modulii for non-leap year, leap year, and 400th year, you can simply treat each event as a modulus equation in a loop with iterations equal to the day-length of the category of repetition (example; day) of the event. So, a check for 'every monday in the summer' is:

<((daysLeftInYear + 7) - daysInWeek)> % DaysInWeek = monday.

and you iterate against the number of weeks left in the summer. On each iteration you run the modulii for all the already-scheduled events at the day-index you are at in the loop. You can skip all the obvious ones if you store the events in different arrays based on divisions of the calendar, whatever's most effective ... but it's really not worth the processing power to do this on the fly, it's cheaper to do one simple math equation.

[Søren Dyhr]

Thanks for making an educated guess, of what I'm after!

You can schedule those directly as one time events, rather than recurrences, after all the recurrenct events have resolved. Don't worry about the end-user not being able to say "15th and last day of each month" -- those are important, like, people get paid on those days! You can write your main app, build in the GUI to let the user schedule those kinds of recurrences and pass those on to a routine to split those recurrences into individual events.

This is not a calender but a bookingsystem for say rooms in a hotel or nurses deployment to wards. This means that eventhough a nurse would like to hide in the management office does someone have to attend patients ...and wishfull thinking like being in several places at the same time ... or if it's a hotel can't you drag the newly wed out of the bridal suite, to another room becomming availiable on thier honeymoon. The system should be abel to tell straight away "No unfortunatly not... The bridal suite is occupied by another couble - I'm so sorry Sir"

Now stretched a little further: say it's a confrence center with smaller meeting rooms. Then could a request be "Let us have room 4 each first monday in the month, we're having all our Willy Lohman's in for a peptalk" where the system aided response could be "Room 4 is not free - tell you what?? You can have room 7 for the same price - it's availiable"

--sd

[Søren Dyhr]

Oh dear! I didn't get it the first time around ...but suddently started Ender to say the same in this thread:

http://www.fmforums.com/threads/showflat...true#Post150562

Now I need to think it through.......

--sd

[Søren Dyhr]

Oh dear! I didn't get it the first time around ...but suddently started Ender to say the same in this thread:

http://www.fmforums.com/threads/showflat...true#Post150562

Now I need to think it through.......

--sd

[Søren Dyhr]

Oh dear! I didn't get it the first time around ...but suddently started Ender to say the same in this thread:

http://www.fmforums.com/threads/showflat...true#Post150562

Now I need to think it through.......

--sd