Добрый день.
Пытаюсь в запросе посчитать пропорцию простым делением текущей суммы в строке таблицы на итоговую сумму таблицы. Но получается слишком грубое округление (даже без использования округлений). Итоговый результат гуляет на 6-8%, есть ли какие-то методы снижения погрешности?

где запрос?
обработка через
ВЫРАЗИТЬ(х/у - 0.5 КАК ЧИСЛО(15, 0)) + ....?

(0) "на 6-8%" - Умножь входящие числа на миллион - точность будет выше.

Нет, просто Таблица1.Сумма / ТаблицаИтоговая.Сумма
Без округлений
Обе таблицы сохранены как временные

Умножение на миллион не помогает, погрешность та же самая

(0)

Говорят, что

МаленькоеЧисло/БольшоеЧисло*ДругоеБольшоеЧисло

отличается от

МаленькоеЧисло * ДругоеБольшоеЧисло/БольшоеЧисло

Врут, небось (с)

(2) Может, он разреженные слау методом гаусса решает?

(5) Ну я попробовал Таблица1.Сумма * 1000000 / ТаблицаИтоговая.Сумма КАК Пропорция

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

(0) Прикол хочешь?
Там еще и точность зависит от СУБД и ее настроек да
Если точность недостаточна - приходится расчеты производить вне запросов

(7) А возводить в квадрат, а потом извлекать корень не пробовал?

Ты задачу опиши - и что делал.

Тут главное чтобы одночлен на многочлен делить по запросу не заставили

(10) "членораздельная речь - это речь человека, которому член делят на многочлен"©

(4) Не может быть. Запрос с умножением на миллион в студию.

(9) Задача простая, распределить некие общие надбавки на таблицу с суммами, по пропорции этих сумм в таблице.

Я группирую таблицу, чтобы получить её итоговую сумму и записываю в ТаблицаИтоговая.
После чего добавляю надбавку по пропорции
ТаблицаНадбавок.Надбавка * Таблица.Сумма / ТаблицаИтоговая.Сумма

Оно всё делит правильно, но приблизительно. Из-за недостаточной точности при делении, предполагаю.

Вот пытаюсь узнать, есть ли способ как-то точность увеличить.

(13)
В запросе
1000000 * ТаблицаНадбавок.Надбавка * Таблица.Сумма / ТаблицаИтоговая.Сумма

Результат из запроса
Надбавка = ВыборкаДетальныеЗаписи.СуммаНадбавки / 1000000

(13) Это древний баян
Что 0.33+0.33+0.33 <> 1

(14) У него не в этом проблема
Он суммы (надбавки) в процентном соотношении распределяет
И сумма распределенных не сходится с суммой выделенного ))

(16)+ Короче см (15)
Выделили премию на весь отдел в 1 рубль
Надо разделить на 3х сотрудников...

(13) скорее (8) прав. как правило в настройках СУБД точность 6 знаков по умолчанию.

выполните запрос в консоли
Выбрать ВЫРАЗИТЬ(15.7/13 КАК ЧИСЛО(27,25))
и покажите тут результат.

(16) так что мешает погрешность добавить к последней (или первой)

(19) Запросами?

(20) Ну а чо бы и нет?
забавнее другое - его просят показать запрос, а он молчит как рыба об лёд..

а если так, то сколько % потерь?

ВЫРАЗИТЬ((ТаблицаНадбавок.Надбавка * Таблица.Сумма) КАК  ЧИСЛО(25,10))/ ВЫРАЗИТЬ(ТаблицаИтоговая.Сумма КАК  ЧИСЛО(25,10))

(16) Цитирую автора: получается слишком грубое округление (даже без использования округлений). Итоговый результат гуляет на 6-8%

Кажется мне это не классическая проблема округление при распределении. 6-8%? Вы серьезно?

Ну вот упрощенный запрос:

Выбрать
Бонусы.ПериодНачисления,
Бонусы.Менеджер,
Бонусы.СуммаБонуса
Поместить Бонусы
ИЗ РегистрСведений.Бонусы КАК Бонусы
Где Бонусы.ПериодНачисления = &ПериодНачисления
;
Выбрать
Надбавки.ПериодНачисления,
Надбавки.СуммаНадбавки
Поместить Надбавки
ИЗ РегистрСведений.Надбавки КАК Надбавки
Где Надбавки.ПериодНачисления = &ПериодНачисления
;
Выбрать
Бонусы.ПериодНачисления,
Сумма(Бонусы.СуммаБонуса) КАК СуммаБонуса
Поместить БонусыИтоговые
ИЗ Бонусы КАК Бонусы
Сгруппировать По ПериодНачисления
;
Выбрать
Бонусы.ПериодНачисления,
Бонусы.Менеджер,
Бонусы.СуммаБонуса,
Надбавки.СуммаНадбавки * Бонусы.СуммаБонуса / БонусыИтоговые.СуммаБонуса КАК НадбавкаПоМенеджеру
ИЗ Бонусы КАК Бонусы
ВнутреннееСоединение Надбавки КАК Надбавки ПО Бонусы.ПериодНачисления = Надбавки.ПериодНачисления
ВнутреннееСоединение БонусыИтоговые КАК БонусыИтоговые ПО Бонусы.ПериодНачисления = БонусыИтоговые.ПериодНачисления

