Для текста вроде мессенджеров вагон и тележка, нетривиально как раз аудио/видео.
Signal определённо работает (по крайней мере у четырёх разных стационарных операторов, ожидаю что и у мобильных). Jami вроде работает, нужно больше тестов.
Подразумеваемая полная форма этой фразы "все разумные люди же понимают... [а если вы не, то вы сами расписались что вы не разумный человек и вас можно игнорировать]".
Я непосредственно смотрел для 2-НДФЛ, но сильно ожидаю что с трудовой то же самое: вы можете получить PDF с приложенным отдельно файлом подписи .p7s. После чего его надо проверить. Adobe Acrobat этого, судя по всему, "из коробки" не умеет (может, можно научить). openssl умеет (openssl smime -verify -in doc_name_PDF.p7s -inform DER -content doc_name.pdf), только для этого а) HR должен уметь этим пользоваться и б) нужно добавить поддержку ГОСТ, ибо из дистрибутива по умолчанию её сколько-то лет назад выкинули.
Моё замечание к словоупотреблению: "противодействие" скорее подразумевает что вот было равновесие, было воздействие в сторону от этого равновесия, и как результат возникла сила, тянущая обратно (cf. "принцип Ле Шателье").
То что мы имеем - это парный процесс, обе компоненты которого уводят из окрестности существовавшего решения, сваливаясь к какому-то другому равновесию.
Я не оспариваю что он закономерный, но, возвращаясь к изначальному пойнту, то что действия людей согласованы с объективной структурой предъявленных им стимулов - не мешает мне субъективно считать их неправыми, и я не вижу в этих двух суждениях противоречия.
There’s a narrative I find kind of troubling, but that unfortunately seems to be growing more common in science. The core idea is that the mere existence of perverse incentives is a valid and sufficient reason to knowingly behave in an antisocial way, just as long as one first acknowledges the existence of those perverse incentives.
Я бы не использовал слова "противодействие" для таких мероприятий - оба усилия направлены на ухудшение ситуации по моей шкале. Eye for an eye leaves the world blind и всё такое.
Значит, оно должно возвращать не double, а что-то в духе Meters или Unit<Meters, double>.
В принципе справедливо, и я предпочёл бы находиться в мире, где это так, но а) плохо применимо когда уже есть уйма кода с double, включая C-интерфейсы нескольких разных библиотек; б) я взял простой и компактный случай как иллюстрацию, можно взять менее компактный где система типов всё равно не поможет выразить смысл (ну, или описание типа будет чрезмерно громоздким).
Length переименовываем в ComputeLength, и затратность уже понятна по имени.
Не согласен. Вы решили одну проблему, но создали другую: теперь у объекта нет просто метода Length(), который в 90% случаев можно и нужно использовать как простой аксессор. Оговорка сделана оговоркой для оставшихся 10%.
А вообще что такое «затратный вызов»?
Компактное утверждение "этот вызов может занять больше времени чем кажется (если вы не понимаете, сколько и почему, спросите у автора кода или изучите и поймите реализацию, полный и точный ответ слишком длинный для этого комментария)".
И, кстати, в LengthUnits такого комментария нет. Я так понимаю, оно не затратное? Или забыли написать?
Ну вот. Можно, конечно, написать больше комментариев чтобы прояснить и это (в данном случае оно более быстрое - затем и нужно, - но возлагает на клиента обязанность думать, как правильно обойтись с результатом).
Ничего не понял. Где этот случай торчит в API?
У данного типа - нигде (и нет, его индикатор в данном классе не является уместным), отсюда и предупреждение. Я расшифровываю "не понял" как "комментариев всё ещё недостаточно" (в данном случае недостающая часть отчасти покрывается комментарием к самому типу, а отчасти ожидается в голове программиста, как часть знания предметной области).
В плюсах лучше возвращать std::variant<Meters, ProjUnits>, например, и комментарий снова не нужен
Не очевидно что лучше. Потому что объектов прорва, а опция variant у них будет одна и та же. Её можно понять заранее во внешнем коде. (И это нелокальное условие, которое я не знаю как выразить типами.)
Вообще, кажется, заметная часть моего убеждения что комментарии нужны - что в проекте существуют нелокальные условия, которые влияют на локальные решения, поэтому их приходится выражать (напоминать) текстом. На это можно возразить, что одна из задач архитектора - превратить нелокальные условия в локальные. Но я сомневаюсь что даже в идеальном случае в сколько-нибудь сложной задаче это можно сделать на 100%.
Комментарии могут размечать логические блоки в пределах функции (а вынести их в отдельные именованные функции может быть плохой идеей из-за большого количества совместно используемых переменных). Более того, один из способов дизайна методов - вначале записать комментариями предполагаемую логику работы, а затем реализующий её код (приём взят из "Совершенного кода" Макконнелла).
Комментарии к публичным интерфейсам полезны, потому что передают семантику использования и неочевидные ограничения, которые затруднительно заложить в имена:
class GeoLine {
public:
//! \brief возвращает длину линии в _метрах_, потенциально затратный вызов
//! \warning в случае местной системы координат длина будет в единицах проекции
double Length(void) const;
//! \brief возвращает длину линии в _единицах проекции_
double LengthUnits(void) const;
}
Или содержат примеры использования:
// \example LOG_TIME(Info) foo(); //выведет в лог время выполнения foo()
#define LOG_TIME(Lv) if(log::impl::timer<Lv> t; t)
Комментарии могут содержать напоминания - знание, которое надо не забыть учесть при изменении кода (даже если прямо сейчас это знание не порождает какого-то решения, про которое надо объяснять "почему"):
int foo(double* xBegin, double* xEnd, const double* yBegin){
// yBegin имеет право совпадать с xBegin
//...
}
Наконец, исключение "чтобы объяснить почему сделано именно так, а не иначе" - очень резиновое. Ведь такие объяснения возможны в любой сколько-то нетривиальной функции:
/// Какой из этих трёх комментариев здесь уместнее? Или никакой?
// определяем, с какой стороны луча находится точка
// подставляем точку в уравнение прямой
// наша прямая aX+bY+c=0, подстановка (p.x,p.y) даёт знаковое расстояние
double dist = a*p.x + b*p.y + c;
if(dist > 0) { //справа по направлению обхода
//...
} else {
//...
}
Мне кажется, или это универсальная претензия к принятию решений в условиях существенной неопределённости? Если туристическая группа пошла маршрутом, который из их исходных знаний ожидался более безопасным, попала под лавину и погибла - ни им ни их родственникам тоже "не легче".
Прагматически, решения всё равно надо принимать, и я считаю, что их качество в среднем всё ещё важно. Эмоционально, я хочу знать. Не "чтобы было легче", а потому что мне любопытно.
Эмоционально этот подход мне близок, но есть другая перспектива: я хочу иметь в голове модель, которая для действия X предсказывает, насколько вероятны те или иные исходы. Т.е. для Q = P("меня посадят" | do("я зашёл в Facebook")) - P("меня посадят" | ~do("я зашёл в Facebook")) может хотеться знать не просто категорическое Q>ε, а количественную оценку Q.
И вообще ИИ больше, чем в него загрузишь, не напишет (если не считать тонны воды).
LLM неявно содержит довольно много "усреднённых" знаний, поэтому даёт хорошую аппроксимацию "отстранённого взгляда" ("outside view"). Я вот недавно попробовал использовать её для оценки сроков задач, и пока что post factum точность оценок очень приличная.
А я знаю? Сидишь себе, никого не трогаешь, тут бац, какой-нибудь find_package(ZLIB REQUIRED) говорит "пошёл нахрен". Или случается The CXX compiler identification is unknown. Или просто настраиваешь какой-нибудь инструмент в первый раз, типа "хочу кросс-компилированный под ARM Go, использующий вот этот C-код".
И во всех этих случаях начинаешь с самого простого: пусть у меня соберётся программа, которая использует все релевантные технологии самым примитивным образом из возможных - напишет в консоль "привет", нарисует чайник, мигнёт одним светодиодом. В этом смысл Hello, world-программ: доказать, что у целевой системы можно вызвать какое-то поведение перед тем как пытаться вызывать сложное.
Hello world пишется столько раз, сколько надо проверить что система сборки как таковая не объявила забастовку и не сошла с ума. Завидую людям у которых это число раз равно 1.
Это объясняется банально - мы не можем чисто физически поглотить столько еды и с таким её разнообразием, что бы восполнить все витамины, мы не сможем всё нужное поглотить даже в течение недели или месяца.
Нужное для чего? Потому что если вы говорите о дозах с обычной пищей в принципе недоступных, то вы заведомо выходите за рамки медицинской нормы. Патологические дефициты витаминов (авитаминозы) известны и редки.
Если вы задаёте некоторый уровень "нужного", который определяется не патологиями, а анализами, то не худо бы хотя бы озвучить, какие плохие последствия вы ожидаете от меньшего уровня.
Есть какие-то конкретные соображения почему InvokeAI, а не Automatic1111 или ComfyUI? (Я открывал статью как раз с надеждой что в ней будет актуальное сравнение систем этого рода, а то сейчас грустно пытаюсь пропатчить sd-webui-SAG до работающего состояния. В статье нет, но может есть у комментаторов?)
А производителю, напротив выгодно будет ждать когда кто то разработает и взять после отзыва патента.
Работает только если все производители солидарно не используют полезный патент в течение specific timeframe. Это не выглядит как равновесие Нэша для независимых агентов.
1) Люди обучаются ещё и об реальность: действуют в мире с некоторыми ожиданиями, получают неожиданные результаты, корректируют (как минимум понижают в приоритете) часть ментальных моделей, "ответственную" за ожидание. У LLM такого механизма сейчас нет.
2) Обучение людей и процесс под названием "обучение", применяемый к LLM - это разные процессы. То что у первого есть условно устойчивые траектории не означает что они обязаны быть у второго.
3) Люди двигают науку за счёт обновления корпуса текстов между поколениями - не только включения, но и исключения ("новая теория становится мейнстримом, когда вымирают последователи старой"). При обучении LLM активного исключения текстов не происходит.
Моё примерное понимание - что у людей есть "естественная" продолжительность дня.
Жаворонки - те у кого она заметно меньше 24 часов (что коррелирует с более возбудимой психикой). Они просыпаются хорошо выспавшимися, легко начинают работать, но к вечеру уже ресурс заканчивается и ничем сложным не хочется заниматься.
Совы - у кого она заметно больше 24 часов, коррелирует с более инертной психикой. Утро настаёт слишком рано, подгрузка brain.exe медленная, какого чёрта все вокруг такие активные. Но к вечеру есть ещё столько интересных дел, и не у всех есть навык заставить себя ложиться по часам, а не когда устанешь.
Я довольно сильно "сова" - первый час после пробуждения со мной лучше не общаться, но, в обратную сторону, я могу один день обойтись вообще без сна - для "жаворонка" вещь малореальная.
"Не следовать эвристике" - это не описание стратегии принятия решений.
"Действовать обратно тому что написано на камне" - для вопросов "да/нет" действительно даст 99.9% ошибок, для вопросов с большим пространством ответов ещё больше.
"Кидать монетку и действовать согласно камню в 99.9%, наоборот в 0.1%" даст примерно 0.2% ошибок.
"Смотреть на реальность, назначая возможным наблюдениям очки, и действовать согласно камню только если очков набралось не больше 30, иначе действовать наоборот" - зависит от вашего метода подсчёта очков, очевидно. Но стратегия в этом духе - это единственный шанс ошибаться реже.
Для текста вроде мессенджеров вагон и тележка, нетривиально как раз аудио/видео.
Signal определённо работает (по крайней мере у четырёх разных стационарных операторов, ожидаю что и у мобильных). Jami вроде работает, нужно больше тестов.
Я как раз тестирую Jami, он умеет в установку одного профиля на несколько устройств. (Пока не знаю насколько хорошо, просто знаю что это есть.)
Подразумеваемая полная форма этой фразы "все разумные люди же понимают... [а если вы не, то вы сами расписались что вы не разумный человек и вас можно игнорировать]".
Я непосредственно смотрел для 2-НДФЛ, но сильно ожидаю что с трудовой то же самое: вы можете получить PDF с приложенным отдельно файлом подписи .p7s. После чего его надо проверить. Adobe Acrobat этого, судя по всему, "из коробки" не умеет (может, можно научить). openssl умеет (
openssl smime -verify -in doc_name_PDF.p7s -inform DER -content doc_name.pdf), только для этого а) HR должен уметь этим пользоваться и б) нужно добавить поддержку ГОСТ, ибо из дистрибутива по умолчанию её сколько-то лет назад выкинули.Моё замечание к словоупотреблению: "противодействие" скорее подразумевает что вот было равновесие, было воздействие в сторону от этого равновесия, и как результат возникла сила, тянущая обратно (cf. "принцип Ле Шателье").
То что мы имеем - это парный процесс, обе компоненты которого уводят из окрестности существовавшего решения, сваливаясь к какому-то другому равновесию.
Я не оспариваю что он закономерный, но, возвращаясь к изначальному пойнту, то что действия людей согласованы с объективной структурой предъявленных им стимулов - не мешает мне субъективно считать их неправыми, и я не вижу в этих двух суждениях противоречия.
Вот статья, на мой взгляд хорошо суммирующая эту интуицию:
Я бы не использовал слова "противодействие" для таких мероприятий - оба усилия направлены на ухудшение ситуации по моей шкале. Eye for an eye leaves the world blind и всё такое.
В принципе справедливо, и я предпочёл бы находиться в мире, где это так, но а) плохо применимо когда уже есть уйма кода с double, включая C-интерфейсы нескольких разных библиотек; б) я взял простой и компактный случай как иллюстрацию, можно взять менее компактный где система типов всё равно не поможет выразить смысл (ну, или описание типа будет чрезмерно громоздким).
Не согласен. Вы решили одну проблему, но создали другую: теперь у объекта нет просто метода
Length(), который в 90% случаев можно и нужно использовать как простой аксессор. Оговорка сделана оговоркой для оставшихся 10%.Компактное утверждение "этот вызов может занять больше времени чем кажется (если вы не понимаете, сколько и почему, спросите у автора кода или изучите и поймите реализацию, полный и точный ответ слишком длинный для этого комментария)".
Ну вот. Можно, конечно, написать больше комментариев чтобы прояснить и это (в данном случае оно более быстрое - затем и нужно, - но возлагает на клиента обязанность думать, как правильно обойтись с результатом).
У данного типа - нигде (и нет, его индикатор в данном классе не является уместным), отсюда и предупреждение. Я расшифровываю "не понял" как "комментариев всё ещё недостаточно" (в данном случае недостающая часть отчасти покрывается комментарием к самому типу, а отчасти ожидается в голове программиста, как часть знания предметной области).
Не очевидно что лучше. Потому что объектов прорва, а опция variant у них будет одна и та же. Её можно понять заранее во внешнем коде. (И это нелокальное условие, которое я не знаю как выразить типами.)
Вообще, кажется, заметная часть моего убеждения что комментарии нужны - что в проекте существуют нелокальные условия, которые влияют на локальные решения, поэтому их приходится выражать (напоминать) текстом. На это можно возразить, что одна из задач архитектора - превратить нелокальные условия в локальные. Но я сомневаюсь что даже в идеальном случае в сколько-нибудь сложной задаче это можно сделать на 100%.
Комментарии могут размечать логические блоки в пределах функции (а вынести их в отдельные именованные функции может быть плохой идеей из-за большого количества совместно используемых переменных). Более того, один из способов дизайна методов - вначале записать комментариями предполагаемую логику работы, а затем реализующий её код (приём взят из "Совершенного кода" Макконнелла).
Комментарии к публичным интерфейсам полезны, потому что передают семантику использования и неочевидные ограничения, которые затруднительно заложить в имена:
Или содержат примеры использования:
Комментарии могут содержать напоминания - знание, которое надо не забыть учесть при изменении кода (даже если прямо сейчас это знание не порождает какого-то решения, про которое надо объяснять "почему"):
Наконец, исключение "чтобы объяснить почему сделано именно так, а не иначе" - очень резиновое. Ведь такие объяснения возможны в любой сколько-то нетривиальной функции:
Мне кажется, или это универсальная претензия к принятию решений в условиях существенной неопределённости? Если туристическая группа пошла маршрутом, который из их исходных знаний ожидался более безопасным, попала под лавину и погибла - ни им ни их родственникам тоже "не легче".
Прагматически, решения всё равно надо принимать, и я считаю, что их качество в среднем всё ещё важно. Эмоционально, я хочу знать. Не "чтобы было легче", а потому что мне любопытно.
Эмоционально этот подход мне близок, но есть другая перспектива: я хочу иметь в голове модель, которая для действия X предсказывает, насколько вероятны те или иные исходы. Т.е. для Q = P("меня посадят" | do("я зашёл в Facebook")) - P("меня посадят" | ~do("я зашёл в Facebook")) может хотеться знать не просто категорическое Q>ε, а количественную оценку Q.
LLM неявно содержит довольно много "усреднённых" знаний, поэтому даёт хорошую аппроксимацию "отстранённого взгляда" ("outside view"). Я вот недавно попробовал использовать её для оценки сроков задач, и пока что post factum точность оценок очень приличная.
А я знаю? Сидишь себе, никого не трогаешь, тут бац, какой-нибудь
find_package(ZLIB REQUIRED)говорит "пошёл нахрен". Или случаетсяThe CXX compiler identification is unknown.Или просто настраиваешь какой-нибудь инструмент в первый раз, типа "хочу кросс-компилированный под ARM Go, использующий вот этот C-код".
И во всех этих случаях начинаешь с самого простого: пусть у меня соберётся программа, которая использует все релевантные технологии самым примитивным образом из возможных - напишет в консоль "привет", нарисует чайник, мигнёт одним светодиодом. В этом смысл Hello, world-программ: доказать, что у целевой системы можно вызвать какое-то поведение перед тем как пытаться вызывать сложное.
Hello world пишется столько раз, сколько надо проверить что система сборки как таковая не объявила забастовку и не сошла с ума. Завидую людям у которых это число раз равно 1.
Нужное для чего? Потому что если вы говорите о дозах с обычной пищей в принципе недоступных, то вы заведомо выходите за рамки медицинской нормы. Патологические дефициты витаминов (авитаминозы) известны и редки.
Если вы задаёте некоторый уровень "нужного", который определяется не патологиями, а анализами, то не худо бы хотя бы озвучить, какие плохие последствия вы ожидаете от меньшего уровня.
Есть какие-то конкретные соображения почему InvokeAI, а не Automatic1111 или ComfyUI?
(Я открывал статью как раз с надеждой что в ней будет актуальное сравнение систем этого рода, а то сейчас грустно пытаюсь пропатчить
sd-webui-SAGдо работающего состояния. В статье нет, но может есть у комментаторов?)Работает только если все производители солидарно не используют полезный патент в течение specific timeframe. Это не выглядит как равновесие Нэша для независимых агентов.
Возможные ответы:
1) Люди обучаются ещё и об реальность: действуют в мире с некоторыми ожиданиями, получают неожиданные результаты, корректируют (как минимум понижают в приоритете) часть ментальных моделей, "ответственную" за ожидание. У LLM такого механизма сейчас нет.
2) Обучение людей и процесс под названием "обучение", применяемый к LLM - это разные процессы. То что у первого есть условно устойчивые траектории не означает что они обязаны быть у второго.
3) Люди двигают науку за счёт обновления корпуса текстов между поколениями - не только включения, но и исключения ("новая теория становится мейнстримом, когда вымирают последователи старой"). При обучении LLM активного исключения текстов не происходит.
Моё примерное понимание - что у людей есть "естественная" продолжительность дня.
Жаворонки - те у кого она заметно меньше 24 часов (что коррелирует с более возбудимой психикой). Они просыпаются хорошо выспавшимися, легко начинают работать, но к вечеру уже ресурс заканчивается и ничем сложным не хочется заниматься.
Совы - у кого она заметно больше 24 часов, коррелирует с более инертной психикой. Утро настаёт слишком рано, подгрузка brain.exe медленная, какого чёрта все вокруг такие активные. Но к вечеру есть ещё столько интересных дел, и не у всех есть навык заставить себя ложиться по часам, а не когда устанешь.
Я довольно сильно "сова" - первый час после пробуждения со мной лучше не общаться, но, в обратную сторону, я могу один день обойтись вообще без сна - для "жаворонка" вещь малореальная.
Попробуйте так порисовать картинки, это доступно уже сейчас. Старая шутка про "с Наташи Ростовой падают трусы" покажется детским лепетом.
"Не следовать эвристике" - это не описание стратегии принятия решений.
"Действовать обратно тому что написано на камне" - для вопросов "да/нет" действительно даст 99.9% ошибок, для вопросов с большим пространством ответов ещё больше.
"Кидать монетку и действовать согласно камню в 99.9%, наоборот в 0.1%" даст примерно 0.2% ошибок.
"Смотреть на реальность, назначая возможным наблюдениям очки, и действовать согласно камню только если очков набралось не больше 30, иначе действовать наоборот" - зависит от вашего метода подсчёта очков, очевидно. Но стратегия в этом духе - это единственный шанс ошибаться реже.