Если мне не изменяет память, то в MySQL prepared statements реализованы коряво, т.е. план запроса не кэшируется, а строится каждый раз заново при выполнении ps, т.ч. толку от таких ps в плане производительности не так уж и много.
10. В течение суток с момента включения в реестр сетевого адреса, позволяющего идентифицировать сайт в сети «Интернет», содержащий информацию, распространение которой в Российской Федерации запрещено, оператор связи, оказывающий услуги по предоставлению доступа к информационно-телекоммуникационной сети «Интернет», обязан ограничить доступ к такому сайту в сети «Интернет».
Похоже, что Елена Мизулина недоговаривает, ст. 15 п. 10:
10. В течение суток с момента включения в реестр сетевого адреса, позволяющего идентифицировать сайт в сети «Интернет», содержащий информацию, распространение которой в Российской Федерации запрещено, оператор связи, оказывающий услуги по предоставлению доступа к информационно-телекоммуникационной сети «Интернет», обязан ограничить доступ к такому сайту в сети «Интернет».
Надежду на это все таки вселяют слова ректора одного из московских ВУЗов. Когда к нему пришел запрос от некого компетентного органа предоставить информацию о национальностях обучающихся в ВУЗе студентов, ректор не растерявшись ответил «У нас одна национальность — математика».
Вообще-то, это был не московский вуз, а челябинский лицей, и не ректор, а директор, и запрос был не о национальностях вообще, а о списке лиц кавказской национальности.
Ну если вы уже используете в своем проекте СУБД, то возможно, что она поддерживает это функционал и от вас не потребуется установка дополнительного инструментария. Из распространенных СУБД, поддерживающих операции с пространственными данными мне известны: PostgresSQL, MySQL, MS SQL, Oracle, Sqlite, MongoDB
На самом деле есть еще одна сложность – это анклавы (Москва лежит внутри Московской области, как и Питер, было решено использовать приоритеты, сначала проверяется лежит ли точка в Москве, а потом уже в Московской области)
Во-первых, ваш алгоритм можно еще улучшить, если по каждому полигону вместо выпуклого многоугольника строить описывающий прямоугольник (bounding box). Таким образом каждый регион в упрощенном виде станет набором из двух координат (противоположный углов прямоугольника), допустим это будет левый нижний угол и правый верхний ((x1, y1) (x2, y2)), таким образом логика поиска попадания точки в такой прямоугольник будет совсем простая. Если координаты точки (xp, yp) то для попадания в прямоугольник необходимо проверить только то, что x1<=xp<=x2 и y1<=yp<=y2. Это должно значительно ускорить поиск. К тому же такой подход позволяет легко построить индекс по таким прямоугольникам, что еще сильнее ускорит поиск;
Во-вторых, многие современные СУБД из коробки (или почти из коробки) поддерживают хранение и поиск пространственных данных. Благодаря нативному коду, построению индексов по пространственным данным и более совершенным алгоритмам эти решения будут на много порядков быстрее вашего. Например, на моей девелоперской машине Postgresql (с Postgis) определяет попадание точки в регион (все регионы имеют в совокупности более миллиона точек) за ~10мс;
В-третьих, даже без баз данных есть хорошо зарекомендовавшие себя готовые решение для различных манипуляций с геометрий. Одно из самых известных это GEOS;
Теперь мы знаем, что функции являются полноправными объектами
Из ваших примеров этого не следует. В своих примерах вы лишь показываете, что в питоне есть функции высшего порядка. Они, например, есть и в php, но, тем не менее, в php функция не является объектами.
Вообще-то, это был не московский вуз, а челябинский лицей, и не ректор, а директор, и запрос был не о национальностях вообще, а о списке лиц кавказской национальности.
Взято отсюда: http://dev.mysql.com/doc/refman/5.1/en/functions-for-testing-spatial-relations-between-geometric-objects.html
Поясните, пожалуйста, в чем возникла сложность?
Во-первых, ваш алгоритм можно еще улучшить, если по каждому полигону вместо выпуклого многоугольника строить описывающий прямоугольник (bounding box). Таким образом каждый регион в упрощенном виде станет набором из двух координат (противоположный углов прямоугольника), допустим это будет левый нижний угол и правый верхний ((x1, y1) (x2, y2)), таким образом логика поиска попадания точки в такой прямоугольник будет совсем простая. Если координаты точки (xp, yp) то для попадания в прямоугольник необходимо проверить только то, что x1<=xp<=x2 и y1<=yp<=y2. Это должно значительно ускорить поиск. К тому же такой подход позволяет легко построить индекс по таким прямоугольникам, что еще сильнее ускорит поиск;
Во-вторых, многие современные СУБД из коробки (или почти из коробки) поддерживают хранение и поиск пространственных данных. Благодаря нативному коду, построению индексов по пространственным данным и более совершенным алгоритмам эти решения будут на много порядков быстрее вашего. Например, на моей девелоперской машине Postgresql (с Postgis) определяет попадание точки в регион (все регионы имеют в совокупности более миллиона точек) за ~10мс;
В-третьих, даже без баз данных есть хорошо зарекомендовавшие себя готовые решение для различных манипуляций с геометрий. Одно из самых известных это GEOS;
Из ваших примеров этого не следует. В своих примерах вы лишь показываете, что в питоне есть функции высшего порядка. Они, например, есть и в php, но, тем не менее, в php функция не является объектами.