Практика неточкисных ревью... Если честно, я впервые такое слышу XD. Если я на плюсах лишний раз напишу (или не напишу) auto, мне это первым же комментарием попросят исправить))
Спасибо за уточнение. Соглашусь, вы дали более корректный ответ)
Автор утверждает, что МТ - модель последовательного выполнения алгоритма; также он утверждает, что для параллельного выполнения подобной модели не существует (опять же, если верно всё понял). Если принять за истину, что детерминированная МТ является моделью в первом случае, то может ли недетерминированная являться моделью во втором? Как считаете?
Не сказал бы, что камешек) просто хочу дать понять, что прерывания - это некое дополнение. На самом деле, когда вы пишете "throw new Exception" или что-то подобное, вы пользуетесь виртуальными таблицами прерываний. Они реализованы программно. В теории, для МТ вы тоже можете их реализовать (умные люди доказали до нас, что МТ может исполнить любой алгоритм). Так что в теории ещё как может :) ведь что такое контекст? Это тоже некая абстракция. По сути таблица переходов реализует оператор goto, и этого вполне может быть достаточно
Обработка исключений в однопотоке тоже последовательная. В многопотоке - нет. Но и МТ может быть недетерминированная))
По поводу перевода программы из последовательного алгоритма в параллельный очень хороший комментарий дал Akon32 - такая оптимизация проводится на всех этапах: от компиляции до исполнения. Увы, комментарий остался без ответа, но мнение автора на этот счёт довольно интересно
По поводу темы статьи - проблемы реализации модели двух парадигм (если это можно так назвать). Ох, тут всё намешано в кучу. Машины Тьюринга/Поста ни в коем случае не являются моделями какой-либо парадигмы. Это модели непосредственно исполнителей с неограниченным ресурсом памяти и времени. Более того, это абстрактные модели НЕРЕАЛИЗУЕМЫХ на практике исполнителей. Утверждать, что это - модели, описывающаие поведение исполнителей последовательных программ, - нельзя. Кроме того, ничего общего с ПОСЛЕДОВАТЕЛЬНЫМ исполнением здесь нет. МТ - это класс машин. Есть недетерминированная, ещё более абстрактная машина Тьюринга. Она может одновременно исполнять несколько переходов, быть в более чем одном состоянии в единицу времени. Чем не модель параллелизма? Но нет, опять же, с реальным миром это не имеет ничего общего. Как хорошо, что меня в универе этому учили целый год :)
Чтобы ответить на вопрос о том, есть ли МОДЕЛЬ какого-либо процесса, предлагаю автору грамотно построить вопрос, ЧТО является моделью? Дать ей определение, прежде чем искать
Люди, утверждающие, что МТ не имеет ничего общего с реальностью из-за каких-то исключений - встречный вопрос: вы знаете про ЯП Go/Rust? Вместо тяжёлых виртуальных таблиц прерываний они используют лёгкие и предсказуемые ветвления, с лёгкостью реализующие аналогичное поведение (можно сколько угодно спорить на тему эффективности, но к теме статьи это не относится)
P.S.: ни в коем случае, не хочу никого обидеть - желаю только справедливости и хочу сам разобраться в теме. Безусловно, мог что-то неверно понять/прочитать - все мы люди. Буду очень рад читать конструктивную критику
Когда я вижу ИИ-статьи, я сразу иду читать комменты. Комментаторов такие статьи стимулируют писать очень интересные вещи, зачастую круче самой статьи, так что спасибо :)
Читаю комментарии, и думаю: а зачем, собственно, выбирать? Комбинируйте ФП и ООП. Вот вам и золотая середина
А насчёт темы статьи полностью согласен. Причём не в масштабах фреймворков, а в масштабе всех ЯП. Я очень надеюсь, что в мире программирования будет больше стандартизации. Это банально удобнее и более предсказуемо. Кроме того, любимый многими генеративный ИИ будет писать код чище и с меньшим количеством галлюцинаций
Несмотря на отсутствие предложений по решению проблемы, в данной статье действительно затрагивается довольно актуальная тема. Вспомните недавние статьи о куче вредоносных NPM пакетов. Об этом нужно говорить, и нужно предлагать пути решения. Один из вариантов - создание безопасного репозитория, в котором проверяется каждый включённый пакет. Пакеты, не включённые туда, можно будет установить на свой страх и риск. Проблема в реализации такого подхода. Понятно, что для ручной проверки ресурсов не хватит. Если кто-то будет это финансировать, возможно, проблема решится. Но во многих случаях компании просто дорабатывают существующие пакеты под свои нужды
Девелоперу-то это всё очевидно. А ревьюверу? А людям, которые будут поддерживать этот код в дальнейшем? Вы представьте, как ревьюверам тяжело - у них может быть 2 или 3 джуна, у которых они кто-то вроде наставников, и у каждого нужно проверять код. Конечно, им проще будет смотреть на алиасы!
Питон и низкое потребление ресурсов - звучит довольно смешно.
Задам 3 наводящих вопроса.
Скажите, что в этой системе больше всего потребляет ресурсов: непосредственно интерпретатор Python, PyQt5 или Vosk?
На чём написан PyQt5?
Что в проекте написано непосредственно на Python?
Надеюсь, посыл понятен.
А насчёт механизма нечёткого сравнения: отчасти согласен. При добавлении своего скрипта стоит добавить опцию отклбчения этого механизма, а также обязательно необходимо предоставить возможность создать подтверждение команды
Интересная статья, но не совсем понятен посыл. Почему я должен забывать старые паттерны, которые уже используются в проекте? Или статья - предложение написать приложение на старом фреймворке, но на новый лад? Тут скорее надо делать гайд для миграции на Vue3.
Ещё непонятен момент с Vuex/Pinia. Вы сначала говорите, что лучше использовать Vuex:
во Vue 2 лучше использовать Vuex для сложного стейта.
А затем утверждаете обратное:
Мой выбор однозначно падает на Pinia.
Постепенно внедряйте Composition API и Pinia, чтобы упростить будущий переход на Vue 3.
И в последней цитате прямо говорится про переход на Vue3, но во всей остальной статье нет других упоминаний этого
Блин, почему в одну модель пытаются уместить все знания мира? ИИ до сих пор не осознаёт значение того, что он говорит, а его уже пытаются сделать сверхразумом. В человеческом мозге есть два полушария, отвечающие за разные вещи, а люди забывают об этом. Я бы предложил обучать текущую реализацию "ИИ" на конкретных областях знаний, делая модели меньше, но эффективнее. Это снизит вероятность возникновения галлюцинаций и повысит точность.
В будущем было бы неплохо обучать модель подобно самому человеку: эмулировать настоящие переживания. Ещё можно попробовать реализовать что-то вроде оптимизации строения нейронной сети: обратное распространение ошибки, но "на уровень выше"
Автор был не очень точен в формулировке. Безусловно, он имел ввиду "неявную статическую типизацию". Не хейтите его - он понял всё верно)
Статья, не считая этого косяка, очень даже дельная: не стоит использовать var на каждом шаге. Стоит использовать либо в реально очевидных местах, либо вместо монструозных типовых конструкций, либо в сприптах. Но на самом деле сильно переживать не стоит, ведь обо всём напишут в кодостайле и выскажут на ревью :)
Ааа, мою идею реализовали)) Я тоже давно задумывался о таком агенте) вы -- молодец :) всё реализовали замечательно
У меня была идея помимо всего прочего дать модели возможность использовать "калькулятор" - можно в виде хуков наподобие [calculate]1+1[/calculate]. Также можно добавить "рекурсивные" хуки (например, [memory][calculate]1+1[/calculate][/memory]). Плюсом было бы дать возможность через те же хуки использовать поиск в интернете. Дальше можно начать подключать датчики, сигналы с которых будут в реальном времени обрабатываться, и получится растоящий киборг))
Вот насчёт языка я бы не очень согласился. В олимпиадах важна скорость решения задач и, в частности, написания самого кода. Если в C++ довольно легко ошибиться, то в python больше вероятности написать верный код с первого раза. За время выполнения программы не дают бонусов почти нигде (если ничего не поменялось, конечно, я 2-3 года назад активно участвовал). Обычно делают так: если алгоритм может отработать менее чем за 30 секунд на бОльшем объёме данных, чем в стандартном условии, то дают +балл. А это зависит уже от реализации. Если вы напишите алгоритм сложностью O(n^4), то пишите на чём угодно - доп.балл не дадут :(
Поэтому я бы советовал напротив - выбирать язык, который лично вам даётся проще, и на котором пишется быстрее и без ошибок
Не сдавайтесь! Я всё ещё верю, что вы продолжите писать :)
Практика неточкисных ревью... Если честно, я впервые такое слышу XD. Если я на плюсах лишний раз напишу (или не напишу) auto, мне это первым же комментарием попросят исправить))
Спасибо за уточнение. Соглашусь, вы дали более корректный ответ)
Автор утверждает, что МТ - модель последовательного выполнения алгоритма; также он утверждает, что для параллельного выполнения подобной модели не существует (опять же, если верно всё понял). Если принять за истину, что детерминированная МТ является моделью в первом случае, то может ли недетерминированная являться моделью во втором? Как считаете?
Не сказал бы, что камешек) просто хочу дать понять, что прерывания - это некое дополнение. На самом деле, когда вы пишете "throw new Exception" или что-то подобное, вы пользуетесь виртуальными таблицами прерываний. Они реализованы программно. В теории, для МТ вы тоже можете их реализовать (умные люди доказали до нас, что МТ может исполнить любой алгоритм). Так что в теории ещё как может :) ведь что такое контекст? Это тоже некая абстракция. По сути таблица переходов реализует оператор goto, и этого вполне может быть достаточно
Обработка исключений в однопотоке тоже последовательная. В многопотоке - нет. Но и МТ может быть недетерминированная))
По поводу перевода программы из последовательного алгоритма в параллельный очень хороший комментарий дал Akon32 - такая оптимизация проводится на всех этапах: от компиляции до исполнения. Увы, комментарий остался без ответа, но мнение автора на этот счёт довольно интересно
По поводу темы статьи - проблемы реализации модели двух парадигм (если это можно так назвать). Ох, тут всё намешано в кучу. Машины Тьюринга/Поста ни в коем случае не являются моделями какой-либо парадигмы. Это модели непосредственно исполнителей с неограниченным ресурсом памяти и времени. Более того, это абстрактные модели НЕРЕАЛИЗУЕМЫХ на практике исполнителей. Утверждать, что это - модели, описывающаие поведение исполнителей последовательных программ, - нельзя. Кроме того, ничего общего с ПОСЛЕДОВАТЕЛЬНЫМ исполнением здесь нет. МТ - это класс машин. Есть недетерминированная, ещё более абстрактная машина Тьюринга. Она может одновременно исполнять несколько переходов, быть в более чем одном состоянии в единицу времени. Чем не модель параллелизма? Но нет, опять же, с реальным миром это не имеет ничего общего. Как хорошо, что меня в универе этому учили целый год :)
Чтобы ответить на вопрос о том, есть ли МОДЕЛЬ какого-либо процесса, предлагаю автору грамотно построить вопрос, ЧТО является моделью? Дать ей определение, прежде чем искать
Люди, утверждающие, что МТ не имеет ничего общего с реальностью из-за каких-то исключений - встречный вопрос: вы знаете про ЯП Go/Rust? Вместо тяжёлых виртуальных таблиц прерываний они используют лёгкие и предсказуемые ветвления, с лёгкостью реализующие аналогичное поведение (можно сколько угодно спорить на тему эффективности, но к теме статьи это не относится)
P.S.: ни в коем случае, не хочу никого обидеть - желаю только справедливости и хочу сам разобраться в теме. Безусловно, мог что-то неверно понять/прочитать - все мы люди. Буду очень рад читать конструктивную критику
Когда я вижу ИИ-статьи, я сразу иду читать комменты. Комментаторов такие статьи стимулируют писать очень интересные вещи, зачастую круче самой статьи, так что спасибо :)
Если приходится выбирать между двумя крайностями, я выбираю увольнение)))
Читаю комментарии, и думаю: а зачем, собственно, выбирать? Комбинируйте ФП и ООП. Вот вам и золотая середина
А насчёт темы статьи полностью согласен. Причём не в масштабах фреймворков, а в масштабе всех ЯП. Я очень надеюсь, что в мире программирования будет больше стандартизации. Это банально удобнее и более предсказуемо. Кроме того, любимый многими генеративный ИИ будет писать код чище и с меньшим количеством галлюцинаций
Несмотря на отсутствие предложений по решению проблемы, в данной статье действительно затрагивается довольно актуальная тема. Вспомните недавние статьи о куче вредоносных NPM пакетов. Об этом нужно говорить, и нужно предлагать пути решения. Один из вариантов - создание безопасного репозитория, в котором проверяется каждый включённый пакет. Пакеты, не включённые туда, можно будет установить на свой страх и риск. Проблема в реализации такого подхода. Понятно, что для ручной проверки ресурсов не хватит. Если кто-то будет это финансировать, возможно, проблема решится. Но во многих случаях компании просто дорабатывают существующие пакеты под свои нужды
Девелоперу-то это всё очевидно. А ревьюверу? А людям, которые будут поддерживать этот код в дальнейшем? Вы представьте, как ревьюверам тяжело - у них может быть 2 или 3 джуна, у которых они кто-то вроде наставников, и у каждого нужно проверять код. Конечно, им проще будет смотреть на алиасы!
Вам-то это всё очевидно. А представьте, что вы отдаёте сво
Задам 3 наводящих вопроса.
Скажите, что в этой системе больше всего потребляет ресурсов: непосредственно интерпретатор Python, PyQt5 или Vosk?
На чём написан PyQt5?
Что в проекте написано непосредственно на Python?
Надеюсь, посыл понятен.
А насчёт механизма нечёткого сравнения: отчасти согласен. При добавлении своего скрипта стоит добавить опцию отклбчения этого механизма, а также обязательно необходимо предоставить возможность создать подтверждение команды
Интересная статья, но не совсем понятен посыл. Почему я должен забывать старые паттерны, которые уже используются в проекте? Или статья - предложение написать приложение на старом фреймворке, но на новый лад? Тут скорее надо делать гайд для миграции на Vue3.
Ещё непонятен момент с Vuex/Pinia. Вы сначала говорите, что лучше использовать Vuex:
А затем утверждаете обратное:
И в последней цитате прямо говорится про переход на Vue3, но во всей остальной статье нет других упоминаний этого
Блин, почему в одну модель пытаются уместить все знания мира? ИИ до сих пор не осознаёт значение того, что он говорит, а его уже пытаются сделать сверхразумом. В человеческом мозге есть два полушария, отвечающие за разные вещи, а люди забывают об этом. Я бы предложил обучать текущую реализацию "ИИ" на конкретных областях знаний, делая модели меньше, но эффективнее. Это снизит вероятность возникновения галлюцинаций и повысит точность.
В будущем было бы неплохо обучать модель подобно самому человеку: эмулировать настоящие переживания. Ещё можно попробовать реализовать что-то вроде оптимизации строения нейронной сети: обратное распространение ошибки, но "на уровень выше"
Статья супер! Но насколько я знаю, EFLAGS 32-битный регистр. FLAGS, расширением над которым и является EFLAGS, как раз таки 16-битный
Дорогие комментаторы
Автор был не очень точен в формулировке. Безусловно, он имел ввиду "неявную статическую типизацию". Не хейтите его - он понял всё верно)
Статья, не считая этого косяка, очень даже дельная: не стоит использовать var на каждом шаге. Стоит использовать либо в реально очевидных местах, либо вместо монструозных типовых конструкций, либо в сприптах. Но на самом деле сильно переживать не стоит, ведь обо всём напишут в кодостайле и выскажут на ревью :)
Ааа, мою идею реализовали)) Я тоже давно задумывался о таком агенте) вы -- молодец :) всё реализовали замечательно
У меня была идея помимо всего прочего дать модели возможность использовать "калькулятор" - можно в виде хуков наподобие [calculate]1+1[/calculate]. Также можно добавить "рекурсивные" хуки (например, [memory][calculate]1+1[/calculate][/memory]). Плюсом было бы дать возможность через те же хуки использовать поиск в интернете. Дальше можно начать подключать датчики, сигналы с которых будут в реальном времени обрабатываться, и получится растоящий киборг))
Индусеть
Главное, чтобы Петя не увидел этот пост, а то он осознает свою ценность и будет отлынивать от своей главной задачи))
Спасибо, статья очень информативная)
Вот насчёт языка я бы не очень согласился. В олимпиадах важна скорость решения задач и, в частности, написания самого кода. Если в C++ довольно легко ошибиться, то в python больше вероятности написать верный код с первого раза. За время выполнения программы не дают бонусов почти нигде (если ничего не поменялось, конечно, я 2-3 года назад активно участвовал). Обычно делают так: если алгоритм может отработать менее чем за 30 секунд на бОльшем объёме данных, чем в стандартном условии, то дают +балл. А это зависит уже от реализации. Если вы напишите алгоритм сложностью O(n^4), то пишите на чём угодно - доп.балл не дадут :(
Поэтому я бы советовал напротив - выбирать язык, который лично вам даётся проще, и на котором пишется быстрее и без ошибок