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

vsb>>Мне нравится, как в JS сделали. float64 без вариантов...
Ф>надеюсь это шутка.

Весь JS, целиком — это шутка. Но очень тонкая шутка, большинство его всерьез воспринимают, увы.

Мне нравится, как в JS сделали. float64 без вариантов. Не знаю, кому нужны 64-битовые целочисленные значения, мне не нужны.

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

S>Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком: https://dart.dev/language/built-in-types

S>Умно?

Так себе.
Выше умные люди уже привели аргументы.

S>Кто-то сразу начнет возражать, что, мол, если будет 1 млрд. записей и в каждой записи число, которое можно было бы сохранить в файл в виде 8 бит, а вместо этого вы потратили 64 бит — то потратим много лишних гигабайт.

Я возражу. Помимо сериализации ещё есть и оперативная память. Нафига создавать семикратный оверхед на ровном месте?

S>Однако же при сериализации/сохранении можно применять спец. атрибуты — это отдельный вопрос. В самой же проге все-равно проще и удобнее оперировать, когда все целые числа имеют одинаковую битность и знаковость.

S>Что скажете?

В одном из проектов мы использовали трюк с разным размером типа данных для ограничения бесплатной демо-версии программы.
В демо-версии максимальное число объектов было ограничено 125 — однобайтный знаковый тип (127 с учётом спецзначений). А в полнофункциональной версии этот тип был 4-байтным.
Было очень увлекательно читать на профильных форумах, как народ пытается отломать ограничения

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

S>Тип меньшего размера чем 64 бит нужны, только если структурв типа record не выравнивают внутреннее представление на 8 байт для 64-разрядного приложения или на 4 байта для 32-разрядного. В противном случае все равно переменная займет 8 байт.
Бывает не только record, но и банальный массив

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

Ой, начался нитпикинг. Давай я тебе сразу поясню кое-что. На ваш этот C++ мне, в целом, наплевать. Пациент всё равно скорее мёртв, чем жив. (Я имею в виду не C/C++ или C++/Qt или ещё что-то, на чём пишут вменяемые разработчики, а настоящий C++ с религией const, наиболее упоротыми конструкциями из std и шаблонным метапрограммированием). На что мне не плевать — это когда вчерашние плюсовики приходят в JS и начинают лепить из него Typescript, потому, что верят в то, что без компилятора у них ошибок будет больше. Хотя с виртуальной машиной там и ошибок-то таких не бывает, как в сях. Поэтому когда я вижу, как кто-то предлагает на компилятор наложить ещё больше проверок, я автоматически триггерюсь. Тесты, тесты, тесты.

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

N>Но народ на JS вообще видеокодеки пишет.
Проблема в том, что езыг, который никогда не проектировался быть полноценным, всякие вьюноши со взором горящим начали использовать как тот самый молоток и забивать им всё подряд.

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

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

A>Ой, начался нитпикинг.



A> На что мне не плевать — это когда вчерашние плюсовики приходят в JS и начинают лепить из него Typescript, потому, что верят в то, что без компилятора у них ошибок будет больше.

Чего "верить", это реальность.

A> Хотя с виртуальной машиной там и ошибок-то таких не бывает, как в сях.

Ну да, там другие ошибки:



Зато не вылетает, продолжает куда-то ехать.

A> Поэтому когда я вижу, как кто-то предлагает на компилятор наложить ещё больше проверок, я автоматически триггерюсь.

Ещё больше чем TypeScript?

A> Тесты, тесты, тесты.

Халва, халва, халва.

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

S>нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком
S>Умно?

Скорее очень глупо.

S>Однако же при сериализации/сохранении можно применять спец. атрибуты — это отдельный вопрос.
S>Что скажете?

Ну то есть тебя не волнует, что в худшем случае придётся купить в 8 раз больше оперативки. По процессору тоже непонятно, как такое воспринимают различные архитектуры.

К тому же нет гарантий, что не понадобятся битовые поля или наоборот числа большей разрядности, например, 128, 256 и так далее. То есть идея я так понимаю просто слить в унитаз инструкции процессора, которые всё равно там будут пользуешься лично ты ими или нет.

Я считаю одним из весомых недостатков C/C++ является то, что разрядность типа int не определена для разных компиляторов. Изначально не нужно было делать такой тип, должен был быть int8, int16, int32, int64, ... , uint8, uint16, uint32, uint64.

Не нужно было делать никаких char, short, long, long long и прочего. Потому в C/C++ каждая вменяемая библиотека извращается создавая свои типы пытаясь скомпенсировать этот недостаток.

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

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

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

vsb>Мне нравится, как в JS сделали. float64 без вариантов. Не знаю, кому нужны 64-битовые целочисленные значения, мне не нужны.
единственный адекватный ответ в треде

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

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

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

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

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

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

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

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

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

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

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

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

S>Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком: https://dart.dev/language/built-in-types

S>Что скажете?

Вообще стоит упомянуть https://api.dart.dev/stable/3.0.5/dart-typed_data/dart-typed_data-library.html
А то местные сишники уже напридумывали себе всякого. Им же такое и в голову прийти не могло.

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

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

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

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

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

S>Так добавили ж уже:

S>int8_t
S>int16_t
S>int32_t
S>int64_t

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

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

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

Z>>>1. Свойство, что все числа данного типа это неотрицательные довольно часто нужно,

TB>>Это где же? Для индексов и размеров оно вредит. Для битовых операций?

A>Как и включенные поворотники, тип uint не предсказывает, куда повернёт машина, и даже не говорит, что в голове у человека на самом деле. Он показывает, что человек хотел сказать окружающим. Тем и ценен.

А еще он создает кучу гемора, не отлавливаемого компилятором со всеми варнингами, когда размер или индекс участвует в формуле где есть такая казалось бы невинная операция вычитания. Нафиг. Показывать ограничения на результат надо другими способами.

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

S>Умно?

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

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

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

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

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

S>>>Что скажете?
O>>LEB128 тогда уже. Чтоб наверняка.
S>Это пока кто-нибудь SHA не захочет в него засунуть.
128 в LEB128 это не о том, что числа в нем 128 битные, а о том, что бит 128 в октете означает 'продолжение' числа на дополнительный октет. Фактическая битность не ограничена.

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

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

N>>На самом деле тут вообще ещё вопрос, при чём тут тьюринг-полнота языка на фазе трансляции, когда проверки всё равно надо впихивать в рантайм. Но если мы не сойдёмся по сказанному выше, то этот вопрос поднимать смысла нет.
S>Тут интереснее возможность не впихивать в рантайм избыточные проверки.
S>Например, при присванивании из RangeInteger<10, 20> в RangeInteger<5, 30> никакие проверки делать не надо.
S>В простых случаях вида RangeInteger<10, 50> a = 42; компилятору легко — после разворачивания шаблона сравнения if(42<10) будут выброшены.
S>А вот как отследить инварианты через границу двух разных типов?

