Правда, тут надо смотреть на саму плоскость (w1x1+w2x2+w3x3+...),
нормаль к плоскости (т.е. точки должны находится не просто выше или ниже линии\плоскости, а с нужной стороны (по нормали) )
И пропускать\не пропускать весь вектор\выбранную маску дальше (на следующий слой).
Такая нейросеть не нуждается в обратном распространении ошибки, не подвержена всем известным проблемам DeepLearning, гарантированно находит любые подпространства (и вообще похожа на Word2Vec :) )
у них отсутствует способность к обобщению на новые стимулы, не совпадающие в точности с теми, которые были показаны при обучении
Ну да, вы же не пропускаете\не пропускаете сигнал на основе данных с перцептрона, а выполняете преобразования.
Естественно, способность к генерализации падает.
Это интуитивно понятно.
Простое, довольно очевидное преобразование.. Пумы?
А если просто пропускать или не пропускать сигнал - получается метод секущих плоскостей (потому что в простейшем случае w1x1+w2x2+w3x3 - уравнение плоскости). И можно отказаться даже от обратного распространения ошибки :) (И это решит все проблемы DeepLearning, да еще без использования этих сложных обратных распространений :) )
И вы получите аналог бустинга\деревьев.
И, да, в этих исследованиях ИИ никто не понимал, что веса - это тангенциальные коэффициенты плоскости, а вы замахнулись аж на основу основ :)
даже если оставить в стороне ценность вашей задумки в целом
Даже если оставить в стороне то, что вы слабо понимаете outbox в шинах, а я вполне себе делаю Metadata-Driven Framework-и в DDD/CleanArchitecture (и использую этот метод регистрации в кодогенерации. Потому что это единственный приемлемый метод в кодогенерации).
Абстракции Unity весят дай бог килобайт. Мне проще делать 1 nuget проект для 10 популярных контейнеров, чем разбивать все на RegisterByAttributes.Abstractions, RegisterByAttributes.Unity и прочее (потому что весь пакет весит дай бог 20 кб).
И еще 150+ человек, у которых ушел BoilerPlate регистраций, не будут разбираться в 3+ пакетах.
А, ну и такая мелочь, как Все популярные либы уже поддерживают добавление конфигураций\реализаций и контроллеровБЕЗ ЛИШНИХ ДЕЙСТВИЙ. (AutoMapper, MVC, etc.)
Не знаю, почему подобный способ вызывает столько саркастических усмешек - не надо даже возится с рефлексией, просто добавляешь атрибуты.
С версии 1.0.0.3 поддерживается регистрация типов, интерфейсы для которых могут быть где угодно. При этом регистрируются типы из сборки, где вызываешь.RegisterByAttributes();
Т.е. строк точно меньше, чем при в регистрации в контейнере. Менее 1 строки на реализацию интерфейса.
Все не "размазано по солюшену", а берется из метаданных к интерфейсу\классу.
С тем же успехом можно сказать, что из-за модификаторов доступа теперь все размазано по солюшену, без единой таблицы импорта\экспорта :).
Размазано по солюшену - это именованные (Keyed) регистрации, и их получение из контейнера :). Вот где место скопления ошибок, не видимых при компиляции.
При обычной регистрации будет использоваться тот, что зарегистрирован последним. Или надо использовать named регистрации. А здесь какой порядок будет?
Тот класс, который зарегистрирован последним. Специально для Вас вышла версия 1.0.0.4. С поддержкой Keyed регистрации. Надо установить name в атрибуте для реализации.
Но на мой взгляд это плохая практика, у нас еще появляются списки имен, которые надо тащить в сервисы.
Такая декларативная регистрация, разбросанная по коду на мой взгляд не очень удобна, поскольку требует времени на поиск и идентификацию
Скорее, наоборот. Ctrl+T, Открыл интерфейс/класс и смотри.
Регистрации в контейнерах тоже не удобно - по 700 строк бойлерплейта, тяжело мержить, добавил интерфейс\реализацию - иди пиши еще 50 строк, не пропусти ничего и т.д.
Правда, тут надо смотреть на саму плоскость (w1x1+w2x2+w3x3+...),
нормаль к плоскости (т.е. точки должны находится не просто выше или ниже линии\плоскости, а с нужной стороны (по нормали) )
И пропускать\не пропускать весь вектор\выбранную маску дальше (на следующий слой).
Такая нейросеть не нуждается в обратном распространении ошибки, не подвержена всем известным проблемам DeepLearning, гарантированно находит любые подпространства (и вообще похожа на Word2Vec :) )
Ну да, вы же не пропускаете\не пропускаете сигнал на основе данных с перцептрона, а выполняете преобразования.
Естественно, способность к генерализации падает.
Это интуитивно понятно.
А если просто пропускать или не пропускать сигнал - получается метод секущих плоскостей (потому что в простейшем случае w1x1+w2x2+w3x3 - уравнение плоскости). И можно отказаться даже от обратного распространения ошибки :) (И это решит все проблемы DeepLearning, да еще без использования этих сложных обратных распространений :) )
И вы получите аналог бустинга\деревьев.
И, да, в этих исследованиях ИИ никто не понимал, что веса - это тангенциальные коэффициенты плоскости, а вы замахнулись аж на основу основ :)
Еще не проверял признаки Чего.
Очевидно, наличия психопатий :)
Может оказаться и Volatile Organic Compounds,
https://coub.com/view/322a66
Проверяйте наличие вентиляции, приточки и вытяжки.
Расположение источников света.
Наличие психопатий у непосредственно контактирующих с вами (чрезмерная общительность, или наоборот, замкнутость).
Пятна на стенах\полах(!).
Не важно, 3Гис это, БСК, или еще кто - работодатель должен обеспечивать безопасные условия труда.
Даже если оставить в стороне то, что вы слабо понимаете outbox в шинах, а я вполне себе делаю Metadata-Driven Framework-и в DDD/CleanArchitecture (и использую этот метод регистрации в кодогенерации. Потому что это единственный приемлемый метод в кодогенерации).
Абстракции Unity весят дай бог килобайт. Мне проще делать 1 nuget проект для 10 популярных контейнеров, чем разбивать все на RegisterByAttributes.Abstractions, RegisterByAttributes.Unity и прочее (потому что весь пакет весит дай бог 20 кб).
И еще 150+ человек, у которых ушел BoilerPlate регистраций, не будут разбираться в 3+ пакетах.
А, ну и такая мелочь, как Все популярные либы уже поддерживают добавление конфигураций\реализаций и контроллеров БЕЗ ЛИШНИХ ДЕЙСТВИЙ. (AutoMapper, MVC, etc.)
Не знаю, почему подобный способ вызывает столько саркастических усмешек - не надо даже возится с рефлексией, просто добавляешь атрибуты.
Проект делался еще когда был unityContainer, Scoped тогда не было.
И из всего рефакторинга с тех пор только поддержка IServiceCollection и тесты.
Не нравится - делайте рефакторинг, присылайте мне на ревью.
Я буду использовать как минимум в своих Metadata-driven фреймворках )
Мне нужна регистрация по атрибутам.
Подробнее, имена проектов на Github, nuget пакетов.
И т.д., и т.п.
P.S. да, минутный рефакторинг и NetCore 2.0.
С заменой Unity на Unity.Abstractions (Теперь вы можете не тащить в свой проект Unity :) )
Напишите, как вы боритесь с размазанностью модификаторов доступа.
Что не так?
Вы пишите подробнее, пожалуйста )
Это - разбиение действий на шаги, гугл не может такое патентовать.
Это вообще рекламная фирма, у которой технологии (кроме карточек фирм) - хз откуда ).
Там уже 3 трлн$ финансирования в ничего, сейчас даже Вам станет плохо (если еще не стало).
Ну, да, вам про декартов квадрат еще лет 5 назад писали.
Теперь поди "Simple, persistent states, sets of actions"
Да еще и за целых 4 цента.
Спасибо за бесплатные технологии, ждем менее политизированные реализации из Китая :)
Так бот сложный. SQUAD.
Опишите предметную область в объектах.
Сделайте ToString.
Готово Q&A по любой (температура за бортом и т.д.)
Неограниченно расширяйте описываемую область - справка все равно доступна.
Если вы делаете что-то - прикрутите еще и обьекты из трекера )
Ну вы еще бэк не смотрели:
"Ок, ЧудоНейросеть, разбей запрос на простые шаги".
Проклятие Декартова Квадрата решено!
NanoBanana в действии!
Apple готовит триллион!
Стойте, это же TractorPilot!
https://habr.com/ru/companies/tractorpilot/articles/880596
ну да, до них были Fujitsu, с их интегратором)
Быстродействие и масштабируемость не нужны, сказано же - это парни аж из рекламной фирмы. Инвестиции уже есть.
Ну, если менеджемента нет, то и смысл писать об отсутствующем управлении статьи.
Отсутствие менеджемента и "Техдолг" - одно ли это и то же?
С версии 1.0.0.3 поддерживается регистрация типов, интерфейсы для которых могут быть где угодно. При этом регистрируются типы из сборки, где вызываешь
.RegisterByAttributes();Дык и?
Режим рассуждений не их.
Глобальную оптимизацию они не запатентуют. (DeepThinking)
Запускать NLU, DreamCoder, транслировать LISP в C++ умеют все.
нет, читайте внимательнее.
98% регистраций - атрибут НА ИНТЕРФЕЙСЕ.
Т.е. строк точно меньше, чем при в регистрации в контейнере. Менее 1 строки на реализацию интерфейса.
Все не "размазано по солюшену", а берется из метаданных к интерфейсу\классу.
С тем же успехом можно сказать, что из-за модификаторов доступа теперь все размазано по солюшену, без единой таблицы импорта\экспорта :).
Размазано по солюшену - это именованные (Keyed) регистрации, и их получение из контейнера :). Вот где место скопления ошибок, не видимых при компиляции.
Атрибуты на оба интерфейса
[TypeRegistration(LifetimeManagementType.Default)]на класс
[DerivedTypeRegistration(LifetimeManagementType.Singletone)]Тот класс, который зарегистрирован последним. Специально для Вас вышла версия 1.0.0.4. С поддержкой Keyed регистрации. Надо установить name в атрибуте для реализации.
Но на мой взгляд это плохая практика, у нас еще появляются списки имен, которые надо тащить в сервисы.
Скорее, наоборот. Ctrl+T, Открыл интерфейс/класс и смотри.
Регистрации в контейнерах тоже не удобно - по 700 строк бойлерплейта, тяжело мержить, добавил интерфейс\реализацию - иди пиши еще 50 строк, не пропусти ничего и т.д.
Fody - работа с IL готовой сборки.
Логирование начала конца метода сделано зря.
System.Reflection тут нет.