Здравствуйте, netch80, Вы писали: M>>А есть варианты сделать long decimal более оптимально, и при этом без особых извращений? N>Загляни в исходники .NET Core. N>Там работают группами по 9 цифр на 32-битное хранилище. N>Промежуточные операции 64-битные. N>Но насколько это "особые извращения", не знаю — код действительно сложнее.
Накидал тест для своего Decimal, вычисление числа Пи по формуле Валлиса:
Здравствуйте, Shmj, Вы писали:
S>Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком: https://dart.dev/language/built-in-types
S>Умно?
на протяжении уже 400 сообщений на серъезных щах спорят нужно ли использовать знаковые целые или беззнаковые.
Один целый тип — это не просто умно. Это гениально.
Re[2]: 64 бита для целого без вариантов - добро или зло?
на протяжении уже 400 сообщений на серъезных щах спорят нужно ли использовать знаковые целые или беззнаковые. КБ>Один целый тип — это не просто умно. Это гениально.
Какого размера должен быть этот тип, чтобы гениально закрыть все проблемы?
The God is real, unless declared integer.
Re[3]: 64 бита для целого без вариантов - добро или зло?
на протяжении уже 400 сообщений на серъезных щах спорят нужно ли использовать знаковые целые или беззнаковые. КБ>>Один целый тип — это не просто умно. Это гениально.
N>Какого размера должен быть этот тип, чтобы гениально закрыть все проблемы?
Неограниченного конечно.
Re[4]: 64 бита для целого без вариантов - добро или зло?
на протяжении уже 400 сообщений на серъезных щах спорят нужно ли использовать знаковые целые или беззнаковые. КБ>>>Один целый тип — это не просто умно. Это гениально.
N>>Какого размера должен быть этот тип, чтобы гениально закрыть все проблемы?
КБ>Неограниченного конечно.
А в Dart, с которого началось обсуждение, он 64-битный. Непорядок-с.
The God is real, unless declared integer.
Re[2]: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, Nuzhny, Вы писали:
N>Смотря для какого языка. Так делать нельзя, если: N>- язык должен иметь возможность получать доступ к железу N>- язык предполагает парсинг и сериализацию бинарных данных/файлов/протоколов.
N>Бухучёт банка в это не лез, и не знаю, имеет ли он отношение к этому.
Насколько помню со времени банковской работы, при конвертации валют погрешности округления идут либо на спецсчет доходов или расходов банка. И так и так бывает, как получится.
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Re[11]: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, netch80, Вы писали:
N>На самом деле тут вообще ещё вопрос, при чём тут тьюринг-полнота языка на фазе трансляции, когда проверки всё равно надо впихивать в рантайм. Но если мы не сойдёмся по сказанному выше, то этот вопрос поднимать смысла нет.
Тут интереснее возможность не впихивать в рантайм избыточные проверки.
Например, при присванивании из RangeInteger<10, 20> в RangeInteger<5, 30> никакие проверки делать не надо.
В простых случаях вида RangeInteger<10, 50> a = 42; компилятору легко — после разворачивания шаблона сравнения if(42<10) будут выброшены.
А вот как отследить инварианты через границу двух разных типов?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: 64 бита для целого без вариантов - добро или зло?
S>>>Что скажете? O>>LEB128 тогда уже. Чтоб наверняка. S>Это пока кто-нибудь SHA не захочет в него засунуть.
128 в LEB128 это не о том, что числа в нем 128 битные, а о том, что бит 128 в октете означает 'продолжение' числа на дополнительный октет. Фактическая битность не ограничена.
Как много веселых ребят, и все делают велосипед...
Re[2]: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, ononim, Вы писали:
S>>Что скажете? O>LEB128 тогда уже. Чтоб наверняка.
Ну форматов передачи целого переменного размера дофига, и это не единственный.
И точно не оптимальный для внутреннего представления — он нацелен на сериализацию.
И не лучший, вообще-то. Почему в DWARF впихнули именно LE — непонятно.
Он легче пишется, но сложнее читается, а при том, что время отладчика на чтение этих значений заметно дороже времени линкера на их запись — выглядит нелепым решением.
The God is real, unless declared integer.
Re[12]: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, 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 делается так:
Здравствуйте, s_aa, Вы писали:
_>Насколько помню со времени банковской работы, при конвертации валют погрешности округления идут либо на спецсчет доходов или расходов банка. И так и так бывает, как получится.
Откуда там погрешности округления? Если на счетах все валюты будут с точностью до копеек, центов, а не их долей. В доходы/расходы идут курсовые разницы.
Re[13]: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, pagid_, Вы писали:
_>Здравствуйте, s_aa, Вы писали:
_>>Насколько помню со времени банковской работы, при конвертации валют погрешности округления идут либо на спецсчет доходов или расходов банка. И так и так бывает, как получится. _>Откуда там погрешности округления? Если на счетах все валюты будут с точностью до копеек, центов, а не их долей. В доходы/расходы идут курсовые разницы.
Вот я сейчас глянул курс — 36.5686.
Конверчу 30$ — получаю 1097.058 грн в идеале — но на счёт попадёт или 1097.05, или 1097.06.
The God is real, unless declared integer.
Re[14]: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, netch80, Вы писали:
N>Вот я сейчас глянул курс — 36.5686. N>Конверчу 30$ — получаю 1097.058 грн в идеале — но на счёт попадёт или 1097.05, или 1097.06.
Вот именно на эту сумму и проводится операция. И в общем-то без разницы 1097.05 или 1097.06. Тут главное чтобы именно на эту сумму увеличился остаток на твоем счете, именно она была показана тебе, как как результат операции и на неё уменьшился какой-то там счет банка. Если будет несоответствие в последнем случае "дебет не сойдется с кредитом" Никакие доли копеек никуда девать не нужно — да и невозможно — остатки на всех счетах учитываются с точностью до копеек.
Курс — не деньги. Его нет в качестве остатка на счете, он не уменьшается и не увеличивается при проведении операции.
Re[15]: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, pagid_, Вы писали:
_>Курс — не деньги. Его нет в качестве остатка на счете, он не уменьшается и не увеличивается при проведении операции.
Это ты так думаешь. А учёт может думать иначе.
Вот пусть банк округлил мне до 1097.06. Пусть прошло 1000 таких покупателей по 30$. В сумме банк выдал продавцам валюты 1097060 грн.
Но в учёт операций должна была пойти продажа 30000$, которые по этому курсу 1097058 грн.
Получается, банк переплатил 2 гривны.
Оно конечно мелочи, но учёт должен сойтись ровно в 0. И вот тут начинается вопрос, а какая из практик бухучёта применяется и что она требует.
То, что сказал s_aa — эти доли копейки и сливаются на спец. счёт доходов и расходов по конвертации, по сумме описанных операций на нём "добавилось" минус две гривны.
Я уже не помню, как зовётся этот подход. Но он есть, как тот суслик
The God is real, unless declared integer.
Re[16]: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, netch80, Вы писали:
N>Это ты так думаешь. А учёт может думать иначе.
Так думают закон, а вслед за ним люди занимающиеся учетом и создающие учетные программы.
N>Вот пусть банк округлил мне до 1097.06. Пусть прошло 1000 таких покупателей по 30$. В сумме банк выдал продавцам валюты 1097060 грн. N>Но в учёт операций должна была пойти продажа 30000$, которые по этому курсу 1097058 грн.
Нет, в учете пройдет 1097060 грн., но никак иначе. Сумма операций это и именно сумма операций, а не одна, по какому-то курсу. Он несколько раз на дню может меняться.
И никому она быть 1097058 не должна.
N>Получается, банк переплатил 2 гривны.
Не получается.
N>Оно конечно мелочи, но учёт должен сойтись ровно в 0. И вот тут начинается вопрос, а какая из практик бухучёта применяется и что она требует.
С общей 30000$ умноженным на курс? Нет, не должен. Никого в учете не интересует сколько будет, если 30000$ умножить на курс. Интересует и является учитываемой величиной сумма валютных операций (переведенных между счетами денег) за период.
N>Я уже не помню, как зовётся этот подход. Но он есть, как тот суслик
В валютных операциях действительно могут быть курсовые разницы попадающие на счет доходов/расходов, а не на какой-то спец. Но они возникают не из-за округления, а из-за того, что курс между моментом заключения договора и фактической операцией (отгрузкой товара, конвертацией валюты по текущему курсу) может измениться.
Re: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, Shmj, Вы писали:
S>Что скажете?
Я вот смотрю на эволюцию C# они становятся все ближе к нативу. Span<T>, ref поля и ref scoped,Встроенные массивы,Function Pointers bnl
и солнце б утром не вставало, когда бы не было меня
Re[14]: 64 бита для целого без вариантов - добро или зло?
Здравствуйте, netch80, Вы писали:
_>>В доходы/расходы идут курсовые разницы. N>Конверчу 30$ — получаю 1097.058 грн в идеале — но на счёт попадёт или 1097.05, или 1097.06.
Не ну ты явно читать не умеешь
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока