Здравствуйте, T4r4sB, Вы писали:
TB>Понимаешь, в чём проблема. Если я забуду привести к инту при сложении u8+u8, то я получу падающий код. И компилятор ничего мне на это не скажет. То есть эти ограниченные Strong Types сами порождают грабли, хотя по задумке якобы должны от них защищать. И что самое хреновое — правильный код выглядит грязнее и хуже, чем неправильный но компилирующийся.
Нуу, посмотрел я на то, как ведёт себя руст, — да, соглашусь, это эребор!
Был бы я автором руста, я бы ввёл разные числовые типы — для арифметики в кольце и арифметики в диапазонах.
И ничего бы из них не делал выбором по умолчанию. Чтобы погроммисты сами выбирали себе вид боли.
Хотят получать странные числа в unsafe_i8 — пусть получают. Хотят получать за это по пальцам в strict_i8 — пусть получают.
А ещё лучше — ограничивать диапазоны не степенями 256, а произвольными числами. Как это делается в паскале и аде.
TB>Я не про то, что неявные преобразования зло. Я про то, что не надо плодить слишком много типов, и боже упаси ограничивать диапазон этих типов.
Много разных типов нужны для многих разных целей.
А то вон в сях пихали int куда ни попадя, и что, хорошо, что ли? Особенно, в функции работы с символами.
Где-то это важно для производительности, где-то напротив, важно сказать "компилятор, ну ты сам за меня реши, что лучше на какой платформе".
К>>Да, фигня какая, вдвое больше места и вчетверо медленнее вычисления.
TB>Отбрось лишние биты (старшие или младшие — в зависимости от задачи) и будет быстрое время.
Так с самого начала и отбросили. А если где-то кому-то надо сверхдлинное время — вот пусть ровно там для себя и вводит.
Зачем всех заставлять-то?
К>>Аха, то есть, координаты для промежуточных вычислений (а не только перед финальным округлением) у нас уже полуцелые. Кто тут говорил, что int хватит?
TB>Очевидно, что пример с шахматной доской это не тот же пример, что с векторами-точками.
К>>Почему точка ровно посередине отрезка AB имеет физический смысл, а шестая по счёту точка на гребёнке из десяти засечек — не имеет физический смысл?
TB>Потому что мне нужен корректный код. Если я опечатался и написал a+(b-a)*0.6, то мне от этого ничуть не легче, чем если бы я написал (a+b)*0.6. Результат в обоих случаях неверен. TB>Можно поспекулировать на тему, что во втором случае я замечу, что поведение системы меняется в зависимости от расстояния до нуля и поэтому быстрее найду причину бага, но это спекуляции, потому что в разных случаях может быть по-разному.
Насчёт легче или нет — это именно спекуляции.
Но в одном случае ты делаешь линейную интерполяцию с неправильным коэффициентом (хотел 0.7 или 0.5, рука дрогнула, подставил 0.6), а в другом — создаёшь неверную сущность, хотя для какой-нибудь фрактальной геометрии, возможно, она и пригодится.
Если тебя бесит, что в симметричной формуле линейной интерполяции появляется внутренняя асимметрия, — одна из точек становится важнее другой, — ну спрячь формулу в функцию.
Point interpolate(Point a, Point b, float ratio) { return a + (b-a) * ratio; }
Point midpoint(Point a, Point b) { return interpolate(a, b, 0.5); }
Point midpoint(vector<Point> points) { return points[0] + sum(points - points[0]) / size(points); } // псевдокод
А то, что interpolate(a,b,r) == interpolate(b,a,1-r), что симметрия там не вокруг 0, а вокруг 0.5 — ну блин извините! Сделай вокруг нуля
Point around_midpoint(Point a, Point b, float deviation) { return interpolate(a, b, deviation + 0.5); } // или свою реализацию по вкусу
Зачем при этом воевать против системы типов-то?
Наоборот, система типов не даст тебе облажаться в попытках колхозной интерполяции (a+b)/2 или (a+b+c+d+e)/5 вместо библиотечной.
К>>Я вот тоже думал "нафига ввели точку, есть же вектор" — до того момента, как не полез в "промышленную" геометрию. К>>Так что все эти вещи — выстраданные.
TB>Что такое "промышленная геометрия"? В популярных библиотеках нет этой шизы. TB>Если же ты про библиотеки, предназначенные для сверх-надёжного кода для прошивок ядерных реакторов, то надеюсь, что тебе очевидно, что методы, применяемые в этой сфере, категорически не подходят в тех случаях, когда цена ошибки — это максимум потеря правок за последнюю минуту?
TB>И раз уж мы вспомнили про прошивки ядерных реакторов, то давай вернёмся к моему примеру про сложение u8+u8, которое компилятор не отловит. Ну и тогда уж, чтоб намёк про "надёжность" ограниченных типов был понятнее — давай заменим ядерный реактор на ракету Ариан-5
Я про библиотеки, используемые в промышленной робототехнике, — в ROS.
И давай не мешать в кучу арифметику чисел (и несчастный ариан) и типизацию структур (векторы и точки).
Если бы разработчики ариана использовали векторы и накосячили в аффинных преобразованиях, это было бы не менее эпично.
Здравствуйте, Кодт, Вы писали:
К>Хотят получать странные числа в unsafe_i8 — пусть получают
Да даже незачем называть этот тип unsafe_i8, можно назвать его looped_i8.
К>А ещё лучше — ограничивать диапазоны не степенями 256, а произвольными числами. Как это делается в паскале и аде
Тогда возникает вопрос, какой тип должен быть у Integer<1..2> + Integer<3..4>? И допустимо ли их сложение?
Число по здравому смыслу это должен быть Integer<4..6>, но из-за ограничений платформы на деле получается, что в Расте
Integer<0..255> + Integer<0..255> имеет тип Integer<0..255> а вовсе не Integer<0..510> как должно быть.
К>Где-то это важно для производительности, где-то напротив, важно сказать "компилятор, ну ты сам за меня реши, что лучше на какой платформе".
В целом подход сей с кастом всего и вся к инту мне кажется каким-то неконсистентным, тут я солгасен.
TB>>Отбрось лишние биты (старшие или младшие — в зависимости от задачи) и будет быстрое время.
К>Так с самого начала и отбросили. А если где-то кому-то надо сверхдлинное время — вот пусть ровно там для себя и вводит. К>Зачем всех заставлять-то?
Мне всегда казалось, что правило, которое выводится прямой логикой, всегда намного легче для понимания и усвоения, чем правило, которое необходимо зубрить. По-моему, это очевидно, что для получения секунд из наносекунд надо поделить на 10**9
ции, потому что в разных случаях может быть по-разному.
К>Насчёт легче или нет — это именно спекуляции. К>Но в одном случае ты делаешь линейную интерполяцию с неправильным коэффициентом (хотел 0.7 или 0.5, рука дрогнула, подставил 0.6), а в другом — создаёшь неверную сущность, хотя для какой-нибудь фрактальной геометрии, возможно, она и пригодится.
Дык я в любом случае из-за опечатки имею неверный результат. И мне ничуть не легче от того, что он "немного по-другому" неверный.
"Раньше люди добрее были. Никого не убивали. А если и убивали, то как-то по-доброму что ли".
К>Если тебя бесит, что в симметричной формуле линейной интерполяции появляется внутренняя асимметрия, — одна из точек становится важнее другой, — ну спрячь формулу в функцию.
Меня бесит, что для задачи
auto half_of_center = center * 0.5;
for (auto& p: points) {
p = p * 0.5 + half_of_center ;
}
мне придётся делать лишнее сложение во внутреннем цикле в случае использования "типобезопасной" библиотеки. И это я вспомнил лишь самую простую формулу.
К>Я про библиотеки, используемые в промышленной робототехнике, — в ROS.
Лично я такие не использовал, но кто пользовался из моих знакомых — отзывы что разделение точек и векторов это бесполезный геморрой для программиста, не дающий никакой пользы.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Кодт, Вы писали:
К>соглашусь, это эребор!
С гномами и барлогами, да!
К>Хотят получать странные числа в unsafe_i8 — пусть получают. Хотят получать за это по пальцам в strict_i8 — пусть получают.
+1
К>А ещё лучше — ограничивать диапазоны не степенями 256, а произвольными числами. Как это делается в паскале и аде.
Чтоб фейерверки от взрывающихся пуканов были повеселее.
К>А то вон в сях пихали int куда ни попадя, и что, хорошо, что ли?
Нет, безумие получилось.
К>Так с самого начала и отбросили. А если где-то кому-то надо сверхдлинное время — вот пусть ровно там для себя и вводит.
+1
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Константин Б., Вы писали:
КБ>А как называется феномен когда программист принципиально не читает документацию? Узнавать о возможностях библиотеки надо из документации, а не из сообщений компилятора. КБ>Если у библиотеки нет/плохая документация — то за это можно и нужно ее поругать. Так же можно поругать того кто решил такую библиотеку использовать в проекте. КБ>А пытаться изучать библиотеку по ошибкам компилятора... Ну такое.
Каждую документацию надо начинать словами "Ну что, с наскоку не получилось?" (С)
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, T4r4sB, Вы писали:
TB>но из-за ограничений платформы на деле получается
Это не ограничения платформы а реальность, данная нам в ощуплении (tm)
Ибо каждый язык это всего лишь более удобный способ выразить логику программы чем писать в машкодах. И они все должны ложиться на архитектуру платформы.
Когда про это забывают — получается бардак и страдания.
TB>Integer<0..255> + Integer<0..255> имеет тип Integer<0..255> а вовсе не Integer<0..510> как должно быть.
Кому должно?
Это как кричать что неправильно что у человеков две руки а должно быть четыре!
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Кому должно?
Математике. Если в школе дать задачу, типа есть вот два числа из диапазона [0..255], то в каком диапазоне будет их результат, то любой первоклассник сможет вычислить, что результат попадёт в диапазон [0..510]. И было бы удобно, если бы система типов соответствовала математике. Но так как это не так, то из-за забытого каста имеем программу, падающую на валидных данных.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Математике.
Математика имеет такой интересный раздел как Rings и в частности подраздел Modular arithmetic
Потрудитесь ознакомиться.
TB>И было бы удобно, если бы система типов соответствовала математике.
И было бы удобно если бы количество пальцев соответствовало абстрактным моделям, вот только реальность не соглашается прогибаться под теорию.
TB> Но так как это не так, то из-за забытого каста имеем программу, падающую на валидных данных.
Не надо перекладывать рукожопие погромиста, не понимающего что он творит, на железо, которое просто делает как ему было погромистом сказано.
Garbage in — garbage out.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Математика имеет такой интересный раздел как Rings и в частности подраздел Modular arithmetic CC>Потрудитесь ознакомиться.
При написании кода в подавляющем большинстве случаев программист подразумевает обычную арифметику, и что на валидных данных никогда не случится арифметического переполнения.
И в русте арифметика не модульная.
CC>Не надо перекладывать рукожопие погромиста, не понимающего что он творит, на железо, которое просто делает как ему было погромистом сказано.
То есть ты утверждаешь, что опечаток не бывает, а бывают лишь ошибки, вызыванные непониманием?
Странно, я думал, что только в школе остались кульные какиры, которые думают, что всегда всё контролируют и что уж они-то никогда не уронят программу из-за случайно забытого символа или не отлавливаемой компилятором опечатки.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>И в русте арифметика не модульная.
В процессоре — модульная.
TB>То есть ты утверждаешь, что опечаток не бывает, а бывают лишь ошибки, вызыванные непониманием?
Очепятка это когда написали чутка не то, а не дыра в логике.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>В процессоре — модульная.
И что с того, что что-то там в процессоре, теперь на асме писать, чтобы было как "в процессоре"? Мне казалось, что обязанность высокоуровнего ЯП это предоставление удобных абстракций. Если абстракция протекает и из-за случайной опечатки это приводит к падающей программе, то это дыра в дизайне.
CC>Очепятка это когда написали чутка не то, а не дыра в логике.
Забыть поставить каст к более широкому типу — это тоже опечатка.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Кодт, Вы писали:
К>Был бы я автором руста, я бы ввёл разные числовые типы — для арифметики в кольце и арифметики в диапазонах.
Примерно так и сделали: https://doc.rust-lang.org/std/num/struct.Wrapping.html
Ну и при необходимости локально можно использовать конкретные операции с нужным поведением: wrapping/checked/saturating/overflowing. Писать так весь код мало кто захотел бы, поэтому стандартное поведение и такое: паника в дебаге (чтобы был таки шанс поймать ошибку) и аналог Wrapping в релизе (с возможностью включить таки проверки).
К>А ещё лучше — ограничивать диапазоны не степенями 256, а произвольными числами. Как это делается в паскале и аде.
Здравствуйте, T4r4sB, Вы писали:
CC>>В процессоре — модульная. TB>И что с того, что что-то там в процессоре
К тому что принципы как оно будет на самом деле выполняться надо таки понимать.
TB> Если абстракция протекает и из-за случайной опечатки это приводит к падающей программе, то это дыра в дизайне.
Ну т.е. тебе тут надо памперсы ChatGPT чтоб за погромиста не забывал сделать то, что надо сделать, для получения ожидаемого результата.
Мдаааа, похоже эта нейросетка таки сможет выгнать на мороз куда больше херак-херак-и-в-продакшен маппетов чем ожидалось.
TB>Забыть поставить каст к более широкому типу — это тоже опечатка.
Очепяткой это было бы есди не к тому типу закастили.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>К тому что принципы как оно будет на самом деле выполняться надо таки понимать.
И каким образом понимание избавит от опечатки? Кульные какиры никогда не опечатываются?
CC>Ну т.е. тебе тут надо памперсы ChatGPT чтоб за погромиста не забывал сделать то, что надо сделать, для получения ожидаемого результата. CC>Мдаааа, похоже эта нейросетка таки сможет выгнать на мороз куда больше херак-херак-и-в-продакшен маппетов чем ожидалось.
Просто у меня хватает мозгов заметить, что на меня тоже распростреняется человеческий фактор.
CC>Очепяткой это было бы есди не к тому типу закастили.
Если компилятор ни слова не говорит про отсутствующий каст, то случайно забыть сделать каст может любой программист с любым опытом. Ну кроме кульного какира из 9Б, который никогда нигде не ошибается.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, T4r4sB, Вы писали:
TB>>Если компилятор ни слова не говорит про отсутствующий каст CC>Ну разишо если warnings игнорировать.
И какой же варнинг у тебя проявится при сложении двух u8? Или при вычитании двух usize?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>В том же русте не так. Ты можешь сложить числа 100 и 200, но если оба аргумента имеют тип u8, то компилятор тебе ничего не скажет. Типа всё ок. Но ты получишь падающую программу, из-за чего матерясь полезешь явно кастить оба аргумента к i32. Ну и нахрена оно надо, изначально-то чего в i32 не хранится?
А почему ты тут думаешь именно про i32? А вдруг и его переполнит, тогда оно должно было святым духом догадаться, что надо было конвертить всё к i64? Или как?
Сложили два int32_t, получим int33_t?
Перемножаем. Первое произведение int64_t, второе int96_t, третье int128_t... Астанавитесь(c), Вите надо выйти!
Я понимаю твой плач, но проблема в том, что при столкновении заведомо противоречивых требований между автопредставлением всех значений именно с нужным размахом — с реальными ограничениями используемых числовых типов — нужно выбирать какой-то компромиссный вариант, и это именно случай эскобара.
Можно 1) влупить в лоб сразу, как в Rust, 2) маскировать проблему подольше, как в C/C++, 3) уходить от неё ценой производительности, как в Python и Erlang. Возможно, ещё как-то можно.
В Rust хорошо, что, в отличие от C/C++, тебе явно показывают проблему и дают средства её решения прямым и легкопонятным способом.
Да, и вдогонку — а действительно, почему у тебя они в u8? Это же тип скорее для упаковки в структуру, чем для манипулирования. Во всех современных ABI всё равно будет один регистр занят, так что u8 или i32 — одномайственно.
Я видел кучу кода, где, например, берут из переменной типа u8 (uint8_t) количество элементов, а затем итерируют по нему опять же переменной типа u8. Это, да, безграмотно.
TB> Нахрен мне нужно ограничение, при котором предполагается, что промежуточный результат будет иметь те же ограничения, что и сами данные, если это вообще даже близко не так? И тогда зачем вообще ограничивать тип, когда проще все эти проверки делать в сеттере поля?
Повторюсь, в C с int или long то же самое. И вообще это ещё из Фортрана растёт, как минимум. Ничто не ново под луною.
Нахрена в нём два (минимум) уровня integral promotion — не знаю, оно таки сомнительно. Как и его ценность сейчас вообще. Но зачем его делали в далёких 70-х — очевидно.
TB>И получаем либу, с которой невозможно работать без часового курения документации.
Ну chrono это отдельная пейсТня.
TB> А по факту было бы достаточно одной-единственной функции, возвращающей число наносекунд с начала эпохи в виде примитивного типа i128 (знаковый, чтоб можно было вычитать два момента и не париться).
Но тут другое. С какой именно эпохи? Юниксовой (начало 1970 года) или виндовой (1601)?
А может, с "юлианского дня" номер 1, как сделали в Delphi?
К>>Долбаный хипстер ввёл Point, Vector и Rotation, а людям расхлёбывать, да? А может, людям за чистотой своих рук последить, прежде чем Point+Point или Point+Rotation делать, не?
Чем дальше в лес, тем толще партизаны код, тем сложнее следить за его качеством, включая 100500 аспектов, которые могут на него повлиять, и тем дороже каждое изменение. Поэтому средства поддержки в виде запрета некорректных операций — бесценны.
TB>Point+Point это нормальная операция, не надо её запрещать.
Надо.
TB>Пример с размерностями матрицы — это положительный пример внедрения гарантий времени компиляции. Полагаю, с таких примеров и начались хорошие идеи по возможности проконтролировать что-то заранее на уровне системы типов. Но заставь дурака богу молиться, и он сделает систему, в которой очень трудно написать что-то полезное.
TB>> Если абстракция протекает и из-за случайной опечатки это приводит к падающей программе, то это дыра в дизайне. CC>Ну т.е. тебе тут надо памперсы ChatGPT чтоб за погромиста не забывал сделать то, что надо сделать, для получения ожидаемого результата. CC>Мдаааа, похоже эта нейросетка таки сможет выгнать на мороз куда больше херак-херак-и-в-продакшен маппетов чем ожидалось.
Судя по принципиальному непониманию проблемы, кое-кто полетит одним из первых — потому что учёт всех обстоятельств в сложном коде это даже для человека с опытом неподъёмно, а такой сетке точно ещё лет 50 расти до нужного уровня.
Здравствуйте, T4r4sB, Вы писали:
S>>А насколько часто у вас встречаются диапазонные типы? Ну, так, если по-честному? TB>На Русте какой-то идиот ввёл для размера массива тип usize, мотивируя это тем, что ограничение >=0 "соответствует специфике домена", при этом на вопрос что делать если надо вычитать два размера, мне сказали "мне никогда это не надо было делать". Дальше разгорелся срач, я привёл пример с шахматной доской 256х256, и спросил, реально ли они ради дебильной идеи сраных доменов будут использовать u8, понимая, что тривиальные операции будет делать крайне геморройно, и они сказали что да.
Здравствуйте, netch80, Вы писали:
N>Судя по принципиальному непониманию проблемы, кое-кто полетит одним из первых
Куда проще заменять нейросеткой пейсателей на памперсных языках, где памперсы примут в себя все косяки нейросетки, чем там, где надо чётко понимать что ты делаешь.
Кстати интересно, осилит ли нейросетка написать double linked list на rust?
N> потому что учёт всех обстоятельств в сложном коде это даже для человека с опытом неподъёмно
Не в сложном коде а в говнокоде, где ни декомпозиции, ни дизайна, ни комментов, рубили вместе с будкой писали как попало.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
N>>Судя по принципиальному непониманию проблемы, кое-кто полетит одним из первых CC>Куда проще заменять нейросеткой пейсателей на памперсных языках, где памперсы примут в себя все косяки нейросетки,
Проще, да. Но такие языки ещё надо разработать (хм, интересное направление)
AMM+GC это слишком низкоуровнево.
А вот безразмерный int это уже ближе к вопросу.
CC> чем там, где надо чётко понимать что ты делаешь. CC>Кстати интересно, осилит ли нейросетка написать double linked list на rust?
Текущие — скорее нет, а зачем?
N>> потому что учёт всех обстоятельств в сложном коде это даже для человека с опытом неподъёмно CC>Не в сложном коде а в говнокоде, где ни декомпозиции, ни дизайна, ни комментов, рубили вместе с будкой писали как попало.
Перекуём баги на фичи!
)