Математика с фиксированной запятой для C++20

Нет уж, Вы анонсировали свое умение работать с рядами - демонстрируйте.

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

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

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

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

Нет, это было еще до Вас. Если Вы конечно не Тейлор и ко…

Всё остальное, вы придумали сами.

Вы утверждали что можете из такого представления извлекать нечто полезное. И банально соврали. Ай-яй…

Вопросов больше не имею.

Нет, это было еще до Вас. Если Вы конечно не Тейлор и ко…

То есть теперь вы спорите ещё и с Тейлором? :)

Вы утверждали что можете из такого представления извлекать нечто полезное. И банально соврали. Ай-яй…

Могу. Да, не из всех рядов, но могу. Разобрались, почему определить знак – сложнее?

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

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

Я думал Вы и правда носитель какого то сакрального знания, а оказывается Вы обычный балабол:-(

Этот ряд имеет значение (сходится)?

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

Это хороший вопрос, но мне довольно очевидно, что в uint8_t нельзя представить число с тремя десятичными знаками после запятой. Диапазон трёх десятичных знаков (unsigned) - это 0.000..0.999, uint8_t может представить только 256 значений, значит этот диапазон он может представить либо с какой-то погрешностью, либо может представить только часть диапазона.

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

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

Этот ряд имеет значение (сходится)?

При b>0 очевидно да. Но при малых b может делать это оооочень медленно;-)

Вопрос в том когда (при каких условиях) НУЖНО представлять значение в виде суммы ряда. И когда такое представление имеет смысл. «Условие теоремы это список поражений ее автора» - так вот я этих условий так и не дождался. В общем случае это очевидно не работает, пример я привел.

Точно, это же «замечательный» предел, так что и при b = 0 должен сходится.

Тогда какие вопросы? Математик сказал: решение существует. Значит медленно и упорно майним монетки - приближаем тепловую смерть вселенной при t -> ∞.

Математик сказал: решение существует.

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

первый замечательный предел

ну вот, спалили контору;-(

Вы утверждали что можете из такого представления извлекать нечто полезное. И банально соврали. Ай-яй…

Улыбнуло. Ладно, считайте, что на слабо взять удалось. Придётся что-то выкатить.

Можете ограничиться более подробным описанием того что Вы делаете и как. С условиями применимости;-)

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

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

Прикладной математик проверяет степень шизофрении, ой, то есть степень оторванности настоящего математика от реальности.

С условиями применимости

Нет, я так не играю. В начале было одно условие: представить корень какого-то рационального числа в рациональных числах.

И тут пришел ты и перевернул условие: есть ряд, представь в виде рационального числа.

Естественный ответ: заткнись и считай.

представить корень какого-то рационального числа в рациональных числах.

Нет бы продолжить троллить, и спросить про квадратный корень отрицательного числа.

В начале было одно условие: представить корень какого-то рационального числа в рациональных числах.

Все уже представлено до Вас, man sqrt. Есть всякие оптимизации

Естественный ответ: заткнись и считай.

«А как дысал, как дысал!» Скучно, девочки… зачем тогда было щеки дуть?!

«А как дысал, как дысал!»

«Молчи и считай!» было сказано сразу же на твое предложение посчитать до бесконечности элементы бесконечного счетного множества.

Поэтому ты, глубоко вдохнув, решил перевернуть всё. Выдыхай, бобер!

Я тут чуть-чуть наговнокодил. Моих знаний Хаскела сделать быстро красивее не хватает.

import Data.Ratio
import Data.List

data Sum = Sum  [(Rational, Rational)]

takeWhileOneMore p = foldr (\x ys -> if p x then x:ys else [x]) []

eval precision (Sum xs) =
    sum $ map fst $ takeWhileOneMore ((>precision).snd) xs

instance Num Sum where
    Sum xs + Sum ys = Sum $ zipWith (\(a1, b1) (a2, b2) -> (a1+a2, b1+b2) ) xs ys
    Sum xs * Sum ys = Sum zs where
        psx = scanl1 (+) $ map fst xs
        psy = scanl1 (+) $ map fst ys
        psz = zipWith (*) psx psy
        as = zipWith (-) psz (0:psz)
        ds = zipWith4 (\sx sy dx dy -> (abs sx)*dy + (abs sy)*dx + dx*dy) psx psy (map snd xs) (map snd ys)
        zs = zip as ds
    negate (Sum xs) = Sum $ map (\(a, b) -> (-a, b)) xs
    fromInteger i = Sum $ (i%1, 0) : repeat (0, 0)