Это как раз уже делается на существующих на данный момент средствах.
Clang имеет __builtin_assume(), который как раз говорит "считай данное условие гарантированным со стороны кодера". GCC (и Clang для совместимости) имеет __builtin_unreachable(), через который assume делается так:

#define assume(x) {if(!x) __builtin_unreachable(); }

И оптимизатор тоже умеет отбрасывать лишние проверки на таком основании.

Для такого RangeInteger мы можем написать

template <int Min, int Max> class RangeInteger {
  ...
  operator underlying_int_t() const {
    if (mValue < Min) {__builtin_unreachable();} // или __builtin_assume(mValue >= Min);
    if (mValue > Max) {__builtin_unreachable();} // или __builtin_assume(mValue >= Max);
    return mValue;
  }
};

Главное не забыть делать реальные проверки при присвоении (в конструкторе, operator=, где ещё надо — ты в курсе).

В твоём примере типа

RangeInteger<10, 20> i1;
...
RangeInteger<5, 30> i2 = i1;

компилятор получит гарантии 10 <= i1.mValue <= 20, и выкинет лишние проверки при присвоении i2.

Переносилось ли это в какие-то другие компиляторы (хоть в MSVC) — я не узнавал.

S>Что скажете?
LEB128 тогда уже. Чтоб наверняка.

S>Умно?
Очередные юные оболтусы изобрели революционную идею что грамотность и ПДД опыт предков устарел и не нужен.

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

S>Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком: https://dart.dev/language/built-in-types

S>Умно?

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

S>Что скажете?

Тип меньшего размера чем 64 бит нужны, только если структурв типа record не выравнивают внутреннее представление на 8 байт для 64-разрядного приложения или на 4 байта для 32-разрядного. В противном случае все равно переменная займет 8 байт.
Как без такой возможности писать высокоэффективные приложения с умеренным потребленем памяти, я не понимаю.

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


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

S>Что скажете?

1. Свойство, что все числа данного типа это неотрицательные довольно часто нужно,
и соответственно заставлять для этого заводить какой-то новый тип, я бы не назвал удобным

2. Кэш процессора на данный момент это один из ключевых факторов производительности,
и невозможность впихнуть туда больше чисел удручает

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

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

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

S>Так добавили ж уже:

S>int8_t
S>int16_t
S>int32_t
S>int64_t

S>https://en.cppreference.com/w/cpp/types/integer

Это не встроенные фундаментальные типы, а алиасы. Разница, хотя бы, в том, что для встроенных типов не надо тащить #include <cstdint>. Что подходит под определение "в C/C++ каждая вменяемая библиотека извращается создавая свои типы пытаясь скомпенсировать этот недостаток".

vsb>Мне нравится, как в JS сделали. float64 без вариантов. Не знаю, кому нужны 64-битовые целочисленные значения, мне не нужны.
А на округлениях можно и денег спереть — правда после по статье в тюрьму отправиться.

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

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

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

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

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

Просто "обойти" было и так очевидно, как. А вот чтобы это было эффективно для кодирования, отладки и сопровождения — уже нет.

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

Очень многое.

A> Соответствие грамматике и т.п. К правильному функционированию это имеет оооооочень опосредованное отношение.

Если компилятор запрещает присвоение числа строке или числу строки, это "соответствие грамматике" или таки "правильное функционирование"?
А мало какой язык такое разрешит.
Значит, проверка типизации возможна и полезна. Почему бы её не расширить?

A> Чекеры это уже лучше, это уже тесты, хоть и чисто модульные. А основные выводы о готовности к проду надо делать по результатам интеграционных.

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

A>А поскольку я сторонник подхода, что если что-то работает ненадёжно, то и использовать это не надо

А оно работает ненадёжно? Это где и когда?

A> (идея та же, по которой люди запрещают security through obscurity),

Не вижу связи.

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

Я надеюсь, с таким подходом вы ничего серьёзного не разрабатываете...

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

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

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

N>>Тьюринг-полнота ни при чём.

A>Да неужели. Когда сравнивают два языка, один из которых хорошо подходит для некоторой фичи, а второй — плохо, а потом кто-то говорит, что оба они, В ПРИНЦИПЕ, одно и то же, то этот "принцип" есть принцип Тьюринга и ничто другое.

CreatorCray сказал, что можно самому построить такой шаблон. Про Тьюринг-полноту ты сам зачем-то ввернул в эту ветку обсуждения, там этого не было. Вот я и не понимаю, почему.

A>И к чему тут этот ужас? Думаешь, никто не знает, как это программировать при помощи сиплюсплюсных шаблонов?

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

A>Есть языки, где ты можешь САМ сделать синтаксис вида a : int 1..100 (или более интуитивный) с генерацией алиаса на тип с чекерами, даже если bounds на уровне языка никак не представлены.

Верю. И это тоже само по себе не тьюринг-полнота.

A> Я удивился, почему было не предложить открыть для себя именно такой язык. Почему C++, где всё подтыкают шаблонами (за неимением синтаксических макросов). Будем по третьему разу мусолить, или хватит уже, наконец?

Я не заинтересован ни в каком мусолении, действительно, если ты не хочешь признавать очевидного, то разговор дальше неинтересен.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

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

НС>>>И наличие таких костылей как бэ намекаэ, что очень зря избавились от целых типов разной размерности.
КБ>>Или наоборот ворох целых типов — костыль.

НС>Это не костыль, это реальность. И попытка на нее натянуть очередную leaky abstraction ни к чему хорошему не приводит.

Практикой не подверждается. От кучи целых типов на практике проблем больше.

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

НС>>Это не костыль, это реальность. И попытка на нее натянуть очередную leaky abstraction ни к чему хорошему не приводит.

КБ>Практикой не подверждается. От кучи целых типов на практике проблем больше.

Продемонстрируйте свою практику, пожалуйста.

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

A>>>> Хотя с виртуальной машиной там и ошибок-то таких не бывает, как в сях.
N>>>Ну да, там другие ошибки:

