Pull to refresh
4
0.1
Send message

Ubuntu такая: "о, я теперь винда, что ли"?
Если компьютер нужен чтобы работать с информацией, то, внезапно, однозначной связи между приложением и данными не существует - у меня вполне рутинна ситуация, когда конкретный файл открывается тремя-четырьмя разными программами.

Для ИИ ваш проект - это просто плоская последовательность символов.

Неочевидно.
При (до)обучении на данных, было показано что трансформеры могут формировать модель порождающего данные процесса [Li 2022] [Nanda 2023].
Утверждение что этого не может происходить при in-context learning - сильное, оно требует обоснований. Мы уже знаем что модель может строить т.н. task vectors в промежуточных вычислениях - превращать "вопрос о данных" в отдельную внутреннюю сущность [Hendel 2023].

LLM статична. Она не становится «умнее» от того, что три часа помогала вам с рефакторингом.

Но в результате рефакторинга код может принимать форму, более удобную для обработки этой LLM. Совокупная система "текст кода+LLM" не является статичной, то что её "понимание смысла кода" не может улучшаться надо доказывать, это тоже неочевидно.

Тем что он работает, но звонит хуже чем Signal (чаще случается когда с точки зрения звонящего вызов происходит, а телефон адресата спокойно себе лежит и только потом сообщает "ой, кажется вас кто-то искал").
Установка на разных устройствах сама по себе вроде работает нормально, но после первых тестов активно им не пользовался.

Рискну предположить, что через неделю про эту Кими никто и не вспомнит

Почему, Kimi давно была хорошей моделью "второго эшелона" (отстающей в общем использовании, но лидирующей в частных задачах, в её случае - в написании прилично звучащего текста и тестах на не-поощрение психозов пользователя вроде SpiralBench).

Я верю что её новую версию могли заметно улучшить, но mixture-of-experts всё-таки не тянет на "прорыв в алгоритмах".

Отдельно, открытые модели имеют неустранимые проблемы безопасности. Anthropic может обрезать доступ к модели, если вы будете задавать вопросы "как сварить зарин в домашних условиях". Если Kimi так хороша как рекламируется, то есть шанс что её вспомнят, но по очень плохой причине.

???

Если я скачал файл с веб-сайта с TLS, то в TLS был сертификат, он и основание.

Если вам кажется что сертификат "Sectigo зуб даёт что владелец домена hack-my-comp.tech - Vasya Pupkin LLC" - так себе основание (с чем я согласен), то чем "Apple зуб даёт что автор исполняемого файла hack-my-comp - Vasya Pupkin LLC" лучше?

Симпатичные авторам герои развлекаются, бродят по институту, рисуют стенгазету, обсуждают мёртвого попугая — занимаются чем угодно, только не своими прямыми обязанностями.

Начнём с того, что стенгазета - это как раз навешанная администрацией обязанность, от которой люди и рады бы отбояриться. Помимо этого Привалов пишет и запускает программы, как явно требуемые, так и по простым просьбам людей которых он уважает. "Бродит по институту" он опять же по прямому приказу начальства. Ойра-Ойра занимается исследованиями за кадром, судя по решённой проблеме Ауэрса - небесплодно. Амперян к "Тройке" успешно сделал свой реморализатор, Корнеев проводит эксперименты с М-полем.

А вот Выбегалло занимается как раз тем, что по отчётам почти наверняка проходит как "работа", но содержательного наполнения практически лишено. Авторы как раз и подсвечивают, что чтобы распознать подобный типаж, необходимо собственное нетривиальное понимание области.

Неплохо бы поиграться и с форматами дат. Например, если вся таблица называется «Платежи 2025», то повторять год в дате не обязательно.

До того отнюдь не прекрасного момента когда по какой-то причине дата окажется 17.12.2024, и бухгалтер поставит всех на уши в попытке найти платёж от 17.12.2025.

