умеют только в то, что видели в обучающем наборе данных, а в то, что не видели, они не умеют
имхо и человек тоже умеет только то что видел. В математику мы умеем, потому что видим как работает природа: она вычисляет свои вещи по своим правилам, а мы обкладываем это своими абстракциями (математикой). Искусственные нейросети тоже видят датасет и формируют свои абстракции.
Хорошие (на мой взгляд) вопросы: как соотносятся датасеты, потребляемые человеком и искусственными сетями? в чем их отличие и важно ли оно для углубления абстракций.. может быть математика будет лучше прорастать когда тебе на голову падают яблоки?
Спасибо! Да, похоже на Mermaid или на PlantUML (вдохновлялся PlantUML).
Попытался сделать улучшение опыта в части написания/чтения самой разметки, а для синтаксиса сделал простенький редактор, он предоставляет подсветку и контекстную подсказку с автодополнением.
Ну то есть работает как везде: начинаем писать - под курсором появляется менюшка в которой выбраны варианты, подходящие с точки зрения ожидаемых типов токенов (например, если пишем имя атрибута для тэга "событие", то будут предложены все допустимые имена атрибутов этого тэга). Мы можем дописать руками или выбрать вариант и нажать "Tab" - произойдет автодополнение.
Выглядит так:
Если же вы предполагаете формировать текстовый файл на основании формочек, как в примере с 1С, то формат может быть лучше сделать более машиночитаемым, например JSON.
Пока что разметка сохраненных схем и формочек хранится и в JSON и "сырым" введенным текстом, но сам текст из формочек не генерируется, только из ручного ввода (как дойдут руки, планирую добавить чтобы генерировался). Выше в статье рисовал схемку, см. ниже: то что пунктиром - не работает. То есть если пользователь сделал форму руками в граф редакторе то текстового описания на нее не будет, только JSON, а если сгенерировал по текстовому описанию, то будет сохранено и оно и JSON.
По использованию массивов вместо именованных объектов размышлял (в комменте выше писал об этом), мне показалось что писать ямл с таким допущением сложнее, чем разметку из примера, и читать, в свою очередь, тоже сложнее, потому что она занимает больше места по вертикали и мозгу нужно как то интерпретировать черточки и отступы. Плюс еще есть аргумент, которые писал выше про указание типов объектов (задача/событие/шлюз и т.п.) в свойствах сущностей а не в тэгах, как в xml.
Ну то есть вместо
процесс
задача .атрибут1 значение .атрибут2 значение
событие .атрибут1 значение .атрибут2 значение
нужно будет написать
процесс:
- тип: задача
атрибут1: значение
атрибут2: значение
- тип: событие
атрибут1: значение
атрибут2: значение
Однако, вероятно, я не прав. Записал себе на развитие все таки сделать ямл.
По велосипедам - каюсь, грешен. Даже в названии статьи попытался обыграть "yet another" :) Мне действительно показалось что есть какие то улучшения, поэтому сделано то что сделано.
Пытался в этом направлении думать, остановился на таких доводах (могу быть не прав, такое часто случается, поправьте меня пожалуйста):
Тип объекта в случае xml указывается в имени тэга, а в случае json или yaml нужно выносить его отдельный атрибут + имя объекта не уникально в пределах одного уровня вложенности. В совокупности это мне показалось не интуитивным, в том числе с точки зрения реализации набора с автодополнением. Ну то есть, если первое слово в строке это указание на тип, то в тот момент, когда система ожидает ввод типа мы просто предлагаем пользователю выбрать нужное имя и оно же печатается в редактор. А если тип указывается как атрибут, то возникают вопросы по дизайну (в связке с эргономикой) - не смог их решить.
Разделители для атрибутов в yaml это переносы строк => визуально сложно читать (ориентировался исключительно на свои ощущения). Ниже запись в ямл-подобном синтаксисе с игнорированием требования к уникальности имени объекта (вопрос с неуникальностью можно решить добавлением "-", то есть использованием неименованных списков, не стал записывать). Возможно, у меня просто нет глубоких знаний о фичах ямл, исходил из того что описание на нем будет выглядеть примерно так (ниже такое же описание как в примере в статье, для демонстрации читаемости):
процесс:
имя: Примерный процесс
дорожки: роль пользователя
событие:
расположение: начальное
задача:
текст: начать делать процесс
тип: ручная
событие:
тип: условие
текст: я устал
расположение: промежуточное
шлюз:
тип: эксклюзивный
ветка:
текст: да
задача:
текст: вызвать подмогу
тип: пользователь
событие:
прерывающее: нет
расположение: промежуточное
генерирующее: да
тип: сигнал
текст: включена система оповещения
задача:
тип: сервисная
текст: запустить протокол психологической помощи
событие:
тип: время
текст: получены цйенные указания
ветка:
текст: нет
задача:
тип: ручная
текст: продолжать трудиться
событие:
тип: время
расположение: промежуточное
задача:
тип: пользователь
текст: отчитаться о выполненной работе
событие:
расположение: завершающее
Понимаю что плохой аргумент, но в рамках каприза: двоеточие в русской раскладке нужно набирать через shift.
Про фатальный недостаток, допускаю что он есть, можете подсветить пож-та?
Отличная идея!
Вот только бы не стать очередной жертвой маржинального пользователя
Предлагаю пытливому читателю такое упражнение: заменям по тексту "1С" на "SAP" , переводим на английский и перечитываем
имхо и человек тоже умеет только то что видел. В математику мы умеем, потому что видим как работает природа: она вычисляет свои вещи по своим правилам, а мы обкладываем это своими абстракциями (математикой). Искусственные нейросети тоже видят датасет и формируют свои абстракции.
Хорошие (на мой взгляд) вопросы: как соотносятся датасеты, потребляемые человеком и искусственными сетями? в чем их отличие и важно ли оно для углубления абстракций.. может быть математика будет лучше прорастать когда тебе на голову падают яблоки?
Спасибо! Да, похоже на Mermaid или на PlantUML (вдохновлялся PlantUML).
Попытался сделать улучшение опыта в части написания/чтения самой разметки, а для синтаксиса сделал простенький редактор, он предоставляет подсветку и контекстную подсказку с автодополнением.
Ну то есть работает как везде: начинаем писать - под курсором появляется менюшка в которой выбраны варианты, подходящие с точки зрения ожидаемых типов токенов (например, если пишем имя атрибута для тэга "событие", то будут предложены все допустимые имена атрибутов этого тэга). Мы можем дописать руками или выбрать вариант и нажать "Tab" - произойдет автодополнение.
Выглядит так:
Пока что разметка сохраненных схем и формочек хранится и в JSON и "сырым" введенным текстом, но сам текст из формочек не генерируется, только из ручного ввода (как дойдут руки, планирую добавить чтобы генерировался). Выше в статье рисовал схемку, см. ниже: то что пунктиром - не работает. То есть если пользователь сделал форму руками в граф редакторе то текстового описания на нее не будет, только JSON, а если сгенерировал по текстовому описанию, то будет сохранено и оно и JSON.
Да, спасибо за замечание.
По использованию массивов вместо именованных объектов размышлял (в комменте выше писал об этом), мне показалось что писать ямл с таким допущением сложнее, чем разметку из примера, и читать, в свою очередь, тоже сложнее, потому что она занимает больше места по вертикали и мозгу нужно как то интерпретировать черточки и отступы. Плюс еще есть аргумент, которые писал выше про указание типов объектов (задача/событие/шлюз и т.п.) в свойствах сущностей а не в тэгах, как в xml.
Ну то есть вместо
нужно будет написать
Однако, вероятно, я не прав. Записал себе на развитие все таки сделать ямл.
По велосипедам - каюсь, грешен. Даже в названии статьи попытался обыграть "yet another" :) Мне действительно показалось что есть какие то улучшения, поэтому сделано то что сделано.
Пытался в этом направлении думать, остановился на таких доводах (могу быть не прав, такое часто случается, поправьте меня пожалуйста):
Тип объекта в случае xml указывается в имени тэга, а в случае json или yaml нужно выносить его отдельный атрибут + имя объекта не уникально в пределах одного уровня вложенности. В совокупности это мне показалось не интуитивным, в том числе с точки зрения реализации набора с автодополнением. Ну то есть, если первое слово в строке это указание на тип, то в тот момент, когда система ожидает ввод типа мы просто предлагаем пользователю выбрать нужное имя и оно же печатается в редактор. А если тип указывается как атрибут, то возникают вопросы по дизайну (в связке с эргономикой) - не смог их решить.
Разделители для атрибутов в yaml это переносы строк => визуально сложно читать (ориентировался исключительно на свои ощущения). Ниже запись в ямл-подобном синтаксисе с игнорированием требования к уникальности имени объекта (вопрос с неуникальностью можно решить добавлением "-", то есть использованием неименованных списков, не стал записывать). Возможно, у меня просто нет глубоких знаний о фичах ямл, исходил из того что описание на нем будет выглядеть примерно так (ниже такое же описание как в примере в статье, для демонстрации читаемости):
Понимаю что плохой аргумент, но в рамках каприза: двоеточие в русской раскладке нужно набирать через shift.
Про фатальный недостаток, допускаю что он есть, можете подсветить пож-та?