Здравствуйте, netch80, Вы писали:

N>Давало возможность украсть то же самое, но в другом исполнении.
N>Например, банковский перевод с 1% комиссии. Переводят 114 долларов 50 центов. Округляем по банкирскому округлению — 1.14 комиссии. А софт берёт 1.15 и один цент уходит на спецсчёт "Корректировки технические".
N>Клиенту обычно пофиг — мало кто придерётся к одному центу на явно спорном округлении (ровно пол-цента, на границе), особенно если грамотно обученная техподдержка вусмерть заинструктирована рассказывать "у нас всё хорошо".
Так это политика банка, а не воровство.
А России принято 1.145 округлять именно до 1.15. Хотя нормативных установок по этому поводу нет. В данном случае нарушение не то, как округлено, а наличие какого-то непонятного "спецсчета". Если он является частной инициативой сотрудника, то будут мгновенно обнаружен бухгалтерскими методами. Если банка, то в общем случае это его дело.

N>Что программист почему-то имеет доступ к счёту "Корректировки технические" снимать с него деньги — никто не видит, потому что счёт называется странными цифрами, на которые всем пофиг.
Это из области сказок. Нет такого счета. Есть корректировочные проводки. Их бухгалтер видит, более того сам и делает. Если там появятся лишние обороты будет разбираться. Да, если бухгалтер сообщник, можно украсть что угодно (это конечно не так, бухгалтер обычно не один, еще бывают аудиторы) только округление к этому не имеет никакого отношения

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

Здравствуйте, Константин Б., Вы писали:

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

КБ>А какие ошибки могут быть от использования целых большей битности чем нужно? Вроде обычно наоборот — меньшая битность приводит к ошибкам.

Не "от большей битности" а вообще от отсутствия ограничений.

В некий интерфейс можно засунуть, например, число от 1 до 100. Для обострения ситуации предположим, что там байт, но уже 101 вызовет выход из платы белого дыма, без которого устройство откажется работать.

Если у вас тип описан как type foo = new integer 1..100; (почти синтаксис Ada) то проверка корректности присвоенного значения может быть (а если не запрещать — то будет) выполнена автоматически компилятором.
Если нет — очень легко допустить ошибку, а в толстом проекте она будет — к гадалке не ходи.

Вы скажете, что финальную проверку надо делать в момент передачи в железо? А там окажется, что код мог выполнить 500 разных мест, где сгенерировалось значение, и кто виноват — ХЗ, данных уже нет. Сидим вписываем проверки вручную в каждое место, где вычисляется, и на 20-м таком месте осознаём, что компилятор бы справился с этим проще и быстрее.

Не нравится железячная аналогия? Может быть куча других, где цвет на экране, где уровень налога, где возраст клиента, и тэ дэ и тэ пэ.

Чем больше таких проверок переложено на компилятор и чекеры, тем удобнее. Чем больше проверок выполняется в рантайме, тем безопаснее (хотя местами и медленнее). Идеал — все типы расписаны, все проверки включены кроме мест, где явно взята на себя ответственность не делать такие проверки, потому что автор кода дал зуб, поклялся матерью, написал проверяемое компилятором доказательство (случай Coq/Idris/etc.), или ещё как-то сформулировал гарантии

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

А вот конкретно какой-нибудь uint16_t это уже костыль дешманской реализации, в которой в половине случаев это просто формат хранения значения, а в половине — рукотворный костыль типа "0..1000 не лезет в 8 бит, но лезет в 16, возьму uint16_t".

Здравствуйте, pagid_, Вы писали:

N>>Давало возможность украсть то же самое, но в другом исполнении.
N>>Например, банковский перевод с 1% комиссии. Переводят 114 долларов 50 центов. Округляем по банкирскому округлению — 1.14 комиссии. А софт берёт 1.15 и один цент уходит на спецсчёт "Корректировки технические".
N>>Клиенту обычно пофиг — мало кто придерётся к одному центу на явно спорном округлении (ровно пол-цента, на границе), особенно если грамотно обученная техподдержка вусмерть заинструктирована рассказывать "у нас всё хорошо".
_>Так это политика банка, а не воровство.

Воровство — внутри банка.

_>А России принято 1.145 округлять именно до 1.15. Хотя нормативных установок по этому поводу нет. В данном случае нарушение не то, как округлено, а наличие какого-то непонятного "спецсчета". Если он является частной инициативой сотрудника, то будут мгновенно обнаружен бухгалтерскими методами. Если банка, то в общем случае это его дело.

Так в том и дело что кража была сотрудником у своего банка — а в случае СССР это означало кражу "социалистической собственности" что сразу поднимало статью.

N>>Что программист почему-то имеет доступ к счёту "Корректировки технические" снимать с него деньги — никто не видит, потому что счёт называется странными цифрами, на которые всем пофиг.
_>Это из области сказок. Нет такого счета.

