Здравствуйте, Sheridan, Вы писали:
S>Ну как то же учат AI в марио играть или AI к нейросетям отношения не имеет? (я ни то ни другое не курил подробно) S>http://www.youtube.com/watch?v=bBZ7kEphv3s
Обучить такому можно используя динамические модели, которые вообще не machine learning, а теория автоматического управления. Здесь задача
повторить движения игрока, за которым адаптивная система наблюдает, а потом на те же события (то же состояние среды) повторить реакцию.
Еще раз AI != Machine Learning, Machine Learning != Neural Networks.
Здравствуйте, Sheridan, Вы писали:
NB>>нейросеть, это грубо говоря "черный ящик". NB>>фиксированное количество входов, и фиксированное количество выходов. все естественно числовые значения. NB>>как твою форму туда запихивать будем? S>Ну как то же учат AI в марио играть или AI к нейросетям отношения не имеет? (я ни то ни другое не курил подробно) S>http://www.youtube.com/watch?v=bBZ7kEphv3s
Здравствуйте, m.aksenov, Вы писали:
MA>Обучить такому можно используя динамические модели, которые вообще не machine learning, а теория автоматического управления. Здесь задача MA>повторить движения игрока, за которым адаптивная система наблюдает, а потом на те же события (то же состояние среды) повторить реакцию. MA>Еще раз AI != Machine Learning, Machine Learning != Neural Networks.
О как. А что насчет этого?
Using a deep learning artificial neural network, I built a 2048 playing bot that teaches itself how to play over time. It reinforces itself after each move based on the score, and whether or not the move lead to a win or loss.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, m.aksenov, Вы писали:
S>О как. А что насчет этого? S>
S>Using a deep learning artificial neural network, I built a 2048 playing bot that teaches itself how to play over time. It reinforces itself after each move based on the score, and whether or not the move lead to a win or loss.
А тут надо смотреть методологию. Скорее всего решалась задача классификации,
но интересно взглянуть на топологию сети и конкретные методы обучения. Из акадамического интереса.
Здравствуйте, m.aksenov, Вы писали:
S>>http://www.youtube.com/watch?v=OKTD_VedHdA
MA>А тут надо смотреть методологию. Скорее всего решалась задача классификации, MA>но интересно взглянуть на топологию сети и конкретные методы обучения. Из акадамического интереса.
Если я не ошибся, есть исходники и я временно это запустил тут
Ну, тут примерно получается решение задачи оптимизации, хотя на мой взгляд, это решение задачи классификации
(оптимальное — неоптимальное локальное решение), но это уже философия скорее.
Если посмотреть на исходник библиотеки convnetjs,
которая там используется, то можно увидеть, что система берет случайные шаги в доступном пространстве решений и
пытается выбрать из 4 имеющихся наиболее выгодное. Сказать что это — прорыв весьма сложно, и, вероятно,
использование других подходов к решению этой задачи дало бы более эффективные результаты. Автор, кстати,
сам указывает, что до 2048 он еще пока не дошел, что намекает на то, что достижение локальных оптимумов
вообще говоря может не привести к решению целевой задачи.
Об этом (о вопросах сходимости и теоретической обоснованности модели), кстати, и написано в английской вики.
Здравствуйте, Sheridan, Вы писали:
S>А дальше гуй-компилер на основе подсказок и своего "опыта" выстраивает контролы на форме(формах) и генерирует код этих форм плюс код прослойки взаимодействия между формой и нашим кодом.
в 80-х генераторы программ для субд это делали. помню, на кларионе можно было за 10 минут создать простенькую программу, в частности благодаря этой фиче
Здравствуйте, Sheridan, Вы писали: S>А дальше гуй-компилер на основе подсказок и своего "опыта" выстраивает контролы на форме(формах) и генерирует код этих форм плюс код прослойки взаимодействия между формой и нашим кодом. S>Как то так.
Такого — как грязи. Все программисты проходят в своём взрослении через этап "давайте генерировать гуй по метаданным".
В дотнете, к примеру, встроен контрол PropertyGrid, который воплощает один из вариантов этой идеи.
Проблема — только одна: юзабилити такого гуя стремится к нулю.
При небольшом количестве управляемых параметров он не слишком ужасен, но и экономия усилий разработчика невелика. (Главное — он спасает от ситуации типа "добавили поле в базу — забыли добавить в UI").
А как только начинается что-то более-менее сложное — всё, копец, приехали.
Сгенерированный UI становится ужасен, и приходится звать дизайнера с юзабилистом, выбрасывать автогенерённый гуй и заменять его на спроектированный человеком.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, m.aksenov, Вы писали:
MA>Расположение элементов на форме — задача оптимизации скорее, и решается совсем по-другому.
Проблема — в том, что проектирование гуя не сводится к "расположению элементов на форме". В таких задачах равных компьютеру нет — достаточно скормить ему формальные правила вёрстки с параметрами "оптимизации", и он ловко раскидает контролы по форме в соответствии с этими критериями.
Увы, реального улучшения UI по сравнению с PropertyGrid вы так не получите. Для него надо копать глубже, и не только разбрасывать контролы, а и выбирать подходящие.
Ну там — если есть два параметра по три варианта каждый, то это 9 сочетаний. Не все сочетания могут быть валидны. И одну и ту же задачу "выбрать значения двух связанных параметров" можно решать огромным количеством способов:
— две радиогруппы, при выборе в одной невалидные значения в другой дизаблятся
— квадрат 3*3 из радиобаттонов, в котором нелегальные сочетания задизаблены сразу
— дроп-даун со всеми валидными комбинациями
— радиогруппа со всеми валидными комбинациями
Какой из них будет более удобен? А хрен его знает — без закапывания в семантику мы это не узнаем. Может быть, эти параметры вообще не надо вводить — они выводятся из контекста взаимодействия.
Может быть, из 5 легальных сочетаний этих двух параметров в 99% случаев используется ровно одно, а остальные надо показывать только по дополнительному запросу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Все, что ты показываешь, имеет четкие критерии входа и четкие критерии выхода. В случае с 2048 даже наверняка формально описываемые. В случае с формами у тебя будет проблема даже описать вход, не говоря уже о выходе.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, m.aksenov, Вы писали:
S>Проблема — в том, что проектирование гуя не сводится к "расположению элементов на форме".
Этого я и не утверждал. Но именно расположение исходя из набора ограничений, на мой взгляд, является задачей оптимизации
S>Какой из них будет более удобен? А хрен его знает — без закапывания в семантику мы это не узнаем. Может быть, эти параметры вообще не надо вводить — они выводятся из контекста взаимодействия. S>Может быть, из 5 легальных сочетаний этих двух параметров в 99% случаев используется ровно одно, а остальные надо показывать только по дополнительному запросу.
А тут может быть уже нужно привлекать статистику использования, как набор входных параметров. Есть, правда, опасения, что составить подходящую систему уравнений будет построить слишком сложно,
и проще нанять специально обученных людей.
Я просто предполагаю, что чисто механическую работу типа дизайна форм для оперденей можно решать в виде чего-то подобного, используя гайдлайны, например, Metro или Cocoa, и на основании них что-то строить.
Это будет аналог PropertyGrid или чего-то подобного, но с более-менее адекватными отступами и прочим. Зачастую люди сами ничего лучше не дизайнят, такой уж он, корпоративный софт.
Здравствуйте, m.aksenov, Вы писали:
MA>Этого я и не утверждал. Но именно расположение исходя из набора ограничений, на мой взгляд, является задачей оптимизации
Вы какую задачу хотите решить? Ту, которую удобнее, или ту, которая людям нужна?
MA>А тут может быть уже нужно привлекать статистику использования, как набор входных параметров. Есть, правда, опасения, что составить подходящую систему уравнений будет построить слишком сложно, MA>и проще нанять специально обученных людей.
Ну вот до ввода формы в эксплуатацию нет никакой статистики. А после ввода уже поздно заниматься редизайном.
Кстати, адаптивные UI умерли — помните меню офиса, которые автоматически сворачивали редкие пункты? Оказалось, что Ribbon на порядок удобнее.
MA>Я просто предполагаю, что чисто механическую работу типа дизайна форм для оперденей можно решать в виде чего-то подобного, используя гайдлайны, например, Metro или Cocoa, и на основании них что-то строить. MA>Это будет аналог PropertyGrid или чего-то подобного, но с более-менее адекватными отступами и прочим. Зачастую люди сами ничего лучше не дизайнят, такой уж он, корпоративный софт.
Если честно, я не понимаю этого разговора в 2015 году. В те времена, когда я занимался оперднями (а это было примерно 20 лет назад), всё, что вы описываете, существовало в полный рост.
Вы мне что, хотите сказать, что все эти формочки в 1c 8.х теперь снова педалятся вручную?
Верится, если честно, с трудом. У нас вот, к примеру, в APS 1.2(образца ~2010 года) весь UI взаимодействия с пользователем генерировался автоматически на основе метаданных. И это далеко не первый проект такого рода. Лично мой первый проект такого рода был написан в 1991 году на Клиппере.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
S>Камрады, не всплывала ли идея? Реально ли реализовать? S>Что думаете?
Нужно не просто построить, а выдать тот, который понравится большинсту пользователей. Пока что нет способа более-менее формально описать "нравится-не нравится" особенно с учетом различия у разных аудиторий.
И описывать придется не просто важность свойств, а учитывать все нюансы взаимодействия с пользователем, всю семантику каждой операции.
BT>>А вот как обучить нейросеть продумывать ресайз и якоря — S>Это да... Тут придется хорошенько думать...
ИМХО, как раз ресайз и якоря — это та часть гуя, которую проще всего скормить нейросети (с тем, чтобы получить на выходе осмысленный результат).
Примерно так:
1. Взять набор форм из разных приложений, которые мы считаем "хорошими" в плане гуя. Их ресайз и якоря — либо должны быть описаны декларативно, либо их можно вытащить эмуляцией (программно порастягивать форму, посмотреть, как изменились контролы, и все это записать в статистику).
2. На этой обучающей выборке обучить нейросеть. Получившаяся обученная нейросеть должна представлять собой "правила хорошего тона" для ресайза контролов.
3. К контролам новой формы применить эти правила ресайза, записанные в структуре нейросети (т.е. на выходе получить программный код, делающий ресайз в соответствии с этими правилами).
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Sheridan, Вы писали:
S>> Ну не скажи, в корпоративном софте частенько встречаются монстроформы с 30+ контролами
W>Это встречается в узких нишах от отсутствия конкуренции. В конкурентной среде такие долго не выживают.
Как раз таки в конкурентной среде такие и выживают. Потому что в корпоративном софте приоритет это — скорость разработки фич, и на всё остальное плевать: Пока к коробочной софтине нарисуют три формы, семь раз измерив пиксели, в корпоративной среде нарисуют одну (заменяющую все три) и состряпают отчёт по вводимым в эту форму данным.
Пока в коробочной софтине разрабы мучают асинхронщину с индикаторами и прогресс барами, разрабы корпоративного софта, повесив часики на указатель мыши, и давно забыв о каких-то там тормозах, пилят новый функционал.
Пока разрабы коробочной сонфтины мучают правильное отображение ошибок, разрабы корпоративного софта, положив болт на кастомные мессаги и иконки, и возложив всю отвественность на глобальный обработчик исключений, пилят новый функционал.
Дизайнеры для коробочного софта определяют концепты, рисуют иконки, продумывают UI, но они не создают фич, поэтому в корпоративной разработке их нет.
Итого: корпоративная софтина за то же время получит в десять раз больше полезных фич, чем к коробочной софтине будет прикручено свистоперделок. Фичи в единицу времени определяют конкурентное преимущество,
ибо в отчёте о разработке ты не можешь описать красоту форм, а список фич описать обязан.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, m.aksenov, Вы писали: MA>Это будет аналог PropertyGrid или чего-то подобного, но с более-менее адекватными отступами и прочим. Зачастую люди сами ничего лучше не дизайнят, такой уж он, корпоративный софт.
А, вот, собственно. http://rsdn.ru/forum/usability/4896253.1
Здравствуйте, Sheridan, Вы писали:
S>Камрады, не всплывала ли идея? Реально ли реализовать? S>Что думаете?
Думаю сначала надо сделать функцию оценки gui по разным критериям.
Читаемость, функциональнось, последовательность операций, группировку, кол-во операций для выполнения типовых сценарив и т.п., утомляемость, концентрацию, кол-во параметров удерживаемых в памяти ...
По целевым группам: ввод данных для дебилов, ввод данных дисциплинированным персоналом, мониторинг, отладка, ....
Только потом можно натравливать нейронные сети, генетические алгоритмы и другие методы перебора вариантов с
различными эвристиками и адабустами.