sqrt' :: Rational -> Sum
sqrt' x = res
    where res = Sum $ zip as $ map (\s -> abs (s - x/s)) ps
          as = a1 : map (\s -> (x/s - s)/2) ps
          ps = scanl1 (+) as
          a1 = fromIntegral (floor $ sqrt $ fromRational x) % 1

Смысл в том, что числа x представляются бесконечной последовательностью пар рациональных (aᵢ, bᵢ) таких, что
x = a₁ + a₂ + a₃ + ...
bᵢ ≥ |aᵢ₊₁ + aᵢ₊₂ + aᵢ₊₃ + ...|
bᵢ -> 0

Ну и пример использования:

Создаем пару чисел s2 = √2 и s3 = √3:

*Main> s2 = sqrt' 2
*Main> s3 = sqrt' 3

*Main> eval (1%100) s2
17 % 12
*Main> eval (1%1000) s2
577 % 408
*Main> eval (1%1000000) s2
665857 % 470832
*Main> fromRational $ eval (1%100) s2
1.4166666666666667
*Main> fromRational $ eval (1%1000) s2
1.4142156862745099
*Main> fromRational $ eval (1%1000000) s2
1.4142135623746899

*Main> x = (s3-s2)*(s3+s2)
*Main> eval (1%100) x
1019911 % 1019592
*Main> fromRational $ eval (1%100) x
1.0003128702461377
*Main> fromRational $ eval (1%1000) x
1.0003128702461377
*Main> fromRational $ eval (1%1000000) x
1.0000000084681628

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

Я не увиливал. Я же ожидаю, что не с кодером общаюсь, а со спецом по мат. моделированию, физике и вот этим вот всем.

Спасибо. Но я продолжаю не понимать, в частности потому что не знаю Хаскеля.

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

1. Когда такое число вычисляется (приводится к float), как производится суммирование? Потому что в рациональных числах это будет очень долго, а во floating point это может оказаться очень неправильно за счет ошибки округления (если ряд знакопеременный).

2. Для каких именно чисел Вы это используете? Это таки накладывает ограничения на способ порождения ряда - для корней вид членов будет один, для синусов другой и т.д. И я не понял как именно Вы порождаете ряд для корня - раскладываетесь в Тейлора в окрестностях ближайшего квадрата рационального числа? Еще как то?

3. Если это корни, то не очень понятно зачем (кроме как джаст фор фан, что тоже ответ)? Народ упарывается по всякому - полиномы Эрмита, сферические функции, я раскладывал экспоненту от суммы скалярных произведений на сфере и еще черти чего. Для корней я бы просто ввел корень как корень из рационального числа - они бы прекрасно перемножались, складывать было бы сложнее (так и оставались бы суммой), но в любом случае ИМНО это было бы удобнее ряда. Да и эстетически симпатичнее;-)

Все это фактически элементы CAS, сделанные на коленке и заточенные под решение какой то узкой задачи. Вот хочется эту задачу понять;-)

Я же ожидаю, что не с кодером общаюсь, а со спецом по мат. моделированию, физике и вот этим вот всем.

Физика тут я не понял причем, а в остальном будьте проще - у меня в первом семестре по матану был трояк;-)

Нет, я так не играю. В начале было одно условие: представить корень какого-то рационального числа в рациональных числах.

Просто ни кто еще "не осилил".  

В связи с этим вспоминается как математики пришли к понятию «производная» /КРАСОТИЩЕ/ и далее пришли к интегральному исчислению.

Скорее всего иррациональные и иные числа все же каким-то образом можно представить в виде рядов, но не методом ПОДГОНКИ …

В связи с этим вспоминается как математики пришли к понятию «производная» /КРАСОТИЩЕ/ и далее пришли к интегральному исчислению.

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

ПРОИЗВОДНАЯ ...

Просто ни кто еще «не осилил».

Представить в рациональных числах / значение x, когда x * x = -1 /

Терять информацию - терять деньги

И снова не удержался. Вопрос наверное больше в плоскости философии, но рано или поздно вы придёте к пониманию того что бОльшая часть информации - мусор. Гораздо интересней из этого потока «условного шума» вычленять что-то практически полезное. Подумайте об этом на досуге.

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

Ну, не так уж и долго. Рациональную дробь для (√3-√2)*(√3+√2) с точностью до 1000000 десятичного знака считает за 3 секунды. Жить можно, хоть и не очень приятно.

Для каких именно чисел Вы это используете?

Мне это не нужно, для моих целей обычно и float хватает.

И я не понял как именно Вы порождаете ряд для корня - раскладываетесь в Тейлора в окрестностях ближайшего квадрата рационального числа? Еще как то?

