– Он называет меня черным уродом, Тренер! Это расизм! – Но ты черный. И ты урод. – Но ведь считать черных уродами - это расизм! – Нет-нет-нет, где ты здесь увидел расизм? Ты ведь черный, мало кто сможет это отрицать, да к тому же урод. Он не считает всех черных уродами, он считает уродом конкретно тебя. "Джентельмены", 2020
Еще до первого полета человека в космос спецы с Байконура запускали на спутниках магнитофонные записи человеческой речи — для проверки голосовой связи между Землей и кораблем. В связи с этим на Западе поднялся шум: дескать, русские отправляли на орбиту пилотов- смертников, чьи голоса перехватывали радиоразведки США, Франции и Великобритании. После этого советские ракетостроители запустили кассету с записью хора Пятницкого...
Это наилучший способ с точки зрения обобщающей способности решающего правила, чему есть строгое теоретическое обоснование (список литературы по ссылке выше написан не зря).
Может быть вам дополнить статью сравнением вашего метода, SVM с разными типами ядер и, например, логистической регрессии? Кросс валидация на ирисах Фишера, например.
Любопытно, спасибо. Кстати, вот здесь https://habr.com/ru/company/hflabs/blog/260601/ есть несколько примеров реально существующих, но необычных адресов. Почти все из них разбираются на сайте правильно, кроме одного - "Бывают адреса без улицы. И даже без дома.", например: Звенигород, Супонево, корп 1.
В пункте "Регистронезависимое сравнение и поиск данных" наверное стоит упомянуть, что регистронезависимость сравнения будет зависеть от выбранного значения параметра Collation конкретной БД. Т.е. при значении Collation, например, SQL_Latin1_General_CP1_CS_AS, сравнение строк будет учитывать регистр (_CS - Case Sensitive), а также аксоны и диакритические знаки ('e' <> 'è', _AS - Accent Sensitive), тогда как при SQL_Latin1_General_CP1_CI_AI - нет.
"… колодец Лотоса, как круг солнца; возле колодца положен один камень, одно долото, две тростинки. Одна тростинка имеет три меры, вторая имеет две меры. Тростинки скрещиваются всегда над поверхностью воды в Колодце Лотоса, и от этой поверхности одна мера до дна. Кто сообщит числа наидлиннейшей прямой, содержащейся в ободе Колодца Лотоса, возьмет обе тростинки, будет жрецом бога Ра." (с) А. Казанцев «Колодец лотоса».
Хотя рассказ Казанцева художественный, в нем описано сразу два решения этой задачи: с уравнением четвертое степени и на основе измерения реального колодца.
Точно вижу один плюс — использование стандартных средств языка, а не написание своего велосипеда. Экономия на выделении памяти под элементы — экономия на спичках. Никто не запрещает перед основной работой сразу создать нужное количество элементов. Кстати, не очень понятно, зачем в условии задачи привязка к количеству запусков в секунду. Очень похоже, что это переформулированная задача об одновременном существовании определенного количества объектов в нескольких потоках. Для таких вещей придуманы семафоры. В частности в шарпе есть модификация SemaphoreSlim, которая позволяет задать сколько именно потоков будут иметь параллельный доступ к ресурсу. И нет, писать код за вас я не стану. На MSDN отличный пример для SemaphoreSlim
За push --force надо бить по рукам, есть большой риск затереть изменения, который другой человек мог параллельно положить в репозиторий. Например, банально забыли повесить пермишны или просто больше одного человека над веткой работают. От того не легче, что затерли коммиты во второстепенном бранче, а не в основном. Конечно из логов можно в таком случае поднять хеш и откатить обратно, но зачем нужны лишние проблемы. Перед вливанием измений в feature-ветку сделать pull --rebase (до кучи autostash в настройках врубить для упрощения процедуры), слив таким образом последние изменения, потом просто push.
Расширенная версия https://habr.com/ru/articles/66320/
https://habr.com/ru/companies/ru_mts/articles/705572/#comment_25012604
– Он называет меня черным уродом, Тренер! Это расизм!
– Но ты черный. И ты урод.
– Но ведь считать черных уродами - это расизм!
– Нет-нет-нет, где ты здесь увидел расизм? Ты ведь черный, мало кто сможет это отрицать, да к тому же урод. Он не считает всех черных уродами, он считает уродом конкретно тебя.
"Джентельмены", 2020
Еще до первого полета человека в космос спецы с Байконура запускали на спутниках магнитофонные записи человеческой речи — для проверки голосовой связи между Землей и кораблем. В связи с этим на Западе поднялся шум: дескать, русские отправляли на орбиту пилотов- смертников, чьи голоса перехватывали радиоразведки США, Франции и
Великобритании. После этого советские ракетостроители запустили кассету с записью хора Пятницкого...
Всё же в русскоязычной литературе обычно используют термин "признак". Соответственно, генерация/отбор признаков.
Правда смысл использования русскоязычной литературы по ML - вопрос открытый.
Это наилучший способ с точки зрения обобщающей способности решающего правила, чему есть строгое теоретическое обоснование (список литературы по ссылке выше написан не зря).
Про количество опорных объектов - не совсем так. Сошлюсь на местную статью https://habr.com/ru/company/ods/blog/484148/ с прекрасными картинками на эту тему.
Может быть вам дополнить статью сравнением вашего метода, SVM с разными типами ядер и, например, логистической регрессии? Кросс валидация на ирисах Фишера, например.
Чем не устроил классический метод опорных векторов (http://www.ccas.ru/voron/download/SVM.pdf)?
Для описания действия есть специальный паттерн.
concat_ws завезли в MS SQL 2017 (https://docs.microsoft.com/en-us/sql/t-sql/functions/concat-ws-transact-sql).
Любопытно, спасибо. Кстати, вот здесь https://habr.com/ru/company/hflabs/blog/260601/ есть несколько примеров реально существующих, но необычных адресов. Почти все из них разбираются на сайте правильно, кроме одного - "Бывают адреса без улицы. И даже без дома.", например: Звенигород, Супонево, корп 1.
В пункте "Регистронезависимое сравнение и поиск данных" наверное стоит упомянуть, что регистронезависимость сравнения будет зависеть от выбранного значения параметра Collation конкретной БД. Т.е. при значении Collation, например, SQL_Latin1_General_CP1_CS_AS, сравнение строк будет учитывать регистр (_CS - Case Sensitive), а также аксоны и диакритические знаки ('e' <> 'è', _AS - Accent Sensitive), тогда как при SQL_Latin1_General_CP1_CI_AI - нет.
Кстати, есть ли нечто подобное в PostgreSQL?
Emacs + AUCTeX. Основная проблема - настроить это все)
Хотя рассказ Казанцева художественный, в нем описано сразу два решения этой задачи: с уравнением четвертое степени и на основе измерения реального колодца.