Я бы сказал так: если скрываете данные для красоты в некотором предположении, сделайте условное форматирование, которое подсветит вырвиглазным красным ячейки где это предположение нарушено. Если не знаете как это сделать - не скрывайте данные, эти грабли бьют по лбу редко, но больно.

Баянист наверняка сможет за краткое время освоить гитару, но восхитительный фламенко будет ему недоступен.

Вопрос в том, каковы реальные требования. И из вакансии они очень плохо считываются - то ли людям нужен относительно приличный гитарист (понятно что чем лучше тем лучше, но "приличного" достаточно), то ли нужно с первого дня играть техничный спид-металл.

Я бы оценивал что и сколько нужно переучивать под нужды проекта, и "сменить язык" здесь не всегда самый большой барьер. Питонист в средний C++ проект - в общем случае так себе идея, но переход C# -> Go выглядит не сильно хуже чем "в проекте активно используются CGo-вызовы внешних библиотек, нужна привычка правильно расставлять defer" (которой у человека с номинальным опытом Go всё ещё может не быть).

Да, принято, запутался в терминах. Человек из Anthropic почти наверняка имел в виду "Super AI" (или его синонимы, любой удачный термин в этой области быстро захватывают маркетологи и начинают рассказывать что это-де они уже продают).

Нет, я включаю в превосходит "производит строго лучший результат при строго меньшем расходовании электроэнергии, времени, площади земной поверхности и иных ограниченных ресурсов".

Да, я согласен что планетарный оракул, способный ответить не более чем на 8000 запросов в сутки и не масштабируемый из-за прожорливости, даже если он на них отвечает кратно лучше людей, сам по себе такой ситуации не создаст (но его можно спросить "как сделать тебя более энергоэффективным?"...).

выкладывает графики не имеющие физического смысла, на основании которых делает глубокие выводы

Почему вам кажется что эти графики - основание, а не иллюстрация?

А то у меня периодически бывают споры с людьми, которые берут иллюстрацию к ОТО "пространство - это эластичный лист, который продавливается шарами с массой" и спрашивают "и что, эти физики-тупицы так и не задались вопросом, а что тогда притягивает эти шары вниз?"

Экономический аргумент вообще-то грустный: "сильный ИИ", по определению термина, есть штука, которая превосходит почти всех людей в почти всех областях деятельности. Если мы считаем его достижимым в ближней перспективе (если!), то для большинства людей не будет существовать экономически оправданной занятости, за которую бы им платили деньги - обладатель денег может получить больше, потратив их на экземпляр ИИ.
(Это, разумеется, подразумевает что "сильный ИИ" и "экономика-как-сегодня" вообще совместимы.)

Можно, но
1) при этом пострадает качество текста в целом (мы, возможно, хотели бы динамически подстраивать температуру под "важность" токена, но сейчас никто вроде не пытается это делать);
2) в менее очевидных случаях нулей не будет (скажем, при ответе "да"/"нет" на нетривиальный вопрос логиты обоих опций будут существенно ненулевыми).

Не решения, право доступа к работающей системе. Судя по тому что Роскомнадзор некоторое время назад выкатывал ТЗ "сделать свой СОРМ, с маджонгом и гейшами" (там были формулировки отчётливо из времён "трёхглавого закона", выглядит так что копипастили из ТЗ какой-то существующей реализации), я восстанавливаю что они попытались пробить себе доступ к СОРМ без судебных решений и были посланы.

Разработка способов блокировки, как и способов обхода этих самых блокировок, должно быть, очень технически сложные задачи

Не очень. Точнее, некоторая идеальная блокировка, когда целью ставится написать простые в исполнении правила, которые практически блокируют конкретный протокол и при этом порождают мало проблем в остальном трафике - нетривиальная задача (если протокол специально маскируется под безобидные или под хрен-пойми-что), но, судя по результатам, решают не её.

Те кто хотят решать нетривиальные задачи анализа протоколов и идеологически не против государственного надзора за гражданами - идут работать над СОРМ (который, судя по доносящимся новостям, Роскомнадзоровцев послал к чёрту). Там решается более сложная задача - по совокупности трафика понять, что именно человек делал, без права вмешательства.
(На всякий случай оговорка: я не говорю что фактическая перлюстрация трафика есть морально достойное занятие, я обсуждаю именно то, насколько технически интересные задачи при этом возникают.)

В условии нет нормального описания того, как именно работает команда сложения. Довольно очевидно, что предполагается что числа представлены в двоичной записи, машинное слово содержит сколько-то бит (а не трит или чего-то более экзотического), отрицательные числа представлены в дополнительном коде, при переполнении старшие биты тихо исчезают. Но всё это вообще-то надо сказать.

Ещё хуже что непонятно сочетание условия что есть только команда сложения (нет условных переходов, нет присваивания константы, нет call/ret, etc) и слов про "язык программирования".

Но поехали. Пусть у нас слова по 32 бита, и все команды сложения по одному слову (т.е. регистр команд IP при каждом сложении увеличивается на 1). Регистры обозначаем латинскими буквами и считаем что их сколько угодно, результат образуется в регистре по имени a.

1) Команда зануления. a := a + a x32.

2) Команда присваивания единицы.
a := 0
b := 0
b := IP
a := IP
# повторить 32 раза
a := a+b
b := b+b

3) Очевидно, аналогично можно присвоить регистру любую константу:
a := 0
b := 1
# пишем 42 = 00101010
b := b+b #0
a := a+b #1
b := b+b
b := b+b #0
a := a+b #1
b := b+b
b := b+b #0
a := a+b #1

(Важно заметить, что эта операция может быть дополнена инструкциями b := b+b и поэтому всегда может занимать ровно 0xa6 команд)

4а) Условные переходы. Пусть TP, FP и Ri - выделенные регистры, которые не используются никак иначе, и мы можем разместить команды по следующим адресам:
# 0x00000000
IP := IP + FP
# 0x80000000
R0 := 0x7fffff59 # вычисление использует R1
TP := TP + R0
IP := IP + TP

Тогда можно сделать команду перехода на инструкцию TP если a имеет значение 0x80000000 и FP если a имеет значение 0, JMP31 a:
b := <дополнение (адреса текущей инструкции+2)>
b := b+a
IP := IP+b

4б) Команда перехода на TP если a имеет 1 в n-ном младшем бите и FP если он имеет в нём значение 0, при условии что все биты младше - нулевые, JMPn: a := a+a x(31-n), JMP31 a

4в) Команда перехода на TP если a не 0, на FP иначе, JNZ a:
b := 0
b := b + FP
FP := L1
JMP0 a
L1: FP := L2
JMP1 a
...
JMP30 a
L31:FP := 0
FP := b + FP
JMP31 a

5) Аналогично, побитовое обращение b:
a := 0
c := 1

d := 0
d := d+b
FP := L1
TP := L2
JMP0 d
L1: a := a+c

TP := L3
JMP0 c
L2: e := 0xffffffff

d := d+e
L3:c := c+c
FP := L4
TP := L5
L4: a := a+c
L5: c := c+c
...

6) Вычитание, a := b - c:
d := ~c
e := 1
d := d + e
a := b + d

Умножение и деление дальше вроде довольно очевидны.

Бледно.

Об именах переменных: не используйте что-либо вне ASCII-набора, даже если среда это позволяет (потому что нынче она, к сожалению, иногда позволяет). Отладка путаницы между int cap и int сар согреет вашу пятую точку как мало что другое.

Обращайте внимание на предупреждение "name XXX hides outer variable". C++ позволяет дублирование имён во вложенных блоках:
int a = 2;
for(int b = 0; b < a; ) {
int a = 17;
//...
--a;
}

- но это почти никогда не идёт на пользу читаемости программы.

Если вы таки-используете глобальные переменные, называйте их уникальным образом, чтобы при чтении было очень хорошо видно, что вот здесь модифицируется глобальная переменная.
Аналогичный совет относится к статическим переменным в функциях/методах и данным-членам классов.

Разделяйте имена переменных и функций (скажем, одни с маленькой буквы, другие с большой), потому что в C++ они умеют конфликтовать.

Либо не используйте макросы вообще, либо давайте им визуально отличные от всего остального имена (обычное соглашение - ИСПОЛЬЗОВАТЬ_КАПС). Имя макроса может быть распознано в совершенно любом контексте и результат способен порождать очень озадачивающие сообщения компилятора.
(Да, старайтесь не включать windows.h по крайней мере в заголовочных файлах, эта падла определяет тонну макросов, иногда с очень неудачными именами.)

Называйте переменные и функции по тому, что они представляют, а не потому, как они реализованы:
bool IsLessThanMinusTen(int number) {return number <= -10;} // плохо
bool IsLethalHP(int hp) {return hp <= -10;} // лучше

Хотя имена могут быть слишком длинными, на современных мониторах "строка не влезает в экран" - отчётливый признак того, что вы делаете что-то кошмарно не то. Найдите в настройках среды визуализацию вертикальной линеечки и выставьте её на какую-нибудь разумную ширину. Есть люди которые рекомендуют 80, на мой вкус это бывает слишком коротко, я предпочитаю 120 (это удачно совпадает со строкой, которая не переносится в интерфейсе нашего gitlab при сравнении side-by-side).

Я знаю "канонический" ответ (круглую крышку в принципе невозможно уронить в люк который она закрывает), но он на мой вкус очень странный. Эти крышки и специально-то обратно на место у меня получается положить со второй-третьей попытки. Кроме того, крышка реалистичной толщины и с реалистичной "полочкой" не пролезет в собственное посадочное место даже будь она квадратной.

1) Они не всегда круглые, автор этого комментария воочию видел квадратные.

2) Они в общем случае не обязаны иметь форму колодца под ними (основание крышки всё равно делается отдельно).

3) Насколько я понимаю, в основном "так исторически сложилось" - есть налаженный процесс изготовления крышек, который сейчас или когда-то в прошлом было проще наладить для условно круглых и нет причины эту форму менять. (Я бы ожидал что сейчас их отливают, что позволяет сделать любую простую форму со сравнимой лёгкостью.)

Впервые (нет) на арене: нумерую все рациональные числа. Беру рациональное число p/q, записываю p и q в восьмеричной системе счисления, объединяю через 8. Например: 355/113 -> 0543 / 0161 -> 5438161. Всё, все рациональные числа получили по натуральному номеру и ещё прорва натуральных номеров осталась.

Нет никакого фундаментального отличия "природы" от "системы", по крайней мере на уровне онлайн-казино. Кидает шарик в рулетку живой крупье или генерируется следующий член гаммы блочного шифра - с точки зрения игрока это гипотезы с одним и тем же распределением исходов. То что абстрактное казино что-то "знает" - совершенно неважно, если миры в которых оно "знает" и "не знает" эмпирически неотличимы.

Вся «удача» — это разница в информационных правах: казино знает всё, игрок не знает ничего.

"Удача" казино в том, что а) математическое ожидание выигрыша для игрока отрицательно (именно для этого на рулетке есть сектор "зеро", к примеру); б) у казино на порядки больше капитала (cf. "задача о разорении игрока"). Разницы между генератором в который можно подглядеть и гипотетическим идеальным генератором, равно непредсказуемым для всех сторон, в смысле этих двух факторов нет.

Да, в принципе казино может мухлевать. Но для этого ему всё ещё совершенно не требуется предсказывать значение генератора, оно может просто заменить очередной выход генератора желаемым - как искусный крупье может намеренно выбросить "красное" на рулетке по заказу.

1
23 ...

Information

Rating
3,824-th
Registered
Activity