Ну да. Так что для Бейсика (как и для ассемблера) основная парадигма – императивная, а написание на нём какой-то функциональщины, да и вообще декларативщины, потребует вначале создать инфраструктуру для неё, да и вообще окажется неэффективным (функциональщина на языках, не поддерживающих автоматическое управление памятью – боль: невозможно даже толком замыкание создать, а как без этого вернуть из функции функцию?)
Когда человек представляет всю цепочку ORM -> запрос к базе -> обработка запроса (индексы, циклы) хотя бы в первом приближении (до способности увидеть, что тут вылезает 30*500*20 операций на юзера на ровном месте, а в идеале хочется 30+500+20) – это здорово помогает при написании на любом из уровней.
Программисты, привыкшие писать код, а не тяп-ляп запрос к бд, плачут... Всё-таки эта история, где за оптимизацию запроса отвечает движок БД, здорово ударила по этому направлению, превратив некоторые вещи в магию.
Впору придумывать расширение для SQL – assert для временнОй сложности (в данном случае – O(n1)+O(n2)+O(n3)+O(nr*log(nr)), где n1, n2, n3 – количество строк в исходных таблицах, а nr – в результате).
Ну тут как раз понятно: потому что синус и косинус. Правда, направление вылезает ещё до формулы Эйлера, когда записываешь комплексное число в тригонометрической форме (и видишь, как удобно работает умножение), а формула Эйлера просто позволяет удобно свести синус и косинус к одной функции и значительно упростить формулы.
Для функциональных языков оптимизация хвостовой рекурсии в цикл – мастхэв (и гуру больно бьют тех, кто использует просто рекурсию там, где можно хвостовую), для C++ – сложно, для Питона, если я правильно помню, Гвидо от неё сознательно отказался по каким-то своим причинам.
Но суть не в этом. Суть ФП – что у функции есть вход (аргументы), есть выход (результат) – и она не меняет ничего во внешнем мире. В Бейсике же подпрограммы только и могут, что что-то менять. Полная противоположность (хотя при некотором опыте можно из одного сделать другое, причём в обе стороны).
Второй случай можно реализовать без хранения пд у себя – например, анонимизированной привязкой к госуслугам. Грубо говоря, госуслуги выдают токен для данного сервиса, по которому нельзя получить никаких данных – лишь проверить, что входит тот же человек. (не знаю, можно ли на гу сейчас выставить такой набор пермишнов для сервиса или имя юзера сервису всегда доступно, но реализовать можно).
Ага, и те же 40 лет назад в бейсиковских подпрограммах не было способа вернуть результат :-). Всё, что можно – это изменять (мутировать) состояние. Даже стека для локальных переменных не было – только для адресов возврата.
Ну так и расклад тот же, что с ООП: если ты его освоил и разумно используешь – ты можешь писать программы проще и надёжнее. А если поверил, что это silver bullet и стал пихать во все дыры – твой код может превратиться в тыкву.
Ну, когда я анализом изображений занимался – мы на C++ писали, тут на чистом питоне странно бы было, из него принято сразу вызывать "жирные" операции, работающие с битмапом, а не пикселем :-)
Навскидку – например, прилипание. У нас есть карта расстояний до камней (ну или для простоты рассмотрения – до центров камней). Берём точку, куда юзер пытается положить камень, и идём по градиенту этого расстояния до получения значения 2R. Есть, правда, ловушки – к примеру, если у нас стоит три камня так, что между ними не влезет четвёртый, а юзер пытается туда засунуть – окажемся в локальном максимуме и не сможем поставить, но это проблема юзера.
Захват – надо подумать, возможно, всё не так просто. Я исходил из того, что нам понадобится отдельно карта расстояний от чёрных и белых камней, и будем для каждого белого в группе проверять расстояние до чёрных. Но, похоже, всё сложнее, надо подумать.
Да, карты достаточно пересчитывать раз в ход (для уже установленных камней), а не на каждом шаге.
FMM – загуглите и почитайте, он интересный. Вкратце идея – мы метим на карте какие-то точки и за время O(N*log(N)) (где N – площадь карты) считаем расстояния по кратчайшему пути от меток до всех точек карты. При этом меток может быть сколь угодно много, а на карте могут быть границы, которые нельзя перескать, и области с разной скоростью движения. Да ещё расстояния считаются довольно точно евклидовы, а не по движению в 4 или 8 возможных направлениях (если пустить волну из одной точки – получится круг, а не квадрат или восьмиугольник). Тут пригодится для построения карт – но, возможно, и не пригодится, если камни добавлять по одному – обновление карты занимает O(N) – причём, может быть, его можно вообще сделать на халяву на GPU наложением заранее созданной текстуры на изображение.
Если делать на битмапе – то и прилипание, и правила убийства должны довольно легко получиться через карту расстояний от края (можно её строить по тупому, считая на каждый пиксель расстояние от края и от всех камней и адаптируя при добавлении нового камня, а есть красивый алгоритм типа поиска в ширину [с бинарной кучей], считающий эти расстояния "диффузией" [UPD: Fast Marching Method]). Если векторно – сложнее, конечно.
А про OpenAI Gym – imho отличная идея.
Ну или ещё вариант – подумать, как перевести это в головоломку – казуальную игру на смартфоне. Потому что как игру для двух человек без комьюнити не раскрутите, полагаю, а вот игра с ИИ или в виде головоломки с потенциальным выходом на турнир среди живых – уже есть шанс.
А ИИ для игры-то реализовали? Саму механику-то сделать не очень сложно, если ограничиться определённой точностью – довольно легко на битмапе всё считать (вокруг камней и краёв доски "отрисовать" зоны влияния, ну и приближённая диаграмма Вороного тоже несложно строится), а вот классическое дерево решений, как в шахматах, уже не получается, нужны другие подходы, это интересно. А вы в статье про эту самую интересную часть – ни слова.
Думаю, что зарегалось-то много реальных людей (хотя бы из любопытства, плюс на iOS поставить его, пока из App Store не удалили). Вот пользоваться – другое дело.
Вам бы вначале, как положено в научной работе, изучить то, что сделано до вас. Тогда бы вы сразу знали и про пространство-время Минковского, и про представление поворотов на плоскости, и про плоское течение несжимаемой жидкости, и ещё про кучу применений, где у мнимой единицы изначально есть физический смысл, и могли свои рассуждения привязывать к сделанному до вас.
Ну да. Так что для Бейсика (как и для ассемблера) основная парадигма – императивная, а написание на нём какой-то функциональщины, да и вообще декларативщины, потребует вначале создать инфраструктуру для неё, да и вообще окажется неэффективным (функциональщина на языках, не поддерживающих автоматическое управление памятью – боль: невозможно даже толком замыкание создать, а как без этого вернуть из функции функцию?)
Человек, который пишет bash-скрипты такого размера, что их содержимое имеет смысл скрывать, должен страдать.
Когда человек представляет всю цепочку ORM -> запрос к базе -> обработка запроса (индексы, циклы) хотя бы в первом приближении (до способности увидеть, что тут вылезает 30*500*20 операций на юзера на ровном месте, а в идеале хочется 30+500+20) – это здорово помогает при написании на любом из уровней.
Программисты, привыкшие писать код, а не тяп-ляп запрос к бд, плачут... Всё-таки эта история, где за оптимизацию запроса отвечает движок БД, здорово ударила по этому направлению, превратив некоторые вещи в магию.
Впору придумывать расширение для SQL – assert для временнОй сложности (в данном случае – O(n1)+O(n2)+O(n3)+O(nr*log(nr)), где n1, n2, n3 – количество строк в исходных таблицах, а nr – в результате).
Ну тут как раз понятно: потому что синус и косинус. Правда, направление вылезает ещё до формулы Эйлера, когда записываешь комплексное число в тригонометрической форме (и видишь, как удобно работает умножение), а формула Эйлера просто позволяет удобно свести синус и косинус к одной функции и значительно упростить формулы.
Для функциональных языков оптимизация хвостовой рекурсии в цикл – мастхэв (и гуру больно бьют тех, кто использует просто рекурсию там, где можно хвостовую), для C++ – сложно, для Питона, если я правильно помню, Гвидо от неё сознательно отказался по каким-то своим причинам.
В большинстве ассемблеров был push/pop.
Но суть не в этом. Суть ФП – что у функции есть вход (аргументы), есть выход (результат) – и она не меняет ничего во внешнем мире. В Бейсике же подпрограммы только и могут, что что-то менять. Полная противоположность (хотя при некотором опыте можно из одного сделать другое, причём в обе стороны).
Ну так и надо набивать. Получил подсказку, прошёл трудное место (где чего-то не знал или сообразить с ходу не мог) – двигайся дальше.
Посмотрите по реестру, не пытайтесь вычислить логически.
Второй случай можно реализовать без хранения пд у себя – например, анонимизированной привязкой к госуслугам. Грубо говоря, госуслуги выдают токен для данного сервиса, по которому нельзя получить никаких данных – лишь проверить, что входит тот же человек. (не знаю, можно ли на гу сейчас выставить такой набор пермишнов для сервиса или имя юзера сервису всегда доступно, но реализовать можно).
"Отечественость" определяется не авторством, а включением в реестр.
Ага, и те же 40 лет назад в бейсиковских подпрограммах не было способа вернуть результат :-). Всё, что можно – это изменять (мутировать) состояние. Даже стека для локальных переменных не было – только для адресов возврата.
А если написан через хвостовую рекурсию, но компилятор её оптимизировал в цикл – это всё равно неправославно?
Ну так и расклад тот же, что с ООП: если ты его освоил и разумно используешь – ты можешь писать программы проще и надёжнее. А если поверил, что это silver bullet и стал пихать во все дыры – твой код может превратиться в тыкву.
Первый пример показателен тем, что в нём первая императивная реализация читается легче, чем "улучшенная" функциональная.
Ну, когда я анализом изображений занимался – мы на C++ писали, тут на чистом питоне странно бы было, из него принято сразу вызывать "жирные" операции, работающие с битмапом, а не пикселем :-)
Навскидку – например, прилипание. У нас есть карта расстояний до камней (ну или для простоты рассмотрения – до центров камней). Берём точку, куда юзер пытается положить камень, и идём по градиенту этого расстояния до получения значения 2R. Есть, правда, ловушки – к примеру, если у нас стоит три камня так, что между ними не влезет четвёртый, а юзер пытается туда засунуть – окажемся в локальном максимуме и не сможем поставить, но это проблема юзера.
Захват – надо подумать, возможно, всё не так просто. Я исходил из того, что нам понадобится отдельно карта расстояний от чёрных и белых камней, и будем для каждого белого в группе проверять расстояние до чёрных. Но, похоже, всё сложнее, надо подумать.
Да, карты достаточно пересчитывать раз в ход (для уже установленных камней), а не на каждом шаге.
FMM – загуглите и почитайте, он интересный. Вкратце идея – мы метим на карте какие-то точки и за время O(N*log(N)) (где N – площадь карты) считаем расстояния по кратчайшему пути от меток до всех точек карты. При этом меток может быть сколь угодно много, а на карте могут быть границы, которые нельзя перескать, и области с разной скоростью движения. Да ещё расстояния считаются довольно точно евклидовы, а не по движению в 4 или 8 возможных направлениях (если пустить волну из одной точки – получится круг, а не квадрат или восьмиугольник). Тут пригодится для построения карт – но, возможно, и не пригодится, если камни добавлять по одному – обновление карты занимает O(N) – причём, может быть, его можно вообще сделать на халяву на GPU наложением заранее созданной текстуры на изображение.
Если делать на битмапе – то и прилипание, и правила убийства должны довольно легко получиться через карту расстояний от края (можно её строить по тупому, считая на каждый пиксель расстояние от края и от всех камней и адаптируя при добавлении нового камня, а есть красивый алгоритм типа поиска в ширину [с бинарной кучей], считающий эти расстояния "диффузией" [UPD: Fast Marching Method]). Если векторно – сложнее, конечно.
А про OpenAI Gym – imho отличная идея.
Ну или ещё вариант – подумать, как перевести это в головоломку – казуальную игру на смартфоне. Потому что как игру для двух человек без комьюнити не раскрутите, полагаю, а вот игра с ИИ или в виде головоломки с потенциальным выходом на турнир среди живых – уже есть шанс.
А ИИ для игры-то реализовали? Саму механику-то сделать не очень сложно, если ограничиться определённой точностью – довольно легко на битмапе всё считать (вокруг камней и краёв доски "отрисовать" зоны влияния, ну и приближённая диаграмма Вороного тоже несложно строится), а вот классическое дерево решений, как в шахматах, уже не получается, нужны другие подходы, это интересно. А вы в статье про эту самую интересную часть – ни слова.
Думаю, что зарегалось-то много реальных людей (хотя бы из любопытства, плюс на iOS поставить его, пока из App Store не удалили). Вот пользоваться – другое дело.
Вам бы вначале, как положено в научной работе, изучить то, что сделано до вас. Тогда бы вы сразу знали и про пространство-время Минковского, и про представление поворотов на плоскости, и про плоское течение несжимаемой жидкости, и ещё про кучу применений, где у мнимой единицы изначально есть физический смысл, и могли свои рассуждения привязывать к сделанному до вас.