Сейчас за последние надцать лет — да, сделать такое нереально.
Я ж потому с самого начала сказал — это истории 1970-х.

_>Что касается истории, то для оценки хотелось бы больше подробностей.

Вообще она гуглится, но я не хочу сейчас глубоко вкапываться. Поищу, но в ленивом режиме.

_> А в таком виде больше похоже на то, что учетную систему непонятно как и почему оторвали от бух.учета, а его полностью забросили. Тогда у администратора/программиста действительно возникают криминальные возможности, и игра с округлением их незначительная часть.

Бухучёт банка в это не лез, и не знаю, имеет ли он отношение к этому.

Здравствуйте, _typhoon, Вы писали:

_>2 Сложность вычисления по операциям сложения увеличиться в 8 раз, умножение столбиком в 64 ,по Карацубы конечно меньше но то же возрастет ощутимо.

этот момент вызывает сомнения. Всё равно данные перед умножением/сложением запихиваются в 64-битный регистр. К тому же выделение н-р 3 байта из 8-байтового куска также будет бить по производительности. Пересылка данных между кешем и процессором ведь также идёт по шине в 64 бита. В общем, держать всё в 64 битах может оказаться даже лучше для производительности.

Здравствуйте, sergii.p, Вы писали:

SP>этот момент вызывает сомнения. Всё равно данные перед умножением/сложением запихиваются в 64-битный регистр. К тому же выделение н-р 3 байта из 8-байтового куска также будет бить по производительности. Пересылка данных между кешем и процессором ведь также идёт по шине в 64 бита. В общем, держать всё в 64 битах может оказаться даже лучше для производительности.

В целом наверно так. Но не факт, что в x64 команды с 64-разрядными операндами выполняются быстрее 32-разряных, может так же, а может медленнее, если про сложение с вычитанием, пересылки надо полагать так же, а уж умножение и деление уверен, что медленнее.

Здравствуйте, netch80, Вы писали:

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

Хорошая шутка.

Здравствуйте, netch80, Вы писали:

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

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

Здравствуйте, Alekzander, Вы писали:

A>А если серьёзно. Это хорошая шутка, но плохой аргумент. Если у тебя чип горит от 101, надо использовать специальный mocking-чип, у которого от 101 горит только лампочка на крышке и активно использовать автотесты, а не возлагать всю полноту ответственности на компилятор и чекеры.

Это, видимо, был намек на https://en.wikipedia.org/wiki/Smoke_testing_(software)

Здравствуйте, Shmj, Вы писали:

S>Умно?

Не особо. Язык/рантайм не умеющий в byte[] становится существенно ограниченным.

Здравствуйте, Alekzander, Вы писали:

A>Хорошая шутка.
У этой шутки уже давно вооот такенная борода, цвета того самого дыма.

Здравствуйте, netch80, Вы писали:

N>Сидим вписываем проверки вручную в каждое место, где вычисляется, и на 20-м таком месте осознаём, что компилятор бы справился с этим проще и быстрее.

Открой для себя С++ где ты можешь себе сделать такой тип сам, с любыми проверками
Возможно уже даже в std завезли какой нить готовый template.
И он будет работать везде автоматически, никаких вписываний проверок вручную.

Здравствуйте, CreatorCray, Вы писали:

N>>Сидим вписываем проверки вручную в каждое место, где вычисляется, и на 20-м таком месте осознаём, что компилятор бы справился с этим проще и быстрее.

CC>Открой для себя С++ где ты можешь себе сделать такой тип сам, с любыми проверками

"Ватсон, это был программист".

Здравствуйте, Alekzander, Вы писали:

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

A>А если серьёзно. Это хорошая шутка, но плохой аргумент. Если у тебя чип горит от 101, надо использовать специальный mocking-чип, у которого от 101 горит только лампочка на крышке и активно использовать автотесты, а не возлагать всю полноту ответственности на компилятор и чекеры.

Шутка не моя, да, и ей лет 15 минимум. Может, ещё советских времён. Но она тут в тему.

В вашей реплике есть принципиальная ошибка и подтасовка: с чего вы взяли, что я собрался этими методами возложить "_всю_ полноту ответственности" на компилятор и чекеры? Разумеется, тесты будут. Скорее, конечно, не с "mocking чипом", а с mocking HAL: перехват будет минимум в функции, которая собственно делает запись в регистры или что там вместо них. А если дадут возможность (буду активно пинать) — и в реальном HAL, если такая проверка не будет в разы дороже самой записи.

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

Здравствуйте, _typhoon, Вы писали:

S>>Что скажете?
_>Это очень плохо. по сравнению с однобайтеыми данным обработка 8 байтных данных даст следующие увеличения

Сравнивать надо, скорее всего, с 32-битными вариантами, потому что integral promotion в C, а int на таких платформах 32 бита.
Языки где этого integral promotion нет уже есть в ходу (Rust, Go), но подложек рантайма на них пока крайне мало.

_>1 Бинарные файлы и занимаемый объем оперативной памяти будут в 8 раз больше.

Непонятно, что такое "бинарные файлы" тут.

_>2 Сложность вычисления по операциям сложения увеличиться в 8 раз, умножение столбиком в 64 ,по Карацубы конечно меньше но то же возрастет ощутимо.

Упоминание Карацубы тут крайне странно.
В текущем GMP на x86-64, например, переход к нему (точнее, к Тоому-Куку 2*2, но считаем эквивалентным) начинается от 27 лимбов, то есть от 216 бит. До этого "столбиком" ("schoolbook") считается эффективнее. Да, это цена out-of-order, кэшей и т.п.

_>В общем приложения написанные на этом языке при большых массивах мелких чисел будут тормозить на приведенные выше порядки значения.

Я сталкивался с кодом, который работал с текстом через 32-битные целые в силу ограничений языка (стандартный Фортран, без LOGICAL*1, CHARACTER и прочих более поздних фишек). Красиво не было, были игры с битами и масками. Но работало. С текущей скоростью оперативной памяти это даже будет не настолько большой задержкой, процессор быстрее памяти раз в 200.

Здравствуйте, vsb, Вы писали:

vsb>Мне нравится, как в JS сделали. float64 без вариантов.

Они даже это сделать не сумели.
Битовые операции в JS выполняются после конверсии в int32_t, с автоокруглением.

Здравствуйте, netch80, Вы писали:

vsb>>Мне нравится, как в JS сделали. float64 без вариантов.

N>Они даже это сделать не сумели.
N>Битовые операции в JS выполняются после конверсии в int32_t, с автоокруглением.

А что в этом плохого? Какие альтернативы?

Здравствуйте, CreatorCray, Вы писали:

A>>Хорошая шутка.
CC>У этой шутки уже давно вооот такенная борода, цвета того самого дыма.

Специально хотел написать: "Лично я раньше не слышал", но потом решил, что умные люди и так догадаются.

Здравствуйте, netch80, Вы писали:

N>В вашей реплике есть принципиальная ошибка и подтасовка

Вот как удивительно: а я увидел подстасовку в приведении такого примера, где ошибку совершать нельзя. И показал в ответ, как это обойти.

А вообще, тезис в том, что (ИМХО) не надо на компиляцию возлагать больших надежд, связанных с проверкой корректности функционирования программы. Что может проверить компилятор? Соответствие грамматике и т.п. К правильному функционированию это имеет оооооочень опосредованное отношение. Чекеры это уже лучше, это уже тесты, хоть и чисто модульные. А основные выводы о готовности к проду надо делать по результатам интеграционных.

А поскольку я сторонник подхода, что если что-то работает ненадёжно, то и использовать это не надо (идея та же, по которой люди запрещают security through obscurity), я считаю, что не стоит использовать все эти a: int 1..100 ни для чего, кроме как для декларации о намерениях (а вот для этого — надо). По сути, можно в имени или комментарии то же написать, но просто менее удобно. Ну, ещё логгер нарушений для дебажной версии, раз он всё равно халявный, но чисто для удобства отладки, не для выяснения, есть ли ошибки.

Здравствуйте, CreatorCray, Вы писали:

CC>Открой для себя С++ где ты можешь себе сделать такой тип сам, с любыми проверками
CC>Возможно уже даже в std завезли какой нить готовый template.
CC>И он будет работать везде автоматически, никаких вписываний проверок вручную.

А не подскажете, дяденька, C++, случайно, не Тьюринг-полный язык?

P.S. Ещё можно понять рекомендацию языка с синтаксическими макросами, где генерация типа с любыми проверками (1..100) идёт на лету, но C++ с его ручными проверками, в которых лучшая реализация is_in_set сделана на шаблонах...

Здравствуйте, Alekzander, Вы писали:

CC>>Открой для себя С++ где ты можешь себе сделать такой тип сам, с любыми проверками
CC>>Возможно уже даже в std завезли какой нить готовый template.
CC>>И он будет работать везде автоматически, никаких вписываний проверок вручную.

A>А не подскажете, дяденька, C++, случайно, не Тьюринг-полный язык?

A>P.S. Ещё можно понять рекомендацию языка с синтаксическими макросами, где генерация типа с любыми проверками (1..100) идёт на лету, но C++ с его ручными проверками, в которых лучшая реализация is_in_set сделана на шаблонах...

А какая разница, если на выходе получается ровно код проверки при укладке в переменную?

Другой вопрос, что CC почему-то решил поадмиральствовать там, где C++ никак не обязателен и может и не подходить по 100500 причин...