(24) Можно вопрос?
Зачем считать это запросами?
У вас там десятки и сотни тысяч сотрудников-менеджеров по которым надо бонусы считать?

Почему тупо не считать это обычным кодом, на обычном языке программирования 1С?
В банальном цикле по ТЗ!

(14) Да, умножение на 1000000 ничего не добавляет к точности
(16) Ладно бы не сходилась, хотелось бы просто поточнее.

(24) "приведите" делимое и делитель к одному типу операндов как в (22)

(25) возможно там у них рлс

(28) Выбрать по кому считать и суммы можно с РЛС
Поместить в ТЗ
И далее циклом

(25) Несколько сотен наберётся.

Типа функцию из СКД вызвать предлагаете, а там считать?

(27) Не повлияло

(30) Нет
Нафуй там СКД?
Для чего???

Если очень хочется отборы - ну так сваял ТЗ готовую (запросами и кодом) и передал в СКД как источник (для показа)

(24) И где "умножение на мильён"?
И что, кстати, "не сходится на 6-8%"?

(33) Кстати, вроде бы в СКД можно в явном виде написать ВЫРАЗИТЬ с нужной точностью и тогда все посчитается не 6 или сколько там знаков в SQL, а сколько укажешь

(33) Добавьте
Бонусы.СуммаБонуса / БонусыИтоговые.СуммаБонуса КАК Пропорция

в последний запрос
Значения пропорций будут такими же, что и
(Бонусы.СуммаБонуса * 10000000) / БонусыИтоговые.СуммаБонуса
только со смещением запятой.

В сумме где-то 0.94 или даже хуже выходит, вместо 1.
Соответственно и сумма всех надбавок настолько же отличается от эталонной надбавки.

Надбавки.СуммаНадбавки * Бонусы.СуммаБонуса / БонусыИтоговые.СуммаБонуса КАК НадбавкаПоМенеджеру

ВЫРАЗИТЬ(Надбавки.СуммаНадбавки * Бонусы.СуммаБонуса / БонусыИтоговые.СуммаБонуса КАК ЧИСЛО(25, 10))  КАК НадбавкаПоМенеджеру

(31) тогда уменьшите разрядность, тут детали

https://its.1c.ru/db/v8std/content/535/hdoc

(36) Так ведь ещё больше ошибка округления будет?

(38) Почему?
Как раз все хорошо будет

ВЫБРАТЬ
    "А" КАК Назначение,
    100 КАК Сумма
ПОМЕСТИТЬ Т

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    "Б",
    200

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    "В",
    300

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    "Г",
    400

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    "Д",
    500

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    "Е",
    600
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    СУММА(Т.Сумма) КАК Сумма
ПОМЕСТИТЬ Т_Итог
ИЗ
    Т КАК Т
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    Т.Назначение КАК Назначение,
    Т.Сумма КАК Сумма,
    ВЫРАЗИТЬ(Т.Сумма / Т_Итог.Сумма - 0.004999999 КАК ЧИСЛО(15, 2)) КАК Процент,
    Т.Сумма / Т_Итог.Сумма - (ВЫРАЗИТЬ(Т.Сумма / Т_Итог.Сумма - 0.004999999 КАК ЧИСЛО(15, 2))) КАК ДельтаПроцент
ПОМЕСТИТЬ ТТ
ИЗ
    Т КАК Т,
    Т_Итог КАК Т_Итог
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    СУММА(ТТ.ДельтаПроцент) КАК ДельтаПроцент,
    СУММА(ТТ.Сумма) КАК Сумма
ПОМЕСТИТЬ Т_Дельта
ИЗ
    ТТ КАК ТТ
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ТТ.Назначение КАК Назначение,
    ТТ.Сумма КАК Сумма,
    ТТ.Процент КАК Процент,
    ТТ.ДельтаПроцент КАК ДельтаПроцент,
    ВЫРАЗИТЬ(ТТ.Процент + Т_Дельта.ДельтаПроцент * ТТ.Сумма / Т_Дельта.Сумма КАК ЧИСЛО(15, 2)) КАК ПроцентИтог
ИЗ
    ТТ КАК ТТ
        ЛЕВОЕ СОЕДИНЕНИЕ Т_Дельта КАК Т_Дельта
        ПО (ИСТИНА)

*видел в запросе появились новомодные ОКР и ЦЕЛ, но я по-старинке доверяю 0.004999999

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

(36) Только выразить надо не результат, а составные части

(42) Э... ну может быть... практика критерий истины.

Все не читал, но можно попробовать
Значение*0.0000000000001/0.0000000000001

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

даже в математических операциях вычитания в экселе есть погрешность. 1,324 - 1,319 не равно 0,005

Можно, а зачем? )

(42) Вроде нет

(45) Если вагон стоимостью миллион состоит наполовину из винтов по рублю, то такие погрешности вполне себе накопятся в серьезную погрешность

Гораздо проще это сделать в коде

(0) а нужно??

(47) вроде да. Иначе оно посчитает с той же самой точностью, а потом приведет к типу. Правда уже поздно