valenok - нет, динамическое программирование состоит как раз в том, чтобы построить оптимальное решение, а не перебирать все возможные, в этом его изюминка и скорость работы. Если интересно, то я могу привести полное решение задачи обхода матрицы с набором минимального/максимального числа очков методом динамического программирования.
предлагаю решить методом обобщения:
1.Завести матрицу размерности NxM (по размерностям лабиринта)
2.Заполнять ее значениями: 1 для свободных клеток и X для занятых, где X равно числу свободных клеток
3.Находить путь из (A) в (B) так, чтобы сумма, накапливаемая во время прохода из значений в клетках была минимальна.
4. Задача '3.' решается общеизвестным методом динамического программирования.
5. В силу постановки '3.' будет найден не только какой-то путь из (A)в (B), но и, более того, кратчайший путь.
6. Если полученная сумма значений для найденного пути больше, чем X, то это значит, что найденный путь пролегает через занятую клетку и таким образом задача не имеет решения.
вот кстати решение задачки с обменом переменных для любых типов данных.. я потратил на ее решение ровно столько времени, сколько мне потребовалось вспомнить, как в PHP вычисляется XOR для двоичного представления переменных.. (около 3 мин.)
Умышленно не приводил переменные к типу строк (чтобы работало для случая разнотиповых переменных), чтобы простота была виднее..
валенок - замечу, что ваш метод решения здесь не подойдет, так как вы неявно используете третью переменную - массив, возвращаемый функцией ... хотя, если не считать структуру из начальных переменных отдельной переменной, ваш метод корректен.
за 1500 брать на себя что то. Собственно, а почему именно Вы должны поддержкой заниматься.. не понятно.. валенок прав, за такие деньги что-то делать невыгодно самому себе.
Потому что если раньше поддержка делалась бесплатно, то никто и не мог потребовать её выполнения, стало быть при отстутствии времени и/или желания можно было ничего не делать. А так получается, что всегда нужно будет этим заниматься, что, мне так кажется, при такой оплате экономически невыгодно.
а что значит неправильно установлены?
проиндексированы те поля, по которым наиболее часто идут выборки.
При этом есть составные индексы. Если бы все шло так как в мануале сказано, то имеющиеся индексы вполне логичны.
Делал и так, как в мануале значится и по-всякому другому так же .. это уже совсем непонятно.
Видимо, я плохо разбираюсь в индексах - почему так происходит неясно совсем.
Сразу скажу: таблица довольно большая (более 131 миллиона строк).
1)есть таблица. в ней много полей.
2)есть индексы: первый по полю record_date и второй - по полям user_id, record_type, record_date, reason. Первый с именем byDate, второй с именем byUserRecordDate.
3)пишу запрос на выборку из этой таблицы. в where условие: where record_date between .. and reason = ..
делаю explain этому запросу. и получаю:
possible keys: byDate (то есть тот, который по одной колонке)
used keys: byUserRecordDate (тот который по 4-м колонкам) .. !!!!
4)И при этом если я пишу USE INDEX byDate (то есть в приказном порядке заставляю использовать правильный индекс) он пишет
used keys: NULL !!!
5)в мануале черным по белому сказано, что многоколоночные - индексы он будет использовать ТОЛЬКО если колонки в WHERE есть точное СЛЕВА подмножество колонок, по которым сделан индекс.
То есть он в принципе не может использовать этот индекс, и тем не менее использует. хотя должен использовать тот, который одиночный
____
Вот я и не понимаю в чем тут дело??
по моему, переопределять все таки можно, правда не так как это написано тут, но это относится к полиморфизму классов а совсем не к такому случаю.
то, что тут написано - это определение двух функций с одним именем в одной области видимости и, уж извините, но имхо это бред ((*
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 8901
