Соберусь как-нить написать о его последыше для медицины. Гибрид с нейросетью и формализм там проще и понятней. Этот, который в ссылке, устарел на 10 лет. Все рабочее).
Система оперирует предоставленными фактами и выводит на них. даете другие факты, получаете другой результат. вообще не проблема, кто там согласен или нет — вот доказательсво на этих фактах. имитация, как по мне, — тема, перпендикулярная логике.
Спросить у сетки ответ на вопрос 42, который главный поставил бы любой ИИ в тупик, ибо он адресует миллионы вопросов в диалогах и опросниках. Глупые фразы типа «Почему вообще существует что-то, а не ничто?» еще дальше увели контекст, потому как обобщить двойную, тройную чушь можно только как чушь.
Дальше сетка ухватилась за факт диалога псевдогения и сына, пытаясь раскрутить ту немногую убогость сказазанного что нашла. Раскрутка завершилась неудачно, потому ничего сколько-нибудь внятного сказано между ними не было. Ввели чушь — получили ее же, сдобренную синтаксическим сахаром. Не рекомендую покупать курс от таких авторов.
Чтобы пользоваться X языком для описания знаний в идеале нужен прямой конвертер ЕЯ -> язык X. Зачем делать то, что можно не делать? Не вижу высокого уровня абстракции, который мог бы это позволить.
При ней
concept unpaidBill is bill where amountToPay > amountPaid;
превратился бы в
concept unpaid is not paid;
property paid of bill, agent
Борьба есть там где есть конфликт. Полагаю что можно, но сложно жить без него. На мой взляд наибольший кофликт обычно лежит в плоскости желаний-требований индивид-социум. Отшельникам легче всего быть счастливыми. Буддиским монахом тоже норм, то не так круто)
С чего это независимыми. Проговаривание чего-либо способствует 1) лучшему запоминанию 2) повышению концентрации == поиска в глубину ~= поиска следствий проговоренного; 3) репетиция и готовность к реакциям в предстоящем или мнимом, но важном диалоге с кем-то; и т.д.
«Написав код на python вы сможете перенести его на lua, c++ и так далее. Очень удобно для портирования.»
Все же на Hex. Синтаксис его не фонтан — ерш шапра с javascript, но если можно сразу конвертить сцены из blender, то это мелочь. Спасибо за инфу, надеюсь на продолжение.
Приавильно ли я понял что у вас есть математически корректные модели поведения главных разновидностей нейронов, которые учитывают концентрации нейромедиаторов (у вас это сигнальные молекулы)? Возможно ли на этом фреймворке вырастить оптимальную нейросеть для решения какой-нить задачи?
Тоже работаю за команду. Если у Вас есть промежуточный результат в виде множества конъюнкий, построить по ним по формулу не представляется особо сложной задачей. Студентам-головастикам вполне под силу. Хотя я зашел бы с другой стороны — кластерного анализа. Там сложностей меньше, и сразу понятно, где конъюкции, где дизъюнкции и как именно дробить диапазоны. Надо будет подумать, не сделать ли самому)
В общем, нормально написано, но конкретные детали для того, чтобы это реально пошло — не увидел.
Интерфейс библиотеки должен быть приближен к обычным данным, т. е. брать на вход обычную матрицу данных (pandas-стандарт) и давать по ней результат (какие колонки-значения-диапазоны дают правильную конъюнкцию). все остальное — не важно.
Но это только часть дела. Как аналитик я не пойму почему такие сложности дают лишь массив конъюнкций. Чтобы это и впрямь было интересно, библиотека должна определять оптимальную формулу-дерево для детектирования любой группы. как по мне я не вижу в этом особых сложностей, а оптимальная формула группы с наперед заданной точностью — это то, что нужно. Возможно я это пропустил и это реализовано, но без этого Ваша разработка годится только для ограниченного применения.
Задача что внутри сервер делает с событиями, синхронизации пользователей, данных сервера — это прикладной уровень и к условному uniGUI не относится. Его задача отрисовать описание, и передавать инфу об его(описании) изменениях юзером(и).
не так. состояние GUI — это экран юзера и он соответсвует только ему. для сервера это какой то экземпляр Screen, уникальный для юзера, и создающийся для него при коннекте клиента. режим эха-зеркала и правда доступен на сервере. это будет, если нескольким вернуть один экран (тот же объект сервера).
сложные элементы управления такие Таблицы, Viewers, могут иметь дополнительные параметры, как то ‘colors’, ‘params’,… которые могут использоваться для специфической отрисовки или выбора доступных опций
По умолчанию — максимальный набор опций,
2.Здесь дело вкуса и информативности. вы сразу видите, что в экране еще чего-то есть, не скроллируя.
нажать кнопку и переместиться на нужный блок быстрее чем скролл и поиск. Но такие мелочи могут настраиваться в опциях автодизайнера, который учтет вкусы пользователя, пользователем.
3. все можно описать декларативно, кратчайшим образом. Все то, что за пределами логики стандартного GUI описывается в сервер логике. Маски, допустимость ввода обрабатываются сервером когда получил событие. Прослойка автоматом имеет на все обработку по умолчанию. Свой обработчик позволяет принять или откатить и сделать в ответ все что угодно с экраном пользователя, послав ему новый экран или апдейт экрана.
1. Автодизайнер дизайнит под конкретное разрешение используя логику web-дизайнера-программиста, когда ему нужно отобразить данные. если все данные вместить невозможно, то нарисует первый(е) блоки, на остальные нарисует иконы в тулбаре.
Прослойки — это адаптеры для языка которые только обеспечивают автоматизм отправки-синхронизации данных пользователя <-> данные GUI. для питона например такая прослойка занимает ~ 250 строк кода. и она универсальная а не прошитая под мои потребности.
2. Локально запускайте сервер-app. Без сервера работать не должно)
3.Сервер дает описание данных. Клиент обеспечивает все остальное.
4.https соединение. клиент шлет только свои события.
5. Расширение типов. Сейчас на некоторые типы данных возможна отрисовка по разному. Если на один тип данных более одного виджета, просто всунуть type:MyNewTree. Если такие типы будут написаны на Dart, то динамическая стыковка вполне реализуема. но как по мне то что в Google MD поддерживать автоматом не морочиться этим.
Дальше сетка ухватилась за факт диалога псевдогения и сына, пытаясь раскрутить ту немногую убогость сказазанного что нашла. Раскрутка завершилась неудачно, потому ничего сколько-нибудь внятного сказано между ними не было. Ввели чушь — получили ее же, сдобренную синтаксическим сахаром. Не рекомендую покупать курс от таких авторов.
При ней превратился бы в
Все же на Hex. Синтаксис его не фонтан — ерш шапра с javascript, но если можно сразу конвертить сцены из blender, то это мелочь. Спасибо за инфу, надеюсь на продолжение.
Интерфейс библиотеки должен быть приближен к обычным данным, т. е. брать на вход обычную матрицу данных (pandas-стандарт) и давать по ней результат (какие колонки-значения-диапазоны дают правильную конъюнкцию). все остальное — не важно.
Но это только часть дела. Как аналитик я не пойму почему такие сложности дают лишь массив конъюнкций. Чтобы это и впрямь было интересно, библиотека должна определять оптимальную формулу-дерево для детектирования любой группы. как по мне я не вижу в этом особых сложностей, а оптимальная формула группы с наперед заданной точностью — это то, что нужно. Возможно я это пропустил и это реализовано, но без этого Ваша разработка годится только для ограниченного применения.
2.Здесь дело вкуса и информативности. вы сразу видите, что в экране еще чего-то есть, не скроллируя.
нажать кнопку и переместиться на нужный блок быстрее чем скролл и поиск. Но такие мелочи могут настраиваться в опциях автодизайнера, который учтет вкусы пользователя, пользователем.
3. все можно описать декларативно, кратчайшим образом. Все то, что за пределами логики стандартного GUI описывается в сервер логике. Маски, допустимость ввода обрабатываются сервером когда получил событие. Прослойка автоматом имеет на все обработку по умолчанию. Свой обработчик позволяет принять или откатить и сделать в ответ все что угодно с экраном пользователя, послав ему новый экран или апдейт экрана.
Прослойки — это адаптеры для языка которые только обеспечивают автоматизм отправки-синхронизации данных пользователя <-> данные GUI. для питона например такая прослойка занимает ~ 250 строк кода. и она универсальная а не прошитая под мои потребности.
2. Локально запускайте сервер-app. Без сервера работать не должно)
3.Сервер дает описание данных. Клиент обеспечивает все остальное.
4.https соединение. клиент шлет только свои события.
5. Расширение типов. Сейчас на некоторые типы данных возможна отрисовка по разному. Если на один тип данных более одного виджета, просто всунуть type:MyNewTree. Если такие типы будут написаны на Dart, то динамическая стыковка вполне реализуема. но как по мне то что в Google MD поддерживать автоматом не морочиться этим.