В контексте задачи изменения промпта --- source кажется более удобным. Посмотреть на результат сразу. Не говоря уже о том, что $PATH не в .bashrcопределяется.
А, может, здесь глубокая мысль о том, что закончатся простые, которые реально проверить на простоту ;) Ну т.е. условно сложность проверки растет быстрее, чем растет вычислительная мощность. Шутка, конечно ;) А вообще плотность простых же как обратный логарифм в пределе, так что определенная логика в этом есть , наверное.
За остальное не скажу, но пользуюсь клавиатурой (от бренда с не очень хорошей репутацией) именно с BT подключением, т.к. два порта USB всего. Проблем пока не наблюдаю.
Это имеется в виду, при максимальной нагрузке ? Просто, если это вообще максимальная скорость вращения вала, то это вроде не так, потому что вы же не всегда силу такую прикладываете. Голый вал если, то нужно момент инерции вала смотреть. Или я не прав ?
Спасибо за статью, и можно меня в маглы записать, но ...
Прошу прощения за сырые мысли, но интересно услышать мнение.
> Полное соответствие с ТЗ,
и
> Есть обработка ошибок связанных с запросами или повреждёнными изображениями хотя об этом даже не говорилось в ТЗ.
Я понимаю, что тут как бы не противоречие, но на мой взгляд, это не фича, а баг. Ибо, откуда он знает, как я хочу обрабатывать ошибки.
Далее,
> нет багов
Как вы это поняли ? Как мы, например, понимаем, что предложенное решение оптимально и не содержит утечек памяти, UB, квадратов при переборе, и т.д. ? Читаем код ?
Я всегда думаю о двух проблемах относительно сгенерированного кода:
a) Поддержка этого кода б) Валидация этого кода
Здесь я говорю о коде, созданном моделью, а не, например, фреймворками GUI (в котором, скорее всего, тоже есть проблема с поддержкой).
Мне интересно какое будущее вам видится в связи с проблемой б). Мои мысли следующие:
z) Валидация кода людьми вообще отсутствует. Выводы о корректности программы делаются на основе тестов выходных данных для данной задачи, например (опять же -- кто написал тесты). Т.е. модель тестируется "косвенно" -- через систематическую проверку результата.
y) (Маловероятно) Модель валидируется как целое, а частные результаты: код, рецепты, инструкции -- не проверяются. По сути, некоторый аналог диплома, если можно так выразиться :)
x) Валидация кода осуществляется так же моделью (возможно, другой). Тогда как оценить корректность работы последней ?
w) Мы признаём, что в какой-то момент мы вынуждены отпустить развитие ИИ, т.к. он достигает уровня, непостижимого человечеством, и становимся техно-шаманами, принимающими результаты ИИ на веру.
Я, конечно, понимаю, что уже сейчас мы часто не проверяем "уровень ниже" -- например, я не готов поручиться за корректность gcc но я знаю, что эта штука детерминирована. Я знаю (верю?), что люди, которые пишут gcc ,понимают каждый шаг, каждую строчку кода. Более того, при сильном желании, я сам могу убедиться в корректности.
Наверное, ещё более сложно дело обстоит с лекарствами. Я думаю, невозможно точно предсказать, как вещество будет действовать на организм. Но, подозреваю, что тратятся огромные ресурсы на исследования. Может, что-то подобное будет и с ИИ-решениями.
В общем, главный вопрос: можем ли мы действительно положиться на ИИ-решения без участия программиста, который будет читать и валидировать, и изменять при необходимости, предоставленный код ?
Интернеты говорят, что вы не правы. В плане, что везде написано практически то же самое, что в статье. Я не эксперт, но предполагаю, что это часть требований именно к аппаратной части по реализации транзакции.
Во-первых, спасибо за символьное описание. Намного меньше вопросов вызывает. Во-вторых, солидарен с таким подходом - тут сразу руки чешутся рекурсию написать. В-третьих, NIT, я бы квантор всеобщности местами убрал.
Ну и P.S. в языках без хвостовой рекурсии, корутин и т.д. придется в цикл всё переводить. Но рассуждать и строить решения в рамках рекурсии, а потом переводить в цикл, мне кажется, проще в таких задачах.
Честное слово -- не хочу обидеть, но Вы про эти кислотные цвета и градиентные заливки ? Если Вы про скрины в Ваших статьях, то это ужасно просто. Я не вникал в Ваши статьи, но предполагаю, что визуальная составляющая в них не главное. Ещё раз -- без негатива, личное мнение.
Должен был привести все ты.
А, не так понял предложенную альтернативу --- подумал, что имеется в виду новый терминал. Пардон, оступился.
UPD. Но так каждый раз множить инстансы после каждого изменения --- тоже не совсем чисто ИМХО.
В контексте задачи изменения промпта ---
sourceкажется более удобным. Посмотреть на результат сразу. Не говоря уже о том, что$PATHне в.bashrcопределяется.В английском языке местоимение I всегда заглавная. Может, сдвижка в голове.
А, может, здесь глубокая мысль о том, что закончатся простые, которые реально проверить на простоту ;) Ну т.е. условно сложность проверки растет быстрее, чем растет вычислительная мощность. Шутка, конечно ;) А вообще плотность простых же как обратный логарифм в пределе, так что определенная логика в этом есть , наверное.
Спасибо за статью. У меня вопрос, который частично пересекается с веткой https://habr.com/ru/articles/665276/#comment_24344226
Подходит ли ECS для реализации UI, HUD в игре ?
За остальное не скажу, но пользуюсь клавиатурой (от бренда с не очень хорошей репутацией) именно с BT подключением, т.к. два порта USB всего. Проблем пока не наблюдаю.
Это имеется в виду, при максимальной нагрузке ? Просто, если это вообще максимальная скорость вращения вала, то это вроде не так, потому что вы же не всегда силу такую прикладываете. Голый вал если, то нужно момент инерции вала смотреть. Или я не прав ?
Спасибо за статью, и можно меня в маглы записать, но ...
Прошу прощения за сырые мысли, но интересно услышать мнение.
> Полное соответствие с ТЗ,
и
> Есть обработка ошибок связанных с запросами или повреждёнными изображениями хотя об этом даже не говорилось в ТЗ.
Я понимаю, что тут как бы не противоречие, но на мой взгляд, это не фича, а баг. Ибо, откуда он знает, как я хочу обрабатывать ошибки.
Далее,
> нет багов
Как вы это поняли ? Как мы, например, понимаем, что предложенное решение оптимально и не содержит утечек памяти, UB, квадратов при переборе, и т.д. ? Читаем код ?
Я всегда думаю о двух проблемах относительно сгенерированного кода:
a) Поддержка этого кода
б) Валидация этого кода
Здесь я говорю о коде, созданном моделью, а не, например, фреймворками GUI (в котором, скорее всего, тоже есть проблема с поддержкой).
Мне интересно какое будущее вам видится в связи с проблемой б). Мои мысли следующие:
z) Валидация кода людьми вообще отсутствует. Выводы о корректности программы делаются на основе тестов выходных данных для данной задачи, например (опять же -- кто написал тесты). Т.е. модель тестируется "косвенно" -- через систематическую проверку результата.
y) (Маловероятно) Модель валидируется как целое, а частные результаты: код, рецепты, инструкции -- не проверяются. По сути, некоторый аналог диплома, если можно так выразиться :)
x) Валидация кода осуществляется так же моделью (возможно, другой). Тогда как оценить корректность работы последней ?
w) Мы признаём, что в какой-то момент мы вынуждены отпустить развитие ИИ, т.к. он достигает уровня, непостижимого человечеством, и становимся техно-шаманами, принимающими результаты ИИ на веру.
Я, конечно, понимаю, что уже сейчас мы часто не проверяем "уровень ниже" -- например, я не готов поручиться за корректность
gccно я знаю, что эта штука детерминирована. Я знаю (верю?), что люди, которые пишутgcc,понимают каждый шаг, каждую строчку кода. Более того, при сильном желании, я сам могу убедиться в корректности.Наверное, ещё более сложно дело обстоит с лекарствами. Я думаю, невозможно точно предсказать, как вещество будет действовать на организм. Но, подозреваю, что тратятся огромные ресурсы на исследования. Может, что-то подобное будет и с ИИ-решениями.
В общем, главный вопрос: можем ли мы действительно положиться на ИИ-решения без участия программиста, который будет читать и валидировать, и изменять при необходимости, предоставленный код ?
Интернеты говорят, что вы не правы. В плане, что везде написано практически то же самое, что в статье. Я не эксперт, но предполагаю, что это часть требований именно к аппаратной части по реализации транзакции.
Опечатка ?
Абсолютно верно. Т.е. если больше нет чисел, чтобы дать квадрат, то заканчивается последовательность на этом.
Не понятно или не видно ?
Во-первых, спасибо за символьное описание. Намного меньше вопросов вызывает. Во-вторых, солидарен с таким подходом - тут сразу руки чешутся рекурсию написать. В-третьих, NIT, я бы квантор всеобщности местами убрал.
Ну и P.S. в языках без хвостовой рекурсии, корутин и т.д. придется в цикл всё переводить. Но рассуждать и строить решения в рамках рекурсии, а потом переводить в цикл, мне кажется, проще в таких задачах.
ttkbootstrap
Ну и matplotlib я соответственно настроил цвета.
Принял.
Честное слово -- не хочу обидеть, но Вы про эти кислотные цвета и градиентные заливки ? Если Вы про скрины в Ваших статьях, то это ужасно просто. Я не вникал в Ваши статьи, но предполагаю, что визуальная составляющая в них не главное. Ещё раз -- без негатива, личное мнение.
Посмотри тут: тут
Сейчас пишу систему мониторинга температуры. Только это tkinter :