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

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

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

S>Умно?

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

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

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

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

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

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

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

Здравствуйте, 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
А то местные сишники уже напридумывали себе всякого. Им же такое и в голову прийти не могло.

Здравствуйте, 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 для хранения любых целых чисел? Или отсутствие выбора лучше чем его наличие?

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

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

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

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

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