Это уже не очень важно, на самом деле. По факту я считаю методом Герона. Да, постоянно нужно тащить частичную сумму ряда, но что поделать. Могу переделать и в ряд Тейлора.

Если это корни, то не очень понятно зачем (кроме как джаст фор фан, что тоже ответ)?

Анонимус спрашивал про корень из двух, я сделал корень из двух. Да, это just for fun, на практике мне оно не нужно. Но можно добавить и другие числа. e^pi?

Для корней я бы просто ввел корень как корень из рационального числа - они бы прекрасно перемножались, складывать было бы сложнее (так и оставались бы суммой), но в любом случае ИМНО это было бы удобнее ряда.

Я бы не делал рядами, конечно. Можно интереснее. Тут только пруф оф поинт.

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

Все это фактически элементы CAS, сделанные на коленке и заточенные под решение какой то узкой задачи. Вот хочется эту задачу понять;-)

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

Рациональную дробь для (√3-√2)*(√3+√2) с точностью до 1000000 десятичного знака

Сферический конь в вакууме.

считает за 3 секунды. Жить можно, хоть и не очень приятно.

Это безумно долго.

для моих целей обычно и float хватает.

Открою секрет - в 99% случаев этого хватает.

Сферический конь в вакууме.

И?

Это безумно долго.

Лет 15 назад в олимпиадном программировании была хорошая оценка. Чтобы уложиться в таймлимит в 1с, программа должна делать до 1000000 итераций. По тем меркам 10^6 значащих цифр за 3 секунды – ок. Попробуйте просто посчитать корень из 2 с такой точностью. Уверяю, длинная арифметика съест очень много времени. Вангую, что у вас получится раз в 10 быстрее, но это мелочь для пруф оф консепт кода.

Открою секрет - в 99% случаев этого хватает.

Спасибо, что сообщил.

Сферический конь в вакууме.

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

Лет 15 назад

А кто-то не понаслышке знает что такое МК-61 и МК-52…

в олимпиадном программировании

О, Вы олимпиадник? Прикольно.

в таймлимит в 1с, программа должна делать до 1000000 итераций.

Мы нынче в гигагерцах живём. Это от 1000 тактов на циферку. Времени - вагон.

Спасибо, что сообщил.

Вы не поняли. Во вполне себе живых системах цены во float’ах разлетаются. Не благодарите.

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

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

Ок, принято. Нет бы сразу так;-)

Открою секрет - в 99% случаев этого хватает.

За овер 20 лет я наверное только один раз уперся в то что мне не хватило флоат. Результаты были очень забавные. И еще раз уперся в нехватку дабла - это как раз при суммировании знакопеременного ряда в лоб;-)

Инвариантную массу флоатом лучше не считать.

У коллег, в латтис больцмане, даже в даблах масса течет:-)

За овер 20 лет я наверное только один раз уперся в то что мне не хватило флоат. Результаты были очень забавные. И еще раз уперся в нехватку дабла - это как раз при суммировании знакопеременного ряда в лоб;-)

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

Ерундой занимаетесь. Мало того, что есть готовые библиотеки, так еще и «потери» денег из-за округлений не бывает в нормальной бухгалтерии. Вам на консультацию к бухгалтеру нужно. Любой участник расчетов может посчитать на калькуляторе, сам же округлит без всяких удивлений, а от вас будет ожидать именно такого числа, а не магии через расчеты в рациональных дробях. Ваша задача - считать как все, а не особенным образом. А чтобы деньги не утекали в никуда и не «притекали» из ниоткуда, существует курсовая разница (это бухгалтерский термин, а не биржевой), которая падает на доходы или расходы. Если вы влезли в неизвестную предметную область (и я не про крипту), то либо вам придется её изучить хотя бы в общих чертах, либо вы сделаете говно.

Ерундой занимаетесь. Мало того, что есть готовые библиотеки

Ссылки в студию, plz.

из-за округлений не бывает в нормальной бухгалтерии

Я уверен, в clearing своя кухня. Front-office - отдельная тема.

Ваша задача - считать как все, а не особенным образом

Основная задача - не попасть «под раздачу», иногда бывает.

существует курсовая разница

В каком виртуальном мире она более менее стабильна?

Если вы влезли в неизвестную предметную область

20+ лет считается?

либо вы сделаете говно

Мы Вас однозначно ждём. И облизываемся. Вы же знаете «как правильно»?

Фигасе жесткий O_o

