Евгений Лернер, создав техническое заданее с Персептроном ты себя немножко ограничил. Персептрон архитектурно не работает c непрерывными величинами. Следовательно твои 32 коэффициента Уолша будут порезаны входным S-элементом.
Я-бы предложил просто отказаться от задания с персептроном и работать с общей нейронной сетью. Это развяжет нам руки хотя-бы в обсуждении.
Александр Скуснов человек спрашивает как раз про то что нет общих рекомендаций к выбору количества скрытых нейронов в слоях. Мы знаем сколько надо входов и сколько выходов (это ТЗ). А внутренняя структура сети как мне кажется подбирается экспериментально.
На псевдокоде это может звучать как-то так.
1) Для всех этажей - создать узлы графа.
2) Для каждого этажа - создать возможные переходы
3) Для ответа на вопрос Сколько различных этажей можно.... мы решаем задачу достижимости на графе.
Конечно в любой олимпиадной задаче всегда есть пути срезать углы и не делать сверх-задачу.
Евгений Лернер, давай я объясню как я себе это вижу. Современные нейросетевые алгоритмы - это очень длинный стек технологий который включает в себя выбор архитектуры сети. Выбор и подготовку данных. Обучение. И использование модели. И нельзя сводить этот сложный вопрос просто к скорости реализации одного нейрона. Тем более что в этой технологии GPU/TPU эта скорость учтена в матричном уножении матриц вещественных чисел.
Никто в топике не сможет тебе провести сравнение этих скоростей. Это все равно что делать суждения о сервере на основе того как быстро срабатывает транзистор в его аппаратной архитектуре.
Евгений Лернер, нейрон - это просто произведение вектора входов на вектор весов и применение
функции активации. Это работает везде одинаково. Понимаешь? Это - как посчитать курс валют
на калькуляторе. Поэтому постановка вопроса - скорее всего неправильная. Думай как спросить
правильно.
Я не знаю что тебе ответить. Мне нужен контекст. Какая тема твоей лабораторной работы? Если ты
изучаешь алгоритмы сортировки то ты выбрал не самый быстрый. Если тебе алгоримты не важны
а нужно просто сортировать с использованием алгоритмов STL то почему ты не воспользовался
примером со stackover?
Если вы просто знаете ваши арендованные IP адреса - то просто пошарьте файл через http или ftp и скачайте.
Так - быстрее. Если вы хотите опубликовать новый релиз и чтобы много людей об этом знали то наверное надо
просто подождать.
В задачах прогнозирования опираются обычно на некоторый интервал времени (например 1 день или 1 неделя)
и дальше рисуют экстраполяции.
Ответить вот так вот ДА или НЕТ на такой сложый вопрос я считаю просто невозможным. И любые попытки вывести ответ из статьи будут просто спекуляциями. Или прогнозами в условиях ограниченных знаний.
Иван Мельников, оптимальный в чем? Есть разные пути оптимизации. По объему кода. По скорости вычислений. По объему занятой временной памяти для алгоритма. Если ты хочешь серъезно так... по честному провести сравнение то тебе нужна среда где можно измерять все эти параметры.
Мой опыт подсказывает что в dbms обычно не ищут перфекционизма а просто берут то решение которое работает и то которое ДОСТАТОЧНО для выдачи ответа.
Я не знаю Hive, но если там поддерживается SQL explode - то разверни эти массивы на 90 градусов
и получишь обычную таблицу и дальше реляционными операциями сделай нужные поиски.
Я никогда не встречал в JDBC DML в несколько таблиц. Я-бы предложил автору поискать в документации где это явным образом разрешено или где есть туториал или грамматика которая описывает такой трюк.
Валентин Бируля, дьявол как всегда кроется в деталях. Говоря о "многих функциях" мы можем овер-инжинерить любую задачу. Я-бы предпочел идти от простого к сложному. Так - проще обсуждать задачу. Иначе мы запутаемся.
Твой вопрос пока не имеет никакого отношения к AWS. Я-бы предложил убрать ненужный тег чтоб не сбивать с толку читающих. Работа прогресс бара лежит в плоскости твоего кода. И аммазон здесь или ажур - без разницы.
Я-бы предложил просто отказаться от задания с персептроном и работать с общей нейронной сетью. Это развяжет нам руки хотя-бы в обсуждении.