N>>>[--url=https://cs9.pikabu.ru/post_img/2016/09/14/8/1473858812151073022.jpg]Image: 1473858812151073022.jpg[/url]

A>>Насколько я помню, ты достаточно низкоуровневый разработчик с большим опытом. И ты при этом не понимаешь, что это *на самом деле* другая ошибка? Что-то тут не сходится. Знаешь, что такое неделю искать, где у тебя память испортилась?

N>Знаю. Где-то и несколько месяцев (не подряд).
N>Да, другая ошибка. И думаешь, она всегда легко ищется?

"Легко" это понятие относительное. Я написал, что "там и ошибок-то таких не бывает", имея в виду два принципиально разных класса этих самых ошибок.

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

А ошибка того типа, что на картинке, ловится автотестами. Если она прошла через автотесты, значит они не покрывали какой-то важный кейс. Значит, надо дописать. Это в принципе МОЖНО сделать. В отличие от.

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

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

N>>Да, другая ошибка. И думаешь, она всегда легко ищется?

A>"Легко" это понятие относительное. Я написал, что "там и ошибок-то таких не бывает", имея в виду два принципиально разных класса этих самых ошибок.

A>Принципиальная разница тут в следующем. Порчу памяти ты автотестами не поймаешь. Она же может оказаться плавающая.

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

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

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

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

В языке без усиленного контроля (как Rust с его borrow checker) хрен там чем грамматики с компилятором помогут. Все семантические проблемы лежат сильно выше.

A>А ошибка того типа, что на картинке, ловится автотестами.

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

Или ситуацией типа — послали API запрос к серверу, тот сказал что-то типа "402 хреново мне от вашей чрезмерной нагрузки", а клиентской стороне пофиг, что переменные не инициализированы и содержат undefined.

Я даже уверен, что вариант с API многократно воспроизводился в реале с примерно такими же последствиями.

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

A> Если она прошла через автотесты, значит они не покрывали какой-то важный кейс. Значит, надо дописать. Это в принципе МОЖНО сделать. В отличие от.

Не "в отличие от", см. выше. Меняется специфика и стиль, может резко отличаться цена, но нет принципиальной разницы в самой возможности.

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

Потому что сам масс-кодинг с платформой, в которой тебе даже самые тупые ошибки обычно не приводят к потере управляемости, выстрелил с Java. JavaScript и C# догнали через несколько лет.

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

S>Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком: https://dart.dev/language/built-in-types

S>Умно?

Тут в соседнем топике

Автор: Евгений Музыченко
Дата: 05.05.20

на протяжении уже 400 сообщений на серъезных щах спорят нужно ли использовать знаковые целые или беззнаковые.
Один целый тип — это не просто умно. Это гениально.

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

N>Какого размера должен быть этот тип, чтобы гениально закрыть все проблемы?
Безразмерного, видимо

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

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

КБ>>>Тут в соседнем топике

Автор: Евгений Музыченко
Дата: 05.05.20

на протяжении уже 400 сообщений на серъезных щах спорят нужно ли использовать знаковые целые или беззнаковые.
КБ>>>Один целый тип — это не просто умно. Это гениально.

N>>Какого размера должен быть этот тип, чтобы гениально закрыть все проблемы?

КБ>Неограниченного конечно.

А в Dart, с которого началось обсуждение, он 64-битный. Непорядок-с.

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

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

_>>Насколько помню со времени банковской работы, при конвертации валют погрешности округления идут либо на спецсчет доходов или расходов банка. И так и так бывает, как получится.
_>Откуда там погрешности округления? Если на счетах все валюты будут с точностью до копеек, центов, а не их долей. В доходы/расходы идут курсовые разницы.

Вот я сейчас глянул курс — 36.5686.
Конверчу 30$ — получаю 1097.058 грн в идеале — но на счёт попадёт или 1097.05, или 1097.06.

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

N>Это ты так думаешь. А учёт может думать иначе.
Так думают закон, а вслед за ним люди занимающиеся учетом и создающие учетные программы.

N>Вот пусть банк округлил мне до 1097.06. Пусть прошло 1000 таких покупателей по 30$. В сумме банк выдал продавцам валюты 1097060 грн.
N>Но в учёт операций должна была пойти продажа 30000$, которые по этому курсу 1097058 грн.
Нет, в учете пройдет 1097060 грн., но никак иначе. Сумма операций это и именно сумма операций, а не одна, по какому-то курсу. Он несколько раз на дню может меняться.
И никому она быть 1097058 не должна.

N>Получается, банк переплатил 2 гривны.
Не получается.

N>Оно конечно мелочи, но учёт должен сойтись ровно в 0. И вот тут начинается вопрос, а какая из практик бухучёта применяется и что она требует.
С общей 30000$ умноженным на курс? Нет, не должен. Никого в учете не интересует сколько будет, если 30000$ умножить на курс. Интересует и является учитываемой величиной сумма валютных операций (переведенных между счетами денег) за период.

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

Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком: https://dart.dev/language/built-in-types

Умно?

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

Что скажете?

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

S>Что скажете?

Смотря для какого языка. Так делать нельзя, если:
— язык должен иметь возможность получать доступ к железу;
— язык предполагает парсинг и сериализацию бинарных данных/файлов/протоколов.

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

V>Не нужно было делать никаких char, short, long, long long и прочего. Потому в C/C++ каждая вменяемая библиотека извращается создавая свои типы пытаясь скомпенсировать этот недостаток.

Так добавили ж уже:

int8_t
int16_t
int32_t
int64_t

https://en.cppreference.com/w/cpp/types/integer

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

vsb>>Мне нравится, как в JS сделали. float64 без вариантов...
Ф>надеюсь это шутка.

The JavaScript Number type is a double-precision 64-bit binary format IEEE 754 value, like double in Java or C#.
...
Integers can only be represented without loss of precision in the range -2^53 + 1 to 2^53 — 1, inclusive (obtainable via Number.MIN_SAFE_INTEGER and Number.MAX_SAFE_INTEGER), because the mantissa can only hold 53 bits (including the leading 1).

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number

Или шутка, что нравится?

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

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


Z>1. Свойство, что все числа данного типа это неотрицательные довольно часто нужно,

Это где же? Для индексов и размеров оно вредит. Для битовых операций?

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

Z>>1. Свойство, что все числа данного типа это неотрицательные довольно часто нужно,

TB>Это где же? Для индексов и размеров оно вредит. Для битовых операций?

Как и включенные поворотники, тип uint не предсказывает, куда повернёт машина, и даже не говорит, что в голове у человека на самом деле. Он показывает, что человек хотел сказать окружающим. Тем и ценен.

А InvalidValue надо явно задавать, через тот же 0xf..f. Или пользоваться исключениями/кодами возврата. Или типами с ? на конце.

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

S>Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком

то что все целые 64 бита — это неправильно. С обработкой двоичных протоколов передачи данных будет неудобно (хотя может Dart на это не рассчитан).

Насчет того что все целые — знаковые... лично мне это нравится. И в джаве мне эта идея сразу понравилась, пока я не узнал что оказывается оператор >>> нормально работает только с int :(

например в джаве после такого:

 byte b=(byte)0xff;
 b>>>=1;

переменная b всё равно будет равна 0xff.

Получается смысл в >>> теряется для всех кроме int и возникают неудобства при обработки байтов в некоторых двоичных протоколах.
Почему они не сделали >>> для byte и short не понимаю

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

Z>>>>1. Свойство, что все числа данного типа это неотрицательные довольно часто нужно,

TB>>>Это где же? Для индексов и размеров оно вредит. Для битовых операций?

A>>Как и включенные поворотники, тип uint не предсказывает, куда повернёт машина, и даже не говорит, что в голове у человека на самом деле. Он показывает, что человек хотел сказать окружающим. Тем и ценен.

TB>А еще он создает кучу гемора, не отлавливаемого компилятором со всеми варнингами, когда размер или индекс участвует в формуле где есть такая казалось бы невинная операция вычитания. Нафиг. Показывать ограничения на результат надо другими способами.

Это надо смотреть на конкретном примере. Правильно ли был выбран uint в данном случае? Правильно ли были записано присваивание? И т.д.

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

A>Это надо смотреть на конкретном примере. Правильно ли был выбран uint в данном случае? Правильно ли были записано присваивание? И т.д.

Уинт был выбран неправильно но не мной, он вшит в язык намертво.
Присваивание конечно неправильно. Пишу тупо a=b вместо a=b as isize.

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

S>Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком: https://dart.dev/language/built-in-types

В JS даже и дальше пошли — там на все про все — 64-битное число с плавающей точкой.

S>Умно?

Ну, Dart — не язык для системного программирования. Так что это вполне разумный ход для упрощения написания программ.

S>Что скажете?

Посоветовался со своей собакой. Мы сошлись на том, что надо сказать "гав!".

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

V>А на округлениях можно и денег спереть — правда после по статье в тюрьму отправиться.
А вот это миф.

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

S>Что скажете?
Изучи историю вопроса почему int такой какой он есть. Наверное для языков типа Dart размер int не играет роли т.к. он выполняется на своей VM.

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

S>Что скажете?
Это очень плохо. по сравнению с однобайтеыми данным обработка 8 байтных данных даст следующие увеличения
1 Бинарные файлы и занимаемый объем оперативной памяти будут в 8 раз больше.
2 Сложность вычисления по операциям сложения увеличиться в 8 раз, умножение столбиком в 64 ,по Карацубы конечно меньше но то же возрастет ощутимо.
В общем приложения написанные на этом языке при большых массивах мелких чисел будут тормозить на приведенные выше порядки значения.

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

S>Умно?

Нет.
Умно — это когда есть возможность писать, например,

type forecast_temperature = new integer -70..+60;

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

S>В самой же проге все-равно проще и удобнее оперировать, когда все целые числа имеют одинаковую битность и знаковость.

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

S>Что скажете?

Да ты и сам всё знаешь. Просто увидел фигню и решил пошуметь.

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

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

V>>А на округлениях можно и денег спереть — правда после по статье в тюрьму отправиться.
_>А вот это миф.

Это не миф, это реальные случаи. Но последний такой был лет 40 назад, с тех пор такое за пределами фирмочки уровня 2 продавана и 1 кассир — практически нереально.

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

N>Это не миф, это реальные случаи. Но последний такой был лет 40 назад, с тех пор такое за пределами фирмочки уровня 2 продавана и 1 кассир — практически нереально.

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

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

N>>Это не миф, это реальные случаи. Но последний такой был лет 40 назад, с тех пор такое за пределами фирмочки уровня 2 продавана и 1 кассир — практически нереально.

Z>Ну я по крайней мере два раза за последние 5-7 лет встречал "гениев" которые хотели использовать числа с плавающей
Z>запятой для денежных расчетов.

Я не про это, а про использования именно округления как средства обогащения.

А фиксированная точка сама по себе от ошибок не спасает, когда не поддерживается финансовая дисциплина. Пусть при НДС 20% цена в 9.99 неважно чего (доллары, фунты, гривны, рубли) делится на цену до НДС и сумму НДС. Если каждую половину округлить независимо, то в зависимости от правила округления получим или 8.32 и 1.66, или 8.33 и 1.67. Опаньки.
Единственный рабочий вариант — последняя часть слагаемого получается вычитанием остальных — тогда уже не так важно куда пойдёт плюс-минус копейка, если сумма корректна.

S>100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64)
S>Что скажете?

Тебе разве запрещают использовать int64_t для хранения любых целых чисел? Или отсутствие выбора лучше чем его наличие?

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

M>Тебе разве запрещают использовать int64_t для хранения любых целых чисел? Или отсутствие выбора лучше чем его наличие?

Так еще и преобразования придется делать, если используете стороннюю либу.

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

N>Это не миф, это реальные случаи.
Миф, миф.
Правда есть один момент, который ставит под сомнение категоричность. Когда-то очень давно, где-то, но не в англоязычных источниках видел, что якобы в США принято хранить денежные суммы с точностью до сотой доли цента. Правда ли это в целом, или только исторически или совсем неправда не знаю, но вот такая особенность возможно дает шанс на криминальную игру с округлением.

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

Z>Ну я по крайней мере два раза за последние 5-7 лет встречал "гениев" которые хотели использовать числа с плавающей
Z>запятой для денежных расчетов.

И что?

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

N>А фиксированная точка сама по себе от ошибок не спасает, когда не поддерживается финансовая дисциплина. Пусть при НДС 20% цена в 9.99 неважно чего (доллары, фунты, гривны, рубли) делится на цену до НДС и сумму НДС. Если каждую половину округлить независимо, то в зависимости от правила округления получим или 8.32 и 1.66, или 8.33 и 1.67. Опаньки.
N>Единственный рабочий вариант — последняя часть слагаемого получается вычитанием остальных — тогда уже не так важно куда пойдёт плюс-минус копейка, если сумма корректна.

Все верно, так и есть. Только это не дает возможность украсть эту копейку.

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

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

N>>А фиксированная точка сама по себе от ошибок не спасает, когда не поддерживается финансовая дисциплина. Пусть при НДС 20% цена в 9.99 неважно чего (доллары, фунты, гривны, рубли) делится на цену до НДС и сумму НДС. Если каждую половину округлить независимо, то в зависимости от правила округления получим или 8.32 и 1.66, или 8.33 и 1.67. Опаньки.
N>>Единственный рабочий вариант — последняя часть слагаемого получается вычитанием остальных — тогда уже не так важно куда пойдёт плюс-минус копейка, если сумма корректна.

_>Все верно, так и есть. Только это не дает возможность украсть эту копейку.

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

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

N>>Это не миф, это реальные случаи.
_>Миф, миф.
_>Правда есть один момент, который ставит под сомнение категоричность. Когда-то очень давно, где-то, но не в англоязычных источниках видел, что якобы в США принято хранить денежные суммы с точностью до сотой доли цента. Правда ли это в целом, или только исторически или совсем неправда не знаю, но вот такая особенность возможно дает шанс на криминальную игру с округлением.

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

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

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

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

Здравствуйте, 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 битах может оказаться даже лучше для производительности.

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

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

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

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

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

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

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

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

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

Здравствуйте, 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, с автоокруглением.

Здравствуйте, 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 причин...

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

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

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

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

vsb>А что в этом плохого?

Ну, например, что в double 53 бита целых, а урезают до 32. Нелепица какая-то.

vsb> Какие альтернативы?

Постановить выполнение этих операций в тех же 53 битах, например.

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

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

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

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

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

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

Ну ладно, шаблоны это всё-таки нечто промежуточное. Т.е. рекомендовать открыть для себя C++ в данной ситуации это всё-таки лучше, чем, например, ассемблер.

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

vsb>>А что в этом плохого?

N>Ну, например, что в double 53 бита целых, а урезают до 32. Нелепица какая-то.

vsb>> Какие альтернативы?

N>Постановить выполнение этих операций в тех же 53 битах, например.

Для чего тебе вообще нужны битовые операции?

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

Ну некоторые упоротые заменяют Math.trunc на ||0 или деление на сдвиг, но я считаю это кулхацкерской дуростью.

Эти юз-кейсы в основном покрываются 1/2/4 байтами.

Где мне были бы полезны битовые операции в 53 бита, я вообще представить не могу. Ну можно придумать, типа приходят 7 байтов, и в них 53 бита значащие , но это явно будет придумка.

В общем я не убеждён, что это плохой дизайн. Свою задачу он решает. Как работает V8 и как он обеспечивает быстрое выполнение подобного кода, я не вполне представляю и если для поддержки 53 битов придётся сильно пожертвовать производительностью в 32 битах, тогда это плохой вариант. Если можно поддерживать 53 бита без снижения производителности для 32 битов, ну можно и так. Я не против этого принципиально, в конце концов если работает для 53 битов, то и для 32 битов, очевидно, будет работать ровно так же, но тут вся суть в том, можно ли это реализовать так, чтобы оно работало с нужной скоростью.

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

N>Я не про это, а про использования именно округления как средства обогащения.

Так это про воровство, округление лишь способ. Тебя посодют, а ты не воруй

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


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

Странно, я делал умножение столбиком для Long Decimal, было жопно долго для любых чисел, потом сделал на каких-то свёртках вроде, на порядок ускорился, про Карацуб и Куков не встретил инфы, когда делал

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

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

M>Странно, я делал умножение столбиком для Long Decimal, было жопно долго для любых чисел, потом сделал на каких-то свёртках вроде, на порядок ускорился, про Карацуб и Куков не встретил инфы, когда делал

Ты вроде писал, что посмотрел на FFT, а затем сделал по Фюреру.
Но как можно было при этом пропустить Тоома-Кука, я не знаю.

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

M>>Странно, я делал умножение столбиком для Long Decimal, было жопно долго для любых чисел, потом сделал на каких-то свёртках вроде, на порядок ускорился, про Карацуб и Куков не встретил инфы, когда делал

N>Ты вроде писал, что посмотрел на FFT, а затем сделал по Фюреру.

Да, точно, вроде Фюрер


N>Но как можно было при этом пропустить Тоома-Кука, я не знаю.

Ну вот как-то так

Но я про то, что столбиком — это крайне неэффективно в любом случае

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

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

Ну да.
Но народ на JS вообще видеокодеки пишет.

vsb>Эти юз-кейсы в основном покрываются 1/2/4 байтами.

Хм, в IP6 заголовке и 16-байтные поля есть, аж два

vsb>Где мне были бы полезны битовые операции в 53 бита, я вообще представить не могу. Ну можно придумать, типа приходят 7 байтов, и в них 53 бита значащие , но это явно будет придумка.

Ну тут я согласен, что случаев, когда надо именно 53, как-то мало, мягко говоря.
Хотя на 48 уже можно найти. Мак-адрес, например.

vsb>В общем я не убеждён, что это плохой дизайн. Свою задачу он решает. Как работает V8 и как он обеспечивает быстрое выполнение подобного кода, я не вполне представляю и если для поддержки 53 битов придётся сильно пожертвовать производительностью в 32 битах, тогда это плохой вариант.

На 64-битных платформах жертв уже нет.

vsb> Если можно поддерживать 53 бита без снижения производителности для 32 битов, ну можно и так. Я не против этого принципиально, в конце концов если работает для 53 битов, то и для 32 битов, очевидно, будет работать ровно так же, но тут вся суть в том, можно ли это реализовать так, чтобы оно работало с нужной скоростью.

Можно. Сейчас. Но захардкодили усечение, которое имело смысл только для 32.

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

A>Довольно странно при обсуждении фичи "a: int 1..100" рекомендовать язык, который не умеет это ни из коробки, ни за счёт расширений (синтаксических макросов), а умеет только за счёт Тьюринг-полноты.

Тьюринг-полнота ни при чём.

Шаблон вида

template <int _T_min, int _T_max>
RangedInteger& operator=(int new_value) {
  if (new_value < _T_min || new_value > _T_max) { throw range_error(); }
  mValue = new_value;
  return *this;
}

ничего такого не требует. Это тупой шаблон без всякой хитрой логики и рекурсии.

A>Ну ладно, шаблоны это всё-таки нечто промежуточное. Т.е. рекомендовать открыть для себя C++ в данной ситуации это всё-таки лучше, чем, например, ассемблер.

Разве что из-за оптимизаций. В ассемблере есть макры.

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

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

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

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

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

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

vsb>Для чего тебе вообще нужны битовые операции?
Отдельные психопаты пишут криптографию на JS и пихают это везде как "новое и молодёжное"

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

M>Но я про то, что столбиком — это крайне неэффективно в любом случае
А в "столбике" у тебя значения были какой разрядности?

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

M>>Но я про то, что столбиком — это крайне неэффективно в любом случае
CC>А в "столбике" у тебя значения были какой разрядности?

У меня один байт — одна десятичная цифра

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

M>>>Но я про то, что столбиком — это крайне неэффективно в любом случае
CC>>А в "столбике" у тебя значения были какой разрядности?
M>У меня один байт — одна десятичная цифра
Ух! Не, ну тогда понятно почему всё так безумно медленно.

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

M>>У меня один байт — одна десятичная цифра
CC>Ух! Не, ну тогда понятно почему всё так безумно медленно.

А есть варианты сделать long decimal более оптимально, и при этом без особых извращений?

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

A>> Хотя с виртуальной машиной там и ошибок-то таких не бывает, как в сях.
N>Ну да, там другие ошибки:

N>[--url=https://cs9.pikabu.ru/post_img/2016/09/14/8/1473858812151073022.jpg]Image: 1473858812151073022.jpg[/url]

Насколько я помню, ты достаточно низкоуровневый разработчик с большим опытом. И ты при этом не понимаешь, что это *на самом деле* другая ошибка? Что-то тут не сходится. Знаешь, что такое неделю искать, где у тебя память испортилась? Как вообще после этого можно сравнивать те ошибки и эту ситуацию, когда тебе русским языком выдана диагностика? Там ещё и в логе наверняка всё есть, вплоть до номеров строк.

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

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

CC>Как по мне так подобная заморочка не стоит того чтобы менять язык на тот, где она за каким то хреном встроена и надо сражаться чтобы её наоборот отключить.

Выбор языка для проекта — это одно. Он вообще редко определяется способностью языка решать подобные заморочки, к сожалению. Приходится смотреть на другие вещи: на чём написаны нужные тебе библиотеки, как их сопрягать, какие есть требования к производительности, памяти и размеру конечного продукта и т.д. и т.п. Вплоть до рынка труда и геополитической ситуации.

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

CC>Но выразительность современного языка должна быть на уровне, позволяющем перекрытие операторов.

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

N>Тьюринг-полнота ни при чём.

Да неужели. Когда сравнивают два языка, один из которых хорошо подходит для некоторой фичи, а второй — плохо, а потом кто-то говорит, что оба они, В ПРИНЦИПЕ, одно и то же, то этот "принцип" есть принцип Тьюринга и ничто другое.

N>Шаблон вида

N>

N>template <int _T_min, int _T_max>
N>RangedInteger& operator=(int new_value) {
N>  if (new_value < _T_min || new_value > _T_max) { throw range_error(); }
N>  mValue = new_value;
N>  return *this;
N>}
N>

И к чему тут этот ужас? Думаешь, никто не знает, как это программировать при помощи сиплюсплюсных шаблонов?

Есть языки, где ты можешь САМ сделать синтаксис вида a : int 1..100 (или более интуитивный) с генерацией алиаса на тип с чекерами, даже если bounds на уровне языка никак не представлены. Я удивился, почему было не предложить открыть для себя именно такой язык. Почему C++, где всё подтыкают шаблонами (за неимением синтаксических макросов). Будем по третьему разу мусолить, или хватит уже, наконец?

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

A>Есть языки, где ты можешь САМ сделать синтаксис вида a : int 1..100 (или более интуитивный) с генерацией алиаса на тип с чекерами, даже если bounds на уровне языка никак не представлены.

Простите, что вмешиваюсь, а можно список этих языков?

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

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

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

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

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

A>>> Хотя с виртуальной машиной там и ошибок-то таких не бывает, как в сях.
N>>Ну да, там другие ошибки:

N>>[--url=https://cs9.pikabu.ru/post_img/2016/09/14/8/1473858812151073022.jpg]Image: 1473858812151073022.jpg[/url]

A>Насколько я помню, ты достаточно низкоуровневый разработчик с большим опытом. И ты при этом не понимаешь, что это *на самом деле* другая ошибка? Что-то тут не сходится. Знаешь, что такое неделю искать, где у тебя память испортилась?

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

A> Как вообще после этого можно сравнивать те ошибки и эту ситуацию, когда тебе русским языком выдана диагностика? Там ещё и в логе наверняка всё есть, вплоть до номеров строк.

Это не диагностика. Это последствия ошибки.
В логе ничего нет, в 99% случаев. Всё надо самому вписывать.
Да, тип интеллектуальной возни другой. Объём работы может быть сходным.

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

M>>>У меня один байт — одна десятичная цифра
CC>>Ух! Не, ну тогда понятно почему всё так безумно медленно.

M>А есть варианты сделать long decimal более оптимально, и при этом без особых извращений?

Загляни в исходники .NET Core.
Там работают группами по 9 цифр на 32-битное хранилище.
Промежуточные операции 64-битные.
Но насколько это "особые извращения", не знаю — код действительно сложнее.

Здравствуйте, Ночной Смотрящий, Вы писали:

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

S>>Умно?

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

Это же вообще не связанные вещи. В дарте есть byte[]. В питоне том же один целый тип но поддержка byte[] есть.

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

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

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

Пример тогда был сильно паршивый. Именно на уровне процессора (берём Intel x86 последних лет):
1) Операции короче 32 бит стоят столько же, сколько 32-битные.
2) Только одна операция из базовых четырёх — деление — дорожает при переходе к 64 битам. (Грубо говоря, 90 тактов вместо 25.) Остальные как были 1 такт или меньше, так и остались. Это про throughput. Latency не меняется. Смотрел по 248966-042.pdf.
Ну и учитывать объёмы перегонки памяти, вот там торможение на оперативке может быть серьёзным.

А вот выше одного машинного слова уже можно и учитывать, как вы делали.

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

Там всё сложнее. И скорее наоборот, если "запихивание в шину" это промах по всем кэшам, то там 300 тактов можно получить как здрасте.

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

M>>А есть варианты сделать long decimal более оптимально, и при этом без особых извращений?

N>Загляни в исходники .NET Core.
N>Там работают группами по 9 цифр на 32-битное хранилище.
N>Промежуточные операции 64-битные.
N>Но насколько это "особые извращения", не знаю — код действительно сложнее.


А, ну ок, я понял. Да, так можно было, но это усложнило бы код. Я думал на эту тему, решил не связываться. Но суть от этого не меняется — умножение в столбик — это реально очень долго по сравнению с другими методами

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

КБ>Это же вообще не связанные вещи. В дарте есть byte[]. В питоне том же один целый тип но поддержка byte[] есть.

И наличие таких костылей как бэ намекаэ, что очень зря избавились от целых типов разной размерности.

Здравствуйте, Ночной Смотрящий, Вы писали:

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

КБ>>Это же вообще не связанные вещи. В дарте есть byte[]. В питоне том же один целый тип но поддержка byte[] есть.

НС>И наличие таких костылей как бэ намекаэ, что очень зря избавились от целых типов разной размерности.

Или наоборот ворох целых типов — костыль. А это нормальный высокоуровневый способ работать с бинарными данными.

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

M>А есть варианты сделать long decimal более оптимально,
Представление чисел DWORDами, в том же стиле как 64 битное число ими представимо, просто размерность тут плавающая.
Операции делать per-dword, всё это прекрасно ложится на уже имеющиееся процессорные складывалки и умножалки.

Все алгоритмы есть у Donald Knuth, не помню какой уже том.

M>и при этом без особых извращений?
А что считается особым извращением?

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

M>Но суть от этого не меняется — умножение в столбик — это реально очень долго по сравнению с другими методами
Последний раз когда я мерял Карацуба становился быстрее начиная где то от 1200 бит.
Это правда довольно давно было, надо бы перемерять.

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

M>>Но суть от этого не меняется — умножение в столбик — это реально очень долго по сравнению с другими методами
CC>Последний раз когда я мерял Карацуба становился быстрее начиная где то от 1200 бит.
CC>Это правда довольно давно было, надо бы перемерять.

Я по Фиюреру делал, и ускорение начинается сразу же

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

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

M>>Но суть от этого не меняется — умножение в столбик — это реально очень долго по сравнению с другими методами
CC>Последний раз когда я мерял Карацуба становился быстрее начиная где то от 1200 бит.
CC>Это правда довольно давно было, надо бы перемерять.

Я про gmp уже упоминал. mpn/x86_64/gmp_mparam.h :

#define GMP_LIMB_BITS 64
#define MUL_TOOM22_THRESHOLD                27

27*64 == 1728

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

НС>>И наличие таких костылей как бэ намекаэ, что очень зря избавились от целых типов разной размерности.
КБ>Или наоборот ворох целых типов — костыль.

Это не костыль, это реальность. И попытка на нее натянуть очередную leaky abstraction ни к чему хорошему не приводит.

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

N>Я про gmp уже упоминал. mpn/x86_64/gmp_mparam.h :

N>

N>#define GMP_LIMB_BITS 64
N>#define MUL_TOOM22_THRESHOLD                27
N>

N>27*64 == 1728

А как давно эта строка менялась? Ибо с развитием железа скорость выполнения алгоритмов от обрабатываемого объёма данных весьма даже плавает.

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

M>Я по Фиюреру делал, и ускорение начинается сразу же
У тебя просто обычное умножение похоже уж очень медленное получилось.
У меня на текущем железе карацуба умножение становится быстрее арифметического только после 1024 бит, а Sqr и вовсе после 4192х
Заодно обновил константы

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

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

НС>>>Это не костыль, это реальность. И попытка на нее натянуть очередную leaky abstraction ни к чему хорошему не приводит.

КБ>>Практикой не подверждается. От кучи целых типов на практике проблем больше.

N>Продемонстрируйте свою практику, пожалуйста.

Не нулевое количество проблем с неправильным выбором целого типа больше чем ноль проблем от "leaky abstraction" 🤷🏿

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

НС>>>>Это не костыль, это реальность. И попытка на нее натянуть очередную leaky abstraction ни к чему хорошему не приводит.

КБ>>>Практикой не подверждается. От кучи целых типов на практике проблем больше.

N>>Продемонстрируйте свою практику, пожалуйста.

КБ>Не нулевое количество проблем с неправильным выбором целого типа больше чем ноль проблем от "leaky abstraction" 🤷🏿

Как минимум на вторую половину вашей фразы отсутствует подтверждение, зато есть очевидные контрпримеры — я приводил их.

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

N>>Я про gmp уже упоминал. mpn/x86_64/gmp_mparam.h :

N>>

N>>#define GMP_LIMB_BITS 64
N>>#define MUL_TOOM22_THRESHOLD                27
N>>

N>>27*64 == 1728

CC>А как давно эта строка менялась?

Репа публичная, hg log напустить ты очевидно в состоянии.
https://gmplib.org/repo/gmp/

CC> Ибо с развитием железа скорость выполнения алгоритмов от обрабатываемого объёма данных весьма даже плавает.

Конкретно этот файл — общий для x86-64 всего целиком — менялся в 2011.
Но там есть ещё по каждой ходовой архитектуре свой файлик.
Например, самая последняя добавка mpn/x86_64/alderlake/gmp-mparam.h, там 13 (то есть 832 бита).
Перед этим zen3, там 20 (1280 бит).
Перед этим bd2, там 16 (1024 бита).
Перед этим bt1, там 24 (1536 бит).

У skylake почему-то 26, хотя не древность. У zen3 больше чем у bd2, хотя она на десяток лет новее. Стабильности не наблюдается.

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

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

НС>>>>>Это не костыль, это реальность. И попытка на нее натянуть очередную leaky abstraction ни к чему хорошему не приводит.
КБ>>>>Практикой не подверждается. От кучи целых типов на практике проблем больше.
N>>>Продемонстрируйте свою практику, пожалуйста.
КБ>>Не нулевое количество проблем с неправильным выбором целого типа больше чем ноль проблем от "leaky abstraction" 🤷🏿
N>Как минимум на вторую половину вашей фразы отсутствует подтверждение

Серъезно? "Вы не привели доказательств что проблем нет"? Ну так может наконец сформулируете с какими проблемами вы сталкивались?

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

НС>>>>>>Это не костыль, это реальность. И попытка на нее натянуть очередную leaky abstraction ни к чему хорошему не приводит.
КБ>>>>>Практикой не подверждается. От кучи целых типов на практике проблем больше.
N>>>>Продемонстрируйте свою практику, пожалуйста.
КБ>>>Не нулевое количество проблем с неправильным выбором целого типа больше чем ноль проблем от "leaky abstraction" 🤷🏿
N>>Как минимум на вторую половину вашей фразы отсутствует подтверждение

КБ>Серъезно? "Вы не привели доказательств что проблем нет"?

Да.

КБ> Ну так может наконец сформулируете

У вас однозначно проблемы с чтением.

КБ> с какими проблемами вы сталкивались?

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

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

КБ>>Серъезно? "Вы не привели доказательств что проблем нет"?

N>Да.

Потрясающе.

КБ>> с какими проблемами вы сталкивались?

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

Не будем обращать внимания что в этой ветке (и топике) обсуждается другое.
Использование языка с несколькими целыми типами (например C) решит эту проблему? Не решит?
А если проблема не зависит от наличия/отсутсвия набора целых типов — то причем этот пример здесь вообще?

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

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

КБ>Не будем обращать внимания что в этой ветке (и топике) обсуждается другое.

А я вижу прямое отношение ко всему в топике.
Все эти int8_t сейчас это костыли для сужения множества значений (тем более не работающие толком в условиях навязанного integral promotion).

КБ>Использование языка с несколькими целыми типами (например C) решит эту проблему? Не решит?

Почему сразу "например C"?
Решит — наличие типов с произвольно задаваемыми множествами значений. Среди которых все эти int16_t будут просто важными частными случаями для типового домена железо/ОС/etc.

КБ>А если проблема не зависит от наличия/отсутсвия набора целых типов — то причем этот пример здесь вообще?

Условие в "если" не выполняется.

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

N>А я вижу прямое отношение ко всему в топике.
N>Все эти int8_t сейчас это костыли для сужения множества значений (тем более не работающие толком в условиях навязанного integral promotion).

А этому утверждению есть подтверждение?

КБ>>Использование языка с несколькими целыми типами (например C) решит эту проблему? Не решит?

N>Почему сразу "например C"?

А почему нет? В C относительно стандартный набор целых типов.

N>Решит — наличие типов с произвольно задаваемыми множествами значений. Среди которых все эти int16_t будут просто важными частными случаями для типового домена железо/ОС/etc.

А этому утверждению есть подтверждение?

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

N>>А я вижу прямое отношение ко всему в топике.
N>>Все эти int8_t сейчас это костыли для сужения множества значений (тем более не работающие толком в условиях навязанного integral promotion).

КБ>А этому утверждению есть подтверждение?

Которому из? Тут у меня три утверждения

КБ>>>Использование языка с несколькими целыми типами (например C) решит эту проблему? Не решит?
N>>Почему сразу "например C"?
КБ>А почему нет? В C относительно стандартный набор целых типов.

char/short/int/long, или что?

N>>Решит — наличие типов с произвольно задаваемыми множествами значений. Среди которых все эти int16_t будут просто важными частными случаями для типового домена железо/ОС/etc.
КБ>А этому утверждению есть подтверждение?

И опять же — которому из?

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

N>Репа публичная, hg log напустить ты очевидно в состоянии.
N>https://gmplib.org/repo/gmp/
Для этого надо его на винду поставить, а он мне там нафиг не нужен.

N>Конкретно этот файл — общий для x86-64 всего целиком — менялся в 2011.
Значит уже устарел. В районе 2011го у меня тоже другая константа была.

N>Согласен, методически более верно было бы взять среднее между относительно последними Intel и AMD.
Идеально было бы мерять на конкретной машине во время старта, но это будет уже малость перебор

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

A>>Есть языки, где ты можешь САМ сделать синтаксис вида a : int 1..100 (или более интуитивный) с генерацией алиаса на тип с чекерами, даже если bounds на уровне языка никак не представлены.

S>Простите, что вмешиваюсь, а можно список этих языков?

Когда я это писал, я держал в голове Nemerle, про который тут много рассказывали в своё время. Язык, где даже if это макрос, и макросами же сделана возможность инлайнить XML в код. Сразу скажу, что сам я эти макросы не писал, но был глубоко впечатлён возможностями языка по расширению базового синтаксиса.

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

N>>>Тьюринг-полнота ни при чём.

A>>Да неужели. Когда сравнивают два языка, один из которых хорошо подходит для некоторой фичи, а второй — плохо, а потом кто-то говорит, что оба они, В ПРИНЦИПЕ, одно и то же, то этот "принцип" есть принцип Тьюринга и ничто другое.

N>CreatorCray сказал, что можно самому построить такой шаблон. Про Тьюринг-полноту ты сам зачем-то ввернул в эту ветку обсуждения, там этого не было. Вот я и не понимаю, почему.

Зачем и почему? Затем, что Тьюринг-полнота автоматически гарантирует принципиальную возможность запрограммировать что угодно. И потому нет смысла акцентировать эту самую принципиальную возможность ("на выходе получается ровно код проверки при укладке в переменную"). Важно, КАК мы это программируем. "Как" называется "выразительность". Между прочим, CreatorCray позже сказал, что из-за выразительности в таком малозначительном вопросе менять язык нет смысла. Из чего следует, что мы с ним друг друга поняли.

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

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

N>>>А я вижу прямое отношение ко всему в топике.
N>>>Все эти int8_t сейчас это костыли для сужения множества значений (тем более не работающие толком в условиях навязанного integral promotion).

КБ>>А этому утверждению есть подтверждение?

N>Которому из? Тут у меня три утверждения

"Все эти int8_t сейчас это костыли для сужения множества значений". Есть мнение что это костыли или для экономии памяти или средство для обеспечения определенного бинарного представления.
Какой смысл сужать множество если ни компилятор ни рантайм не проверяют выход за границы.

КБ>>>>Использование языка с несколькими целыми типами (например C) решит эту проблему? Не решит?
N>>>Почему сразу "например C"?
КБ>>А почему нет? В C относительно стандартный набор целых типов.

N>char/short/int/long, или что?

Эти и их unsigned варианты.

N>>>Решит — наличие типов с произвольно задаваемыми множествами значений. Среди которых все эти int16_t будут просто важными частными случаями для типового домена железо/ОС/etc.
КБ>>А этому утверждению есть подтверждение?

N>И опять же — которому из?

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

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

КБ>>>А этому утверждению есть подтверждение?
N>>Которому из? Тут у меня три утверждения
КБ>"Все эти int8_t сейчас это костыли для сужения множества значений". Есть мнение что это костыли или для экономии памяти или средство для обеспечения определенного бинарного представления.
КБ>Какой смысл сужать множество если ни компилятор ни рантайм не проверяют выход за границы.

Компилятор не проверяет, но мы-то можем проверять. После присвоения — сконвертировать обратно в исходный более широкий тип и сравнить на равенство.
Если компилятор уверен в том, что диапазон значений был до того достаточно узким, он может выкинуть эту проверку с конверсией.
А если ещё GCC/Clang стиль с __builtin_add_overflow(src, 0, &dst), то можно сразу и результат проверки получить.

Конечно, есть ещё тот фактор, что, например, запись по int16_t* запишет 2 байта, а не 4. Но то, что intN_t типы необязательны (в отличие от int_leastN_t и int_fastN_t), чётко показывает, чего именно хотели стандартизаторы в первую очередь.
Вы про эту прикольную тонкость стандартов были в курсе?

КБ>>>>>Использование языка с несколькими целыми типами (например C) решит эту проблему? Не решит?
N>>>>Почему сразу "например C"?
КБ>>>А почему нет? В C относительно стандартный набор целых типов.
N>>char/short/int/long, или что?
КБ>Эти и их unsigned варианты.

Тогда — не очень-то решит. Этот набор ограничен и непереносим в общем случае. Можно, конечно, опереться на то, что char везде вокруг 8 бит, short — 16, а int — минимум 32, но тогда надо честно говорить себе, что мы пишем не на C, а на некоем "усреднённом C современного железа достаточной мощности".
С другой стороны, у меня в работе одновременно проекты для железяк на ARM/32 и ARM/64. Так что на размер long я уже не могу заложиться.

N>>>>Решит — наличие типов с произвольно задаваемыми множествами значений. Среди которых все эти int16_t будут просто важными частными случаями для типового домена железо/ОС/etc.
КБ>>>А этому утверждению есть подтверждение?
N>>И опять же — которому из?
КБ>"Решит". Не очень понятно как оно там что решит. Согласно вводной на проекте бардак и заставить разработчиков проверять данные нельзя, но почему-то можно заставить их использовать наш волшебный тип.

Мы переваливаем на компилятор проверку валидности значений. Где-то он ещё при компиляции пожалуется — пусть это 1% мест, но уже будет хорошая зацепка. Дальше начнёт взрываться на тестах. Это уже хороший метод заставить разработчиков закопаться, что они не так делают. Дальше... ну передавать с этой опцией кастомерам или нет — зависит, где-то лучше чтобы работало даже на кривых данных, но как минимум в бета-тестировании или что вместо него — лучше с полной защитой.
А дальше — психология. Это тот же случай, как в TDD: чтобы заставить себя написать код для задачи, а не пялиться на котиков — пишем тест, и его непрохождение служит стимулом для написания целевого кода.