Здравствуйте, Alekzander, Вы писали:
A>Какой там домен? Вот и у меня, будем считать, такой же. Домен "Универсальный", как сказали бы маркетологи.
Ну вот обратите внимание — авторы Outlook уже в доисторические времена не стали заморачивать людей интами и флоатами. Нумбер и точность — вот наши друзья!

A>Это-то я хорошо понимаю. Но вот столкнувшись с необходимостью как-то имплементировать, я понял, что это не так-то просто.
Ну вариантов тут несколько.
Помимо уже обсуждавшихся чисел с фиксированной точностью, есть упомянутый одним из коллег Rational.
Он ведёт себя прилично везде, кроме возведения в нецелые степени и тригонометрии.
У него преимущество перед decimal — в отсутствии маеты с разрядностью. Например, нам не нужно ни заставлять человека указывать, сколько знаков после запятой будет у X. И не нужно думать, сколько знаков после запятой будет у z, который равен x / y. Или как нам сделать что-то типа x = x * y, если у игрека после запятой не ноль знаков.
Недостаток у него — в отсутствии разрядности. Number(2) всегда превращается в строку с 2мя знаками, даже если внутри него целое число. И округляется всегда до запрошенного количества знаков.
А Rational нужно округлять вручную, и разрядность указывать при выводе.

S>>Переполнения интов и потери точности для double ведут себя в бытовых сценариях настолько противоестественно, что даже программисты часто ошибаются.

S>>Пункт 1: double не нужен вообще ни для чего, кроме научных расчётов. Если ваша предметная область — не про физику/математику, то забудьте про дабл как про страшный сон.
S>>Пункт 2: так называемые "целые" двоичной разрядности имеют только одно полезное свойство: они быстро обрабатываются компьютером.
S>>Пункт 3: Если в вашей предметной области нет расчётов с триллионами значений, то длинные десятичные будут гораздо более адекватным выбором.
S>>Если есть — то тогда вам пригодятся ограниченные десятичные, которые лишь чуть-чуть медленнее интов, зато ведут себя предсказуемо.

S>>Так что я бы оставил в языке понятие number с известным количеством цифр после запятой (и неограниченным — до запятой).
S>>Если окажется, что такие длинные числа приводят на практике к нехорошестям, то оптимизировал бы язык, заменив в нём представление number на ограниченное.

A>Понял, принял. Буду думать ))

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

M>Некоторые акции торгуются по 0.000001 руб за штуку. Не ложится в твой currency. Но можно увеличить размер дробной части, до 6ти знаков, например. Правда, при этом лучше надеяться, что никогда не появится акций с ценой с большим количеством знаков. 0x7FFFFFFFFFFFFFFF/100000 = 92 233 720 368 547 руб. Ну, в принципе, для домашней бухгалтерии хватит. Только не пиши серьёзный софт

Так они и продаются, наверно, пакетами тысяч в десять или сто при такой-то цене.

A>>Что может пойти не так? (Кроме как всё, само собой).

M>Кстати, а дробная часть у тебя как, двоичная или десятичная будет?

Не понял вопроса. А просто считать в сотых, это двоичная или десятичная? И как выглядит другая?

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

A>Так они и продаются, наверно, пакетами тысяч в десять или сто при такой-то цене.

Да, они продаются лотами. Но оперировать стоимостью одной акции всё равно придётся


M>>Кстати, а дробная часть у тебя как, двоичная или десятичная будет?

A>Не понял вопроса. А просто считать в сотых, это двоичная или десятичная? И как выглядит другая?

Это десятичная — умножаешь/делишь на сто. Сдвигами не получится. Двоичная — это когда у тебя после точки идут 1/2, 1/4, 1/8, 1/16 и тп. 0.1 ты с двоичной дробной частью не сможешь получить.

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

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

Ну, в общем, если будешь decimal fixed point на целых делать, приходи к нам с геморроями, поржем

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

A>Возник вопрос на стыке проектирования, UX и БД )) Требуются ваши мнения.

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

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

A>>Возник вопрос на стыке проектирования, UX и БД )) Требуются ваши мнения.

НС>Ты не с того начал. Начать следует с описания юзкейсов и нефункциональных требований. Скорее всего после этого у тебя уже куча вариантов отсеется. После этого из оставшихся вариантов делаешь примеры кусочков на гипотетическом DSL и идешь с ними к целевой аудитории.

Я уже выше отписал, что это, как говорится, "инструмент общего назначения". Как калькулятор. Даже не сам калькулятор (для калькуляторного GUI юзкейсы имеют смысл), а калькуляторный движок под капотом.

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

НС>>Ты не с того начал. Начать следует с описания юзкейсов и нефункциональных требований. Скорее всего после этого у тебя уже куча вариантов отсеется. После этого из оставшихся вариантов делаешь примеры кусочков на гипотетическом DSL и идешь с ними к целевой аудитории.
A>Я уже выше отписал, что это, как говорится, "инструмент общего назначения".

Ты уж определись, DSL у тебя или универсальный язык. Если второе — ничего изобретать не нужно, берешь любой популярный строго-типизированный язык — Java, C# и т.п.

A>Как калькулятор. Даже не сам калькулятор (для калькуляторного GUI юзкейсы имеют смысл), а калькуляторный движок под капотом.

Строго типизированный калькулятор?

Здравствуйте, Alekzander, Вы писали:
A>Итак, что посоветуете для внутреннего представления чисел в памяти и хранения в sqlite? И какими типами это всё оформить для юзеров?
Внезапно столкнулся с такой же задачей.
Пока что кажется, что лучше всего — что-то вроде дотнетного Decimal.
Делать "резиновый" scale точно нельзя — потому что тогда 1/3 порождает число бесконечной длины.
Делать "резиновым" precision можно, но пока непонятно, нужно ли оно на практике. Это тип данных не для решения всяких уравнений, где, скажем, надо делить очень большое число на очень маленькое, а для деловых/финансовых расчётах.
Там верх сложности — это какой-нибудь StDev, где надо вычитать квадрат суммы из суммы квадратов, и WeightedAverage, где нужно делить сумму произведений на целое число.
Допустим, длина коллекции у нас порядка 2^L, размеры элементов — порядка 2^N. Итого, сумма квадратов потребует 2N+L бит.
То есть, скажем, коллекция в миллион элементов (L=20) и значениями, скажем, сто триллионов (N~47 бит) получаем 114 бит.
114битное число содержит до 35 десятичных цифр. Если мы хотим все эти цифры пустить на точность числа между 0 и 1, то нам не нужен scale больше 34. То есть для него достаточно 6 бит. Плюс знак — 1 бит.
Итого, получилось 121 бит — влезаем в 128. В принципе, 6 бит хватит и для бОльших scale. В 128 бит можно запихать до 121 бит точности, 1 бит знака, 6 бит scale. Но, наверное, производительность будет подтормаживать при таком плотном расположении.