Ещё чаще ошибки никуда не подталкивают, а являются просто ошибками. И если бы статья была о революционных результатах, полученных из найденной проблемы, её сенсационный тон был бы оправдан.
А так, имеем пустозвонство из совершенно рядового события.
1. Это далеко не все разработанные типы НС, а лишь малая их часть. Всё равно что одну исследовать.
2. Все они обучались методом глубокого обучения, которому и посвящена исходная статья.
То есть вся исходная статья посвящена особенностям работы конкретного метода обучения на паре конкретных архитектур.
Исследователи молодцы, что нашли существенный баг в этом популярном и перспективном методе, но их результаты никак не могут претендовать на революционность или философскую ценность.
>есть ли вообще какие-то математические выкладки по нейронным сетям, хоть что-то… доказано?
Есть хорошие и подробные математические выкладки и по ним пишут толстые книги.
К сожалению люди, которые этим занимаются серьёзно, редко пишут научно-популярные статьи и интернеты застраны описанием «магических» нейронных сетей без какого-либо объяснения принципов их работы.
По-моему полезной информации в статье чуть больше нуля и тем более никаких философских вопросов она ставить не может в принципе.
Изучался один тип сетей из многих и результат применим только к нему.
>если у вас есть фотография кота, существует набор небольших изменений, которые могут сделать так, что сеть будет распознавать кота как собаку
Бредовое утверждение, хотя бы потому, что сеть, распознающая котов о собаках ничего не знает. Она может распознать кота как «не кота», не более.
Даже если сеть обучена распознавать и котов и собак, из эффекта описанного в статье не следует, что можно подобрать пример, который будет воспринимать кота собакой, а не «не котом».
Хорошая статья для работы со среднестатистическим джуниором. Осталось понять где найти настолько среднего джуниора.
Вспомнил как начинал я и мои однокурсники, так вот, по данным рекомендациям нас бы всех поувольняли. Хорошо, что наши работодатели подходили к вопросу более индивидуально.
> Одним из главных отличий и преимуществ игры является уникальный игровой мир, в котором объединены достижения высоких технологий и привычные всем элементы фэнтези.
Иными словами, более серьёзных отличий от существующих продуктов нет?
К слову, смесь фэнтези и технологий уже давно не является уникальным явлением в геймдеве.
Буду рад увидеть здесь комментарий человека, который не понимает что написано в этих строках (и знает английский):
> result = self.client.get('/products/123/')
> self.assert('title' in result.body)
Человек, который работал в Excel, писал макросы для Word, настраивал что-нибудь в Jira, или ещё чего-нибудь похожее делал хоть раз в своей жизни, поймёт что тут написано. Это не говоря уже о том, что не ясно зачем ПМ-у вообще лезть в эти тесты.
Если же по какой-то неимоверной случайности этот ПМ вообще не сталкивался с программированием, то вот хороший повод узнать таки, чем он управляет.
>«Новый ЯП» это некоторый полу-формальный формат записи спецификаций, не более.
И тем не менее ему надо учить всех людей, которые будут с ним взаимодействовать и большинство из которых точно может обойтись без него. Зачем тогда его вводить? Этот полу-формальный формат — отличный пример лишней сущности.
>Такая «спецификация-тест» для человека со стороны лучше, чем простой тест и никакой спецификации.
Простой тест и есть спецификация, причём максимально конкретная. Более того, простой тест более гибок, чем правила на специфичном для проекта ЯП, описывающем только часть (причём меньшую) предметной области.
Даже писать простые тесты с подробными комментариями на нормальном языке проще, чем поддерживать отдельный ЯП для описания этих тестов на «почти» нормальном языке.
Глобальная цель у тестирования одна — убедиться что поведение проекта соответствует спецификации (как бы она ни была выражена).
Использование BDD предполагает:
1. Введение в проект нового ЯП со своим синтаксисом и семантикой (а значит обучение им всех специалистов, работающих с тестами).
2. Дублирование части функционала, для возможности его использования в BDD.
3. Поддержка дублированного функционала (как только будет надо сделать какое-то новое действие, его надо замапить в правила).
Человек, который пишет тесты (а значит явно описывает требования спецификации ПО), должен быть в состоянии писать простейшие алгоритмы. Если он не может этого делать, то его нельзя допускать до этой работы. А если он может писать алгоритмы, то разницы между:
— user.create(name='test_name')
— «create user with name 'test_name'»
никакой нет, за тем исключением, что программистам будет проще разобрать 1-ый вариант, так как они его по 20 раз на дню видят.
Наворачивание ещё одного уровня абстракции (которым является BDD) над тестами увеличит сложность поддержки тестов.
Я ни в коем случае не говорил, что сами тесты — плохо, тесты — это хорошо, но только до тех пор, пока над ними не начинают ставить странные опыты.
Еретический метод — внесение абсолютно лишнего уровня абстракции.
Полностью «классические» тесты заменить на него не получится, а значит его использование в проекте только увеличит сложность поддержки (через добавление лишних сущностей и связей), не принося существенной пользы.
А так, имеем пустозвонство из совершенно рядового события.
2. Все они обучались методом глубокого обучения, которому и посвящена исходная статья.
То есть вся исходная статья посвящена особенностям работы конкретного метода обучения на паре конкретных архитектур.
Исследователи молодцы, что нашли существенный баг в этом популярном и перспективном методе, но их результаты никак не могут претендовать на революционность или философскую ценность.
Есть хорошие и подробные математические выкладки и по ним пишут толстые книги.
К сожалению люди, которые этим занимаются серьёзно, редко пишут научно-популярные статьи и интернеты застраны описанием «магических» нейронных сетей без какого-либо объяснения принципов их работы.
Изучался один тип сетей из многих и результат применим только к нему.
>если у вас есть фотография кота, существует набор небольших изменений, которые могут сделать так, что сеть будет распознавать кота как собаку
Бредовое утверждение, хотя бы потому, что сеть, распознающая котов о собаках ничего не знает. Она может распознать кота как «не кота», не более.
Даже если сеть обучена распознавать и котов и собак, из эффекта описанного в статье не следует, что можно подобрать пример, который будет воспринимать кота собакой, а не «не котом».
Вспомнил как начинал я и мои однокурсники, так вот, по данным рекомендациям нас бы всех поувольняли. Хорошо, что наши работодатели подходили к вопросу более индивидуально.
G+
Сейчас занят свой инди браузеркой: «Сказка»
Извините, это сколько в год будет?
Было бы неплохо, если бы появился профсоюз и занялся хотя бы этим, а заодно следил за различными договорённостями о «не переманивании сотрудников».
Что ж они там 5 лет делали-то… вибраторы по карманам распихивали?
В чём сложность, поясните.
Иными словами, более серьёзных отличий от существующих продуктов нет?
К слову, смесь фэнтези и технологий уже давно не является уникальным явлением в геймдеве.
> result = self.client.get('/products/123/')
> self.assert('title' in result.body)
Человек, который работал в Excel, писал макросы для Word, настраивал что-нибудь в Jira, или ещё чего-нибудь похожее делал хоть раз в своей жизни, поймёт что тут написано. Это не говоря уже о том, что не ясно зачем ПМ-у вообще лезть в эти тесты.
Если же по какой-то неимоверной случайности этот ПМ вообще не сталкивался с программированием, то вот хороший повод узнать таки, чем он управляет.
И тем не менее ему надо учить всех людей, которые будут с ним взаимодействовать и большинство из которых точно может обойтись без него. Зачем тогда его вводить? Этот полу-формальный формат — отличный пример лишней сущности.
>Такая «спецификация-тест» для человека со стороны лучше, чем простой тест и никакой спецификации.
Простой тест и есть спецификация, причём максимально конкретная. Более того, простой тест более гибок, чем правила на специфичном для проекта ЯП, описывающем только часть (причём меньшую) предметной области.
Даже писать простые тесты с подробными комментариями на нормальном языке проще, чем поддерживать отдельный ЯП для описания этих тестов на «почти» нормальном языке.
Вообще, кто этот мифический «человек со стороны»?
Использование BDD предполагает:
1. Введение в проект нового ЯП со своим синтаксисом и семантикой (а значит обучение им всех специалистов, работающих с тестами).
2. Дублирование части функционала, для возможности его использования в BDD.
3. Поддержка дублированного функционала (как только будет надо сделать какое-то новое действие, его надо замапить в правила).
Человек, который пишет тесты (а значит явно описывает требования спецификации ПО), должен быть в состоянии писать простейшие алгоритмы. Если он не может этого делать, то его нельзя допускать до этой работы. А если он может писать алгоритмы, то разницы между:
— user.create(name='test_name')
— «create user with name 'test_name'»
никакой нет, за тем исключением, что программистам будет проще разобрать 1-ый вариант, так как они его по 20 раз на дню видят.
Я ни в коем случае не говорил, что сами тесты — плохо, тесты — это хорошо, но только до тех пор, пока над ними не начинают ставить странные опыты.
Полностью «классические» тесты заменить на него не получится, а значит его использование в проекте только увеличит сложность поддержки (через добавление лишних сущностей и связей), не принося существенной пользы.
Для своего проекта ищу что-то похожее, пока не нашёл.
Писался для моего проекта, поэтому умеет не много «национальностей», зато может делать имена на кирилице с полным набором склонений.