Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Вот теперь понял. Да, в таком виде легко не получится. Я-то полагал, что элемент расписания самодостаточен, и полностью описывает время и дату. Например, "по вторникам" с... по ... — это фиксированный набор дат, ни от чего не завмсящий. Если элементы могут зависеть от каких-то прочих факторов, которые могут изменяться, то легко не получится — разве только удалить растр по всем таким элементам и создать заново.
Дело не только в том, чтобы удалить и создать. Если бы это была БД, как ты предлагаешь, это всё ещё те же самые delete и insert.
Вопрос — в том, когда и что удалять.

PD>Теперь опять не понимаю. Она наплодила не неизвестно сколько строчек, а столько строчек, сколько дней в интервале, в котором она наплодила. Скажем, с 1 марта по 31 марта — 31 строчку.
Что такое "интервал"? Откуда он взялся?
Вот, допустим, мы хотим создать расписание для того, чтобы поздравлять Павла Дворкина с днём рождения. Сколько нужно строчек сгенерировать? Две? Пять? Десять? Тысячу? Когда именно ты планируешь прекратить их праздновать?
PD>Если нужно добавить новые , скажем, с 1 апреля по 30 апреля, то добавить новое расписание, которое растеризуется в 30 строк.
Что такое "новое"? У тебя нет никакого нового расписания дня рождений. Это всё то же самое расписание.
PD>По-видимому, в тот момент, когда нужно добавить данные на апрель. А кто будет вызывать для исходного расписания и когда ?
Как определить момент, когда "нужно добавить данные на апрель"? Получается, расписание должно быть не пассивной сущностью, которая просто отвечает на вопрос "когда ближайший День Космонавтики", но ещё и чуть ли не активной штукой (потоком), которая раз в X просыпается и добавляет новые данные.

PD>>>Согласен, просто. Вот только это слишком "регулярное событие". Если бы все они были такими или иными, но столь же регулярными, то было бы просто. А если на это "ежедневно в 8.00" наложится еще хотя бы одно такое типа "ежедневно в 18.00" , то все станет менее просто.
S>>Нет, не станет. Потому, что у нас появляется Union(Schedule s1, Schedule s2), у которого GetNextOccurence устроен вот так:
S>>

S>>TimeStamp GetNextOccurence(TimeStamp start, TimeZone zone) 
S>>{
S>>  return Min(s1.GetNextOccurence(start, zone), s2.GetNextOccurence(start, zone));
S>>}
S>>

S>>Имеем O(1) по памяти, O(1) по времени работы. Вроде ж не rocket science, не?

PD>Верно. Только вот GetNextOccurence будет намного сложнее.
Намного сложнее, чем что? Чем функция CreateXXX()? А почему?
PD>И более того, ее придется, возможно, вызывать много раз для одних и тех же данных. А она внутри должна не просто взять минимальный элемент, а по фразе "после дождичка в четверг" найти этот ближайший четверг, в который ожидается дождик, проверить, что после него, а не до, и если не выйдет — брать следующий четверг и для него то же самое. И в следующий раз опять то же. Как тут кешировать — я не очень понимаю.
А зачем и что кэшировать? Давай посмотрим, как будет устроена функция, которая генерирует набор строк для "после дождичка в четверг". И почему в ней генерация второй строки будет драматически дешевле, чем генерация первой.

PD>Будет, будет. С перевычислением их всех на каждом GetNext
Ну так там "перевычисление" стоит O(1). Что всё ещё гораздо лучше, чем O(Log(N)) в "оптимизированном" случае.

PD>Представь себе, что тебе нужно найти некую точку на экране (то есть в дискретном пространстве), через которую проходит некая y=f(x) при x1<x<x2. Ну хотя бы с min(y). Аналитически задача не решается.
Зачем мне представлять себе аллегорию, которая не является удачным аналогом моей задачи? В расписаниях никогда не бывает так, чтобы событие с номером n+1 случилось бы раньше события с номером n.

PD>2. предварительно записать в массив Point все точки (x,y) и искать в нем.
Теперь понятно. Неверное решение следует из неверной аналогии.