Ссылки сами найдете. Можете mpdecimal прикрутить. У нас над gmp своя обертка (и без динамических аллокаций). Если за 20+ лет не знаете, какими проводками обменная операция выполняется, то либо мы о разных предметных областях говорим, либо одно из двух. От «стабильности» курсовой разницы её наличие или отсутсвие не зависит. Либо строите учет так, чтобы курсовые разницы не мешали, либо учитываете их. Собственно, на самом деле вся эта история - это творчество с моделированием, подбором плана счетов, эффективным раскладывание всех операций на проводки с учетом будущих требований бизнеса (да, их никто заранее не сформулирует - это же крипта) в условиях динамичных курсов и, по сути, созданием аналогии взрослого операционного дня (подсказка: не дня :)). И именно поэтому, если с бух.учетом нелады (чаще всего даже банковские разработчики со стажем считают себя выше этого), нужен бухгалтер с головой. Потому что можно либо сделать схематоз, который вас завалит, либо сделать удобный обслуживаемый инструмент для бизнеса. В обоих случаях термины одни, а выхлоп критически разный.

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

ЗЫ Я тоже знаю, как правильно. Но мои продукты давно в проде (некоторые - много лет), т.е. моё «правильно» еще и работает (в т.ч. с длинными цепочками партнеров). Процессинг электронной коммерции (16 лет стажа в банке) и биржа. Ожидаемо - криптовалютная. И после банковского опыта криптовалютная индустрия - это анархия и дичь во весь рост, поэтому я даже не вполне понимаю, в каком месте и от кого именно Вы там собрались попадать под раздачу. Активы с пассивами сходятся - и хорошо. У вас же сходятся? :)

Если вы влезли в неизвестную предметную область

20+ лет считается? … Вы же знаете «как правильно»?

По таким предъявам даже не заподозрил, что топикстартер - другой человек. Вы чего, товарищ, в бутылку лезете за других? Зря на Вас буквы перевёл :(

Фигасе жесткий O_o

На самом деле я «белый и пушистый» :)

Ссылки сами найдете. Можете mpdecimal прикрутить. У нас над gmp своя обертка

Это - медленно.

Если за 20+ лет не знаете, какими проводками обменная операция выполняется, то либо мы о разных предметных областях говорим, либо одно из двух.

У Вас явно терминология бухгалтера. И в этом ничего плохого нет. Мы смежники, но из разных лагерей.

От «стабильности» курсовой разницы её наличие или отсутсвие не зависит.

Знание значения «вечность назад» в общем случае Вам мало поможет.

нужен бухгалтер с головой

Если Вам придётся иметь дело с несколькими миллионами DARTs, никакой «живой» бухгалтер Вас не спасёт, буть он хоть семи пядей во лбу.

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

Основная головная боль - регуляторы.

даже с эфирными 18 знаками после десятичной точки

Я не знаю платформу где берут ордера с такой точностью. И при цене ETH $3-4k мне 18 знаков после запятой кажутся, мягко говоря, избыточными, если не сказать на уровне шизофрении. Вы электричества больше сожжете на транзакции чем ошибка округления.

ЗЫ Я тоже знаю, как правильно.

В отношении себя я не буду так категоричен. Мы в постоянном развитии и поиске правильных/лучших решений. Но если хотите посостязаться - милости просим :)

т.е. моё «правильно» еще и работает

Хех…

Зря на Вас буквы перевёл :(

Да ладно - неужели Вам скучно не бывает? :-)

В отношении себя Вы предельно категоричны - настолько абсолютизируете себя, что даже не пытались понять суть написанного (или Вам это не нужно, и тогда зачем эти вбросы?). Какая связь между бухгалтером и DARTs? Речь о проводках в рамках жизненного цикла ордеров каждого вида (и торговых, и неторговых), смене операционных курсов и проч. Торговые ордера с точностью 18 знаков я вообще не упоминал. Вечность или не вечность назад - тоже не к месту. Если у вас есть проблемы с учетом, то они с учетом, а не с округлением. Если были проблемы с регулятором из-за округлений, то, пожалуйста, приведите пример из жизни (будет хоть что-то полезное в рамках темы топика).

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

даже не пытались понять суть написанного

Я честно пытался.

Какая связь между бухгалтером и DARTs?

И тут же:

Речь о проводках в рамках жизненного цикла ордеров каждого вида

И раньше:

нужен бухгалтер с головой

Вы, мягко говоря, непоследовательны.

Торговые ордера с точностью 18 знаков я вообще не упоминал.

А как ещё вот это интерпретировать:

даже с эфирными 18 знаками после десятичной точки

?

В какой момент эти 18 знаков вообще появляются?

Если у вас есть проблемы с учетом, то они с учетом

У меня нет проблем с учётом - этим clearing занимается, и я там не работаю. Это почему-то у Вас всё к учёту сводится.

Напомню: топик про fixed point math, давайте мы как нибудь в это русло дискуссию завернём?

Если были проблемы с регулятором … приведите пример из жизни

Вот так вот сразу. Неужели Вы думаете мне может придти в голову мысль обсуждать такие вещи вне конторы?

И тут же:

Речь о проводках в рамках жизненного цикла ордеров каждого вида

Ключевое слово - «вида». Где DARTs, и где обвязка одного ордера.

А как ещё вот это интерпретировать:

даже с эфирными 18 знаками после десятичной точки

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

Топик про fixed point math, но во вполне конкретном контексте, и русло дискуссии я веду к тому, что проблема недостаточной точности конкретно здесь надумана.

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

Судя потому, как Вы активно съезжаете в абстрактные вычисления, а клиринг где-то там, даже Ваш пример (если бы он возник) вряд ли связал бы наказание с округлением. Потому что с вероятностью 99% наказали за кривое отражение в учете.

Ключевое слово - «вида».

Давайте хотя-бы определимся что Вы называете «видом» ордера? А то походу у нас терминология совсем разная.

Где DARTs, и где обвязка одного ордера

Я к тому что в «ручном» режиме Вы можете провести очень ограниченное число транзакций.

Эфир здесь - блокчейн, в контрактах которого точность номинала в данной валюте ограничена 18 знаками.

И что? В теории да, но кого это волнует. На практике Вы позицию хотите знать всегда абс точно, надеюсь здесь нам спорить не о чем - если Вы что-то купили или продали Вы хотите точно знать сколько именно Вы этого чего-то купили или продали. Но помимо того что конкретный продукт допускает теоретически имеют место быть ограничения конкретно взятых платформ. И я не видел пока ещё места где бы крипту вообще и ETH в частности торговали бы с точностью до 18го знака. Вас также волнует «total cost» и «total value» позиции, с точностью до копейки в валюте счета (или продукта). И там sub-копейки никому не интересны, ни трейдерам, ни брокерам, ни налоговикам, никому. Потому как никто в своём уме не будет проводить sub-копейки транзакции - комиссии съедят всё. Cost basis это отдельная тема - там sub-копейки могут вылезать.

К учету всё сводится потому, что именно ради него вся эта кутерьма с супер-округлениями или попыткой не округлять.

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

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

«Вид» к ордерам я обычно не применяю :) Здесь пришлось попытаться по-простому сделать акцент на том, что каждый специфичный документ (в частности, торговые ордера в их вариациях) может по-разному отражаться в учете. Причем нет правильного варианта - есть более или менее удачные. И задача условного бухгалтера - не проводки руками проводить, а придумать хороший в последующем применении бизнесом схематоз (начиная с плана счетов), который потом уже будет применяться массово. И чем удачнее получится это сделать, тем проще будет обращать бизнесовые вопросы к базе данных (в т.ч. про PnL).

Про высокую точность (вот это вот всё про 18 знаков) не я топил. Мои слова, с которых всё началось: «А округлять вам придется неизбежно …». Я тоже считаю это перебором, и все мои посты о том, не зря ли топикстартер поставил перед собой задачу добиться особой точности там, где она никому не нужна (кмк).

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

ЗЫ Предлагаю перейти на личное общение, если есть желание. Нас с Вами стало слишком много в этой ветке :) Мою почту можно найти на гитхабе в одноименном профиле.

Посоны, с новым годом и рождеством!

Очередная финальная версия на сегодняшний день:

• Вместо std::optional библиотека будет выбрасывать исключения. Теперь нет необходимости разименовывать опшиналы, везде возвращается fixed::p или выбрасывается исключение. Опшиналы ещё используются внутри, но не снаружи.
• 1/3 + 1/3 + 1/3 даёт точную единицу, а 1 - 1/3 - 1/3 - 1/3 даёт точный ноль. Тут есть побочный эффект в том, что при операциях с дробями растёт точность, т.к. внутри используется умножение, при котором растёт точность. Это пока что останется.
• Теперь fixed отслеживает не только то, что число не точное, а до какого знака оно точное. Например неточное число с тремя знаками после запятой может быть точным до второго знака - это отслеживание точности по верхнему пределу. Получить такую точность можно вызвав fixed::accuracy().

В общем fixed::precision() - с какой точностью число представлено, fixed::is_accurate() - точно или неточно ли число в принципе, fixed::accuracy() - фактическая точность числа, независимо от представления.

Все изменения экспериментальные, но на сегодняшний день пока что всё.