А я думал, что мне, embedder'щику, деньги платят ровно за это.
Вы можете продолжать думать, что код на C++ написан для оборудования, я вряд ли в силах вас переубедить.
Но это не изменит реальности, в которой код на C++ написан для компилятора С++. А код на асме написан для ассемблера.
Т.е. все таки цензура.
Нет, это оптимальный осмысленный выбор. Такой же, как тот факт, что ваши микроконтроллеры по вашим же словам утверждают0/0 = 255. От чего у автора наверное сердечный приступ случился бы.
Вариант "потому, что могу" не катит.
К позиции автора, которую он пытается в статье отстоять, и вы вроде как с ним соглашаетесь, можно еще более тонкий вопрос задать.
Почему автора не смущает, что C++ как и куча других языков позволяет написать:
int a, b, c;
...
c = a / b;
а глупый CPU возьмет да и положит результат целочисленного деления в целочисленный регистр?
Это с точки зрения математики чушь какая-то, как это мы получили целое число, поделив целое на целое?
Предлагаю соблюдать правила математики со всей строгостью - для начала всем участникам снижаем оценки.
Потом переделываем процессоры, чтобы они такие глупости не делали, а клали в вещественный, нечего остатку пропадать.
А потом исправляем от этого недуга математически некорректные языки ассемблера и все высокоуровневые.
Я говорю что так можно - аппаратура это не запрещает.
Ну так для ваших PIC и AVR он может и не сократит. Проверьте, если GCC под них собирать умеет.
Но если я пишу x/x то это означает именно то, что мне НЕОБХОДИМО поделить x на x.
Приведите мне, пожалуйста, пример, при котором это имеет смысл в целочисленном делении. По мимо вашего желания запихнуть в регистр 0xFF, на него я уже ответил.
Я не нарушаю ни правила для оборудования, ни правила формальной системы.
Вы упускаете из внимания тот факт, что программу вы пишете не для оборудования. Вы ее пишите для другой программы, компилятора. Хоть на асме хоть на жаваскрипте.
Не хотите ориентироваться в слоях абстракций и выбранных решений, выбранных в той программе, для которой пишите свой код - пишите машинные инструкции.
Оно связано с тем, что автор "сформулировал" собственно сам бан деления на ноль и сокращения тут ни при чем.
Вопрос был скорее риторическим :)
Решите уравнение sqrt(x)/sqrt(x) = 1
Ну, компилятор такое и не сократит. Я понимаю, что вы пытаетесь сказать, но это никак не влияет на то, что компилятор, расстроивший автора - прав.
CPU не решает уравнения и не оперирует множествами. Он выполняет операции над числами.
Мы бы хотели зачеркнуть одинаковые выражения
Вы имеете на это полное право. Даже не так - вы обязаны это сделать, чтобы не вычислять корень два раза. Из некой сложной f(x), где такая дробь возникла, легитимно выкидываете, заменяя на единицу.
Перед этим, разумеется, вычисляете корень единожды и осуществляете проверку root != 0, кидаете исключение сами. А можете проверку и не делать, если где-то выше есть гарантии, что x != 0. Да, это тоже самое, что написали и вы, де-факто распространив на свое решение бан деления на ноль.
Контекст всегда важен, но компилятор исходит и всегда должен исходить из того, что написанное написано со смыслом. А вот генерить деление, в котором один и тот же регистр фигурирует 2 раза - не очень осмысленно.
Нужно показать детям, что деление на ноль — это ошибка.
Это не ошибка, а "бессмысленная" операция, для которой в формальной системе не определена операция обратная осмысленная.
А в некоторых местах вне элементарной алгебры делить можно. Разрешаю и вашим ученикам.
Дети видят — компьютер не может делить на ноль, программа аварийно завершается.
С тем же успехом можно объяснять детям, что ветер дует, потому что деревья качаются.
Математика устроена не так, как считает правильным железо/компилятор. Это железо/компилятор устроены так, как выгодно математике, догадываетесь?
Причем, преимущественно с инженерной точки зрения.
Если вы хотели показать, что нельзя делить на 0, то, ну... надо было делить на 0. А не на переменную.
В алгебре существует фундаментальное правило Сокращение x в числителе и знаменателе допустимо тогда и только тогда, когда явно оговорено, что x ≠ 0.
Чего? Покажите, пожалуйста, в какой из алгебр вы видели такое правило.
И вот здесь компилятор воспроизвёл классическую математическую ошибку
Компилятор все сделал верно. И даже гуманно - справедливо было бы упасть с сообщением "сокращай".
А он за вас сократил, так еще и бонус приятный сделал - сократил накопление ошибки в нагруженном смыслом расчете. Потому что он сделан для выражений чуть сложнее x/x.
Это ложная аналогия. И она разваливается даже с позиции для которой была приведена.
Если я на ткацком станке получил хрень (так как новичок), то могу итеративно почесать затылок, потыкать палочкой (если совсем умный то почитать мануал), и получить/приблизиться к желаемому результату через обозримое количество шагов.
При хорошем раскладе я со временем получаю полную ментальную модель станка, становлюсь виртуозом, ну вы поняли. И могу делать на нем то, для чего он даже не был предназначен.
Но вы не сможете стать мастером LLM. Не сможете предсказуемо получать вменяемые результаты для сложных задач, выписывая пляски с бубном вокруг огромной трясущейся функции аппроксимации.
Ну конечно только если не стоит задача генерировать дженерик хрючево на основе интернета, перемешивая с галлюцинациями. А такой задачи стоять не должно.
Луддиты тут ни причем. Станок ни кого не лишает работы, равно как и LLM. Только станок, в отличии от — это инструмент, которым вы можете овладеть.
Покажите, если опен. Или опишите, что за бинды и к чему, интересно.
Я пока что из своего опыта вижу, что недетерминированная LLM никак в таких задачах помочь не может. И все нормальные бинды автоматом могут быть сгенерены только генератором (зачастую самописным) переваривая спеку или синтаксическое дерево.
И все равно при этом многие места будут руками написаны. Потому что всю семантику и задуманное поведение не переведешь через генератор.
Если у вас на руках либа на Cи, состоящая из чистых функций, то проблем сгенерить бинды не будет даже у самого дотнета - LibraryImportAttribute и вперед.
Проблемки начинаются сразу после порога в виде набора чистых функций (и не Си).
LLM смысла написанного не выкупает и закономерно генерит бредик.
Ещё хуже то, что этот рак бьёт и будет бить дальше ещё сильнее по опенсорсу.
Из относительно недавнего личного примера — попытки (не особого шарящего судя по всему) сгенерировать бинды на C# к Vello (2D-либа на Rust для векторной графики построенная на компьют шейдерах) через LLM породили вкусный слоп, а заодно и брейн демедж с потерей времени у меня и тиммейта.
В лице оригинальной работы мы нашли качественную замену гугловской Skia, которая на объеме наших данных показывает себя уже не так хорошо.
Но вот то, что должно стремиться к нулевой цене (бинды), оказалось бредом, разваливающимся под нагрузкой. Ознакомиться можно здесь.
Есть ещё более вкусный пример (заслуживает расследования и статьи на самом деле). Прямо в реальном времени дамаг.
Открываете, например, репозиторий meshoptimizer — титаническая работа талантливого инженера. И замечаете интересную особенность, ведь глаз часто падает на Used by, всегда интересно покапаться, вдруг найдешь какой-нибудь скрытый гем. А тут почти 200k юзеров. Да ну?
В графе зависимыхзанятная картина — куча мусора, никакого отношения к 3D-графике не имеющая. С конкретных профилей (а их там много таких) идет бесконечный спам каким-то бредом. А в зависимостях этого бреда навалено всё, что можно и нельзя.
Да-да, прямо в концентрированный банк знаний, на котором этим самые бредогенераторы и были обучены (сожрав килотонны денег, электричества и далее по списку) в реальном времени льется куча бессмысленного шума.
Моё мнение, при развернутом self-hosted GitLab'е (у вас наверняка он?) - не нужно. Гитлабовский Package Registry закрывает все потребности и позволяет нормально работать со своими внутренними пакетами.
Один раз завели крупные группы, в которых делаете репы с системными либами и держите nuget.config в конечных проектах с адресами на Package Registry.
Опознает, ведь зрительный аппарат нормальный и распознаёт длины волн также, как и ваш. Но вот "видит" человек при этом то, что вы видите, когда смотрите на серо-буро-фуксиевый.
Собственно концепцию квалиа можно растянуть ещё дальше, и вообразить, что этот человек вообще ничего не видит. Его "картинка" это что-то, что конкретно вы посчитали бы просто чёрно-белый шумом.
При этом с человеком все нормально, он здоров. Вы оба посмотрите на кружку и согласитесь, что это кружка. Потому, что это просто слова, которые мы неявно согласились использовать для разных паттернов.
Что же такое человек видит (и в общем смысле чувствует) вы не сможете понять никогда, даже если разберёте его на элементарные части и тщательно проанализируете. Максимум - сможете сформулировать законы "чувствования".
А там уже и философский зомби за углом поджидает.
Поэтому лучше философию не трогать, трогайте зелёную траву на улице в летнюю погоду :)
Мне, как человеку, у которого есть опыт только с сишным синтаксисом (C++ и преимущественно C#), Раст бьёт по глазам очень сильно.
Но это далеко не так больно, как факт того, что в Расте до сих пор нет стабильного ABI. Ладно стабильного, компилятор Раста даже не способен выдать после компиляции инфу в адекватном виде по макетам типов, что решило бы множество проблем взаимодействия. 25 год подходит к концу, на секундочку.
Хорошо сделанную либу, написанную на Расте, просто невозможно вызвать из, например Шарпа, не написав кучу клея с оверхедом.
То есть язык, с которым невозможно общаться без С ABI (повышая цену вызова), позиционируется как замена С.
То, что он улетает в какой-нибудь
edx, не меняет сути того, что я пытался вам донести :)Подобный нонсенс с математической точки зрения вам и уютный С позволяет.
Вы либо от позиции автора откажитесь, либо от железячной. А лучше с ветряными мельницами вообще не бороться.
Вы можете продолжать думать, что код на C++ написан для оборудования, я вряд ли в силах вас переубедить.
Но это не изменит реальности, в которой код на C++ написан для компилятора С++. А код на асме написан для ассемблера.
Нет, это оптимальный осмысленный выбор. Такой же, как тот факт, что ваши микроконтроллеры по вашим же словам утверждают
0/0 = 255. От чего у автора наверное сердечный приступ случился бы.К позиции автора, которую он пытается в статье отстоять, и вы вроде как с ним соглашаетесь, можно еще более тонкий вопрос задать.
Почему автора не смущает, что C++ как и куча других языков позволяет написать:
а глупый CPU возьмет да и положит результат целочисленного деления в целочисленный регистр?
Это с точки зрения математики чушь какая-то, как это мы получили целое число, поделив целое на целое?
Предлагаю соблюдать правила математики со всей строгостью - для начала всем участникам снижаем оценки.
Потом переделываем процессоры, чтобы они такие глупости не делали, а клали в вещественный, нечего остатку пропадать.
А потом исправляем от этого недуга математически некорректные языки ассемблера и все высокоуровневые.
Красота?
Ни в коем случае. Это делает компилятор.
Ну так для ваших PIC и AVR он может и не сократит. Проверьте, если GCC под них собирать умеет.
Приведите мне, пожалуйста, пример, при котором это имеет смысл в целочисленном делении. По мимо вашего желания запихнуть в регистр 0xFF, на него я уже ответил.
Вы упускаете из внимания тот факт, что программу вы пишете не для оборудования. Вы ее пишите для другой программы, компилятора. Хоть на асме хоть на жаваскрипте.
Не хотите ориентироваться в слоях абстракций и выбранных решений, выбранных в той программе, для которой пишите свой код - пишите машинные инструкции.
Тогда и выражайте свои намерения явно,
x = 255?В случае автора это также означает, что надо было вместо статьи написать
x/0, но видимо помешал опыт программирования в 30 лет.Если бы вместо
intбахнулfloat- удивился бы с учениками ещё сильнее.Компилятор ничего не додумывает, да и на намерения художника ему все равно.
Он просто выбирает (в лице людей его написавших) оптимальный путь в рамках оборудования и формальной системы, которой является язык.
Это ваша обязанность - знать и понимать выхлоп компилятора.
Либо берете в руки asm. Но и там могут поджидать свои опасности из-за, например, out-of-order.
Оно связано с тем, что автор "сформулировал" собственно сам бан деления на ноль и сокращения тут ни при чем.
Вопрос был скорее риторическим :)
Ну, компилятор такое и не сократит. Я понимаю, что вы пытаетесь сказать, но это никак не влияет на то, что компилятор, расстроивший автора - прав.
CPU не решает уравнения и не оперирует множествами. Он выполняет операции над числами.
Вы имеете на это полное право. Даже не так - вы обязаны это сделать, чтобы не вычислять корень два раза. Из некой сложной
f(x), где такая дробь возникла, легитимно выкидываете, заменяя на единицу.Перед этим, разумеется, вычисляете корень единожды и осуществляете проверку
root != 0, кидаете исключение сами. А можете проверку и не делать, если где-то выше есть гарантии, чтоx != 0. Да, это тоже самое, что написали и вы, де-факто распространив на свое решение бан деления на ноль.Контекст всегда важен, но компилятор исходит и всегда должен исходить из того, что написанное написано со смыслом. А вот генерить деление, в котором один и тот же регистр фигурирует 2 раза - не очень осмысленно.
Это не ошибка, а "бессмысленная" операция, для которой в формальной системе не определена операция обратная осмысленная.
А в некоторых местах вне элементарной алгебры делить можно. Разрешаю и вашим ученикам.
С тем же успехом можно объяснять детям, что ветер дует, потому что деревья качаются.
Математика устроена не так, как считает правильным железо/компилятор. Это железо/компилятор устроены так, как выгодно математике, догадываетесь?
Причем, преимущественно с инженерной точки зрения.
Если вы хотели показать, что нельзя делить на 0, то, ну... надо было делить на 0. А не на переменную.
Чего? Покажите, пожалуйста, в какой из алгебр вы видели такое правило.
Компилятор все сделал верно. И даже гуманно - справедливо было бы упасть с сообщением "сокращай".
А он за вас сократил, так еще и бонус приятный сделал - сократил накопление ошибки в нагруженном смыслом расчете. Потому что он сделан для выражений чуть сложнее
x/x.Да это и есть выхлоп от нейронки, смысл статьи нулевой.
Плюс ко всему, автор как будто бы в состоянии потока находится. И ему бы обеспокоиться.
Вон выше уже и наставления от Иисуса. Либо клиника, либо толстота.
Это ложная аналогия. И она разваливается даже с позиции для которой была приведена.
Если я на ткацком станке получил хрень (так как новичок), то могу итеративно почесать затылок, потыкать палочкой (если совсем умный то почитать мануал), и получить/приблизиться к желаемому результату через обозримое количество шагов.
При хорошем раскладе я со временем получаю полную ментальную модель станка, становлюсь виртуозом, ну вы поняли. И могу делать на нем то, для чего он даже не был предназначен.
Но вы не сможете стать мастером LLM. Не сможете предсказуемо получать вменяемые результаты для сложных задач, выписывая пляски с бубном вокруг огромной трясущейся функции аппроксимации.
Ну конечно только если не стоит задача генерировать дженерик хрючево на основе интернета, перемешивая с галлюцинациями. А такой задачи стоять не должно.
Луддиты тут ни причем. Станок ни кого не лишает работы, равно как и LLM. Только станок, в отличии от — это инструмент, которым вы можете овладеть.
Ловко вы станок, у которого детерминирован выход от входа (как и у любой техники для производства) приравняли к LLM.
Но вам не станок продают. В обе стороны этим аргументом нельзя.
Покажите, если опен. Или опишите, что за бинды и к чему, интересно.
Я пока что из своего опыта вижу, что недетерминированная LLM никак в таких задачах помочь не может. И все нормальные бинды автоматом могут быть сгенерены только генератором (зачастую самописным) переваривая спеку или синтаксическое дерево.
И все равно при этом многие места будут руками написаны. Потому что всю семантику и задуманное поведение не переведешь через генератор.
Если у вас на руках либа на Cи, состоящая из чистых функций, то проблем сгенерить бинды не будет даже у самого дотнета - LibraryImportAttribute и вперед.
Проблемки начинаются сразу после порога в виде набора чистых функций (и не Си).
LLM смысла написанного не выкупает и закономерно генерит бредик.
Ещё хуже то, что этот рак бьёт и будет бить дальше ещё сильнее по опенсорсу.
Из относительно недавнего личного примера — попытки (не особого шарящего судя по всему) сгенерировать бинды на C# к
Vello(2D-либа на Rust для векторной графики построенная на компьют шейдерах) через LLM породили вкусный слоп, а заодно и брейн демедж с потерей времени у меня и тиммейта.В лице оригинальной работы мы нашли качественную замену гугловской
Skia, которая на объеме наших данных показывает себя уже не так хорошо.Но вот то, что должно стремиться к нулевой цене (бинды), оказалось бредом, разваливающимся под нагрузкой. Ознакомиться можно здесь.
Есть ещё более вкусный пример (заслуживает расследования и статьи на самом деле). Прямо в реальном времени дамаг.
Открываете, например, репозиторий meshoptimizer — титаническая работа талантливого инженера. И замечаете интересную особенность, ведь глаз часто падает на
Used by, всегда интересно покапаться, вдруг найдешь какой-нибудь скрытый гем. А тут почти 200k юзеров. Да ну?В графе зависимых занятная картина — куча мусора, никакого отношения к 3D-графике не имеющая. С конкретных профилей (а их там много таких) идет бесконечный спам каким-то бредом. А в зависимостях этого бреда навалено всё, что можно и нельзя.
Да-да, прямо в концентрированный банк знаний, на котором этим самые бредогенераторы и были обучены (сожрав килотонны денег, электричества и далее по списку) в реальном времени льется куча бессмысленного шума.
Такие дела. А выводов нет.
Ассемблер на 53.3% - JavaScript и 46.7% - TypeScript? Гений.
А гении не редко бывают отвергнуты обществом.
Так решается тем, что nuget.org держится в nuget.config наряду с адресами на гитлаб. Рабочие машины и раннеры чувствуют себя нормально.
Заодно лента гитлаба и как нормальный источник отладочных символов выступает - VS и Rider дружат.
Я может проблематику не понимаю.
Моё мнение, при развернутом self-hosted GitLab'е (у вас наверняка он?) - не нужно. Гитлабовский Package Registry закрывает все потребности и позволяет нормально работать со своими внутренними пакетами.
Один раз завели крупные группы, в которых делаете репы с системными либами и держите
nuget.configв конечных проектах с адресами на Package Registry.Опознает, ведь зрительный аппарат нормальный и распознаёт длины волн также, как и ваш. Но вот "видит" человек при этом то, что вы видите, когда смотрите на серо-буро-фуксиевый.
Собственно концепцию квалиа можно растянуть ещё дальше, и вообразить, что этот человек вообще ничего не видит. Его "картинка" это что-то, что конкретно вы посчитали бы просто чёрно-белый шумом.
При этом с человеком все нормально, он здоров. Вы оба посмотрите на кружку и согласитесь, что это кружка. Потому, что это просто слова, которые мы неявно согласились использовать для разных паттернов.
Что же такое человек видит (и в общем смысле чувствует) вы не сможете понять никогда, даже если разберёте его на элементарные части и тщательно проанализируете. Максимум - сможете сформулировать законы "чувствования".
А там уже и философский зомби за углом поджидает.
Поэтому лучше философию не трогать, трогайте зелёную траву на улице в летнюю погоду :)
Шершавый кабан снова выходит на связь.
Мне, как человеку, у которого есть опыт только с сишным синтаксисом (C++ и преимущественно C#), Раст бьёт по глазам очень сильно.
Но это далеко не так больно, как факт того, что в Расте до сих пор нет стабильного ABI. Ладно стабильного, компилятор Раста даже не способен выдать после компиляции инфу в адекватном виде по макетам типов, что решило бы множество проблем взаимодействия. 25 год подходит к концу, на секундочку.
Хорошо сделанную либу, написанную на Расте, просто невозможно вызвать из, например Шарпа, не написав кучу клея с оверхедом.
То есть язык, с которым невозможно общаться без С ABI (повышая цену вызова), позиционируется как замена С.
Подобного мусора будет все больше с каждым днём. Зря выпустили нейроджина, ох, зря.