Бывают люди для которых пассивный отдых счастливее активного, особенно в пункте социализации. Также укрощение своих желаний, либо природная скромность, глубокая медитация способны дать плюс к счастью, которому может сам Маск позавидует. В общем и бедным можно спокойно кайфовать, если башка варит.
Кроме того, пользователь должен легко получать от интерфейса обратную связь.
Все эти задачи решаемы при помощи современного искусственного интеллекта.
Эти задачи решаемы безо всякого ИИ. Только нужно отталкиватся от данных, которые мы хотим визуализировать и работать с ними. У некоторой системы есть данные, а мы хотим чтобы GUI-система их оптимально визуализировала в понятном или нужном нам виде/дизайне и позволила нам с этими данными работать. автоматом. пример такой GUI-системы . https://github.com/Claus1/unigui Однако это верно если данные первичны, а дизайн - вторичен.)
писал на flutter в основном для web ~ 2 года, когда он еще был то ли в бете, толи еще в чем. медленно работал в 3-4 х(чем если б на js), либы flutter в основном не подходили для web, js либы тоже не подключишь, качество кода middle-web было таким, что переделал половину элементов. криво-косо работали, вменяемый саппорт отсутствовал. плюнул и ушел на vue, когда новый dart сломал совместимость с написанными и используемыми либами. vue и web тоже не мед, но то было пыткой.
Если кто-то знает, как быть с этой проблемой, поделитесь, пожалуйста, со мной советами.
Повторяемость информации ведет к субъективному повышению ее достоверности из-за фундаментальной особенности мозга к индукции частностей. Если информацию можно верифицировать - проблемы нет, если сделать это оперативно. Если это невозможно - ставить флаг "не доказано" и не забывать этого.
не похож ни разу на hypergen. html разметки нет в принципе. только декларация данных и их ЛОГИЧЕСКАЯ группировка. "Proof of concept" было давно. рабочий инструмент для меня)
Не вижу оснований и предпосылок в корреляции случайных текстов персоны и ее характеристик в общем случае. скорее всего именно поэтому был закрыт этот "сервис". впрочем, один частный случай и правда есть: если все такие тексты написаны человеком как характеристики на самого себя по всему этому спектру характеристик. именно то, что разбиение текста "улучшает" результат, подтверждает мою мысль - нейросеть "переобучается" лучше на дробленных текстах.
В целом очень позитивно и стоит развить в религию или ветку философии. Некоторые моменты стоит еще углубить. Некоторые из них:
Таким образом мы приходим к выводу, что "Я" или представления о "душе" - это вымышленные вещи.
Из текста не следует, что процессы - Я, мысли о Я - происходяшие в материальных системах, явпяются вымышленными (ложными).
Но, если это так, то тогда наше представление о себе, как о наборе "состояний" за последние несколько минут жизни, или лет жизни - суть не важно, не более чем воображение и абстракция.
Раз это находит отражение в материальном мире - состояние нейронов + процессы, которые мы запустим или остановим - это не просто воображение и абстакция.
Это означает, что идея о себе, как о "непрерывно" существующем "Я", мягко скажем, очень ошибочна. Будет ли существовать некий субъективный опыт в каком-то мозге, зависит лишь от того, будет ли во вселенной представлена материя этого мозга, или нет. Но нельзя сказать, что это будешь именно "ты".
Утрата со временем опыта в силу неточности воспроизведения информации - фундаментальное свойство мозга, связанное с непрерывной компрессией и копированием информации. Они выработаны эволюцией так, чтобы оставаться +- той же особью со временем в критически важных аспектах.
Рабочие идеи стоят и сами по себе и зарабатывать на них можно и не сложно (см. патентный троллинг). Когда покупают пакеты патентов, средняя цена мало-мальски используемого патента минимум лимон $. ценные идеи рассказывать без патента нельзя даже патентному поверенному, если у него нет долгой и безупречной репутации. если все равно хочется - не рассказывать "секретный соус", без которого идея не заработает. и наконец, идеи для игр и правда ничего не стоят)
>>вот здесь вам может потребоваться дополнительный инструментарий поверх HTML.
не нужно это, если протокол покрывает все нужные типы данных, и устраивает единый стиль интерфейса (MD). Если на всех экранах нужен составной элемент, делается блок, кладется в blocks папку и используется во всех экранах.
Пример:
Вверху общий блок Parameters. Описан 1 раз в blocks.
Из вещей, требующих улучшения: сейчас есть оверхед с адаптерами для компонентов. Для условного компонента Table требуется адаптер, чтобы соединить его (компонент) со слоем DSL. Опираясь на текущий опыт, это кажется избыточным. Работаем над упрощением.
Если я прально понял проблему - REST+JSON - много головняка, стандартов, писанины. Если закрыть более простым и менее гемморойным протоколом чем html/xml, то возможно, муры писать будем меньше. Такой протокол/решение есть - https://github.com/Claus1/unigui
Я б посоветовал глянуть Redisgraph, если скорость действительно волнует. там она в десятки-сотни раз больше https://redis.com/blog/new-redisgraph-1-0-achieves-600x-faster-performance-graph-databases/
Даздраперды?
Бывают люди для которых пассивный отдых счастливее активного, особенно в пункте социализации. Также укрощение своих желаний, либо природная скромность, глубокая медитация способны дать плюс к счастью, которому может сам Маск позавидует. В общем и бедным можно спокойно кайфовать, если башка варит.
Видео со сравнением с другими стетками https://www.youtube.com/watch?v=gy-dnOhfiWs&ab_channel=DrAlanD.Thompson
Эти задачи решаемы безо всякого ИИ. Только нужно отталкиватся от данных, которые мы хотим визуализировать и работать с ними. У некоторой системы есть данные, а мы хотим чтобы GUI-система их оптимально визуализировала в понятном или нужном нам виде/дизайне и позволила нам с этими данными работать. автоматом. пример такой GUI-системы . https://github.com/Claus1/unigui Однако это верно если данные первичны, а дизайн - вторичен.)
писал на flutter в основном для web ~ 2 года, когда он еще был то ли в бете, толи еще в чем. медленно работал в 3-4 х(чем если б на js), либы flutter в основном не подходили для web, js либы тоже не подключишь, качество кода middle-web было таким, что переделал половину элементов. криво-косо работали, вменяемый саппорт отсутствовал. плюнул и ушел на vue, когда новый dart сломал совместимость с написанными и используемыми либами. vue и web тоже не мед, но то было пыткой.
Повторяемость информации ведет к субъективному повышению ее достоверности из-за фундаментальной особенности мозга к индукции частностей. Если информацию можно верифицировать - проблемы нет, если сделать это оперативно. Если это невозможно - ставить флаг "не доказано" и не забывать этого.
твйку вон на $250 лямов развели - https://pattayapeople.ru/news/znakomstvo-v-internete-pattaya-thailand , правда, там "американский доктор".
сам нашел) https://towardsdatascience.com/pytorch-lightning-vs-pytorch-ignite-vs-fast-ai-61dc7480ad8a
долго занимаясь семантикой я понял, что математически строгое определение смысла - связь или их множество. между понятиями. описание концепта - это перечисление таких связей. подробнее здесь - https://docs.google.com/document/d/1lkqVj4YhzJAwpkphKXymOYb5KpQfoYI5-95DueRKTp0/edit?usp=sharing
Это аналог pytorch-lighting/fast.ai или есть еще какие плюшки?
не похож ни разу на hypergen. html разметки нет в принципе. только декларация данных и их ЛОГИЧЕСКАЯ группировка. "Proof of concept" было давно. рабочий инструмент для меня)
Не вижу оснований и предпосылок в корреляции случайных текстов персоны и ее характеристик в общем случае. скорее всего именно поэтому был закрыт этот "сервис". впрочем, один частный случай и правда есть: если все такие тексты написаны человеком как характеристики на самого себя по всему этому спектру характеристик. именно то, что разбиение текста "улучшает" результат, подтверждает мою мысль - нейросеть "переобучается" лучше на дробленных текстах.
В целом очень позитивно и стоит развить в религию или ветку философии. Некоторые моменты стоит еще углубить. Некоторые из них:
Из текста не следует, что процессы - Я, мысли о Я - происходяшие в материальных системах, явпяются вымышленными (ложными).
Раз это находит отражение в материальном мире - состояние нейронов + процессы, которые мы запустим или остановим - это не просто воображение и абстакция.
Утрата со временем опыта в силу неточности воспроизведения информации - фундаментальное свойство мозга, связанное с непрерывной компрессией и копированием информации. Они выработаны эволюцией так, чтобы оставаться +- той же особью со временем в критически важных аспектах.
если бы автор взял свои РАЗНЫЕ тексты на одном языке, и сравнил выдачу между собой, это бы наверняка протрезвило и опечалило).
Рабочие идеи стоят и сами по себе и зарабатывать на них можно и не сложно (см. патентный троллинг). Когда покупают пакеты патентов, средняя цена мало-мальски используемого патента минимум лимон $. ценные идеи рассказывать без патента нельзя даже патентному поверенному, если у него нет долгой и безупречной репутации. если все равно хочется - не рассказывать "секретный соус", без которого идея не заработает. и наконец, идеи для игр и правда ничего не стоят)
по запросу ALS music embedding гугел молчит. можно ссылку на метод?
>>вот здесь вам может потребоваться дополнительный инструментарий поверх HTML.
не нужно это, если протокол покрывает все нужные типы данных, и устраивает единый стиль интерфейса (MD). Если на всех экранах нужен составной элемент, делается блок, кладется в blocks папку и используется во всех экранах.
Пример:
Вверху общий блок Parameters. Описан 1 раз в blocks.
```user_edit = Edit('User ID', 1)
tape_length = Edit('Tape length', 20)
inertia = Edit('Update inertia', 0.5)
buffer_length = Edit('Buffer length', 2)
setting_block = Block('Parameters', [ user_edit,
Button("(Re)start", recalc_init, icon = "cloud_sync"), tape_length,
inertia, buffer_length], icon = "settings" )
```
можно посмотреть как это решено здесь https://github.com/Claus1/unigui . заодно узнать о протоколе.
Если я прально понял проблему - REST+JSON - много головняка, стандартов, писанины. Если закрыть более простым и менее гемморойным протоколом чем html/xml, то возможно, муры писать будем меньше. Такой протокол/решение есть - https://github.com/Claus1/unigui