Столкнулся с неожиданной проблемой. 8.3 в режиме управляемых форм написал обработку моделирующую некий процесс, заметил что выполняется он неестественно долго. Решил, что дело в разделении на клиентскую и серверную части - забил. Образовалось немного свободного времени - повторил тоже самое в 8.2 - тормозит точно также. Удивился, поползал в отладчике, нашел что тормоза происходят в момент вычисления арифметических формул, типа:
строкаР.Параметры.Плт = Формат(377.1562*оПр/вПр-377.836,"ЧДЦ=1; ЧГ=");
эта строка вычисляется более 20 секунд! Табло показывает, что проблема именно в вычислении
оПр/вПр
Переписал строку, добавив округление:
строкаР.Параметры.Плт = Формат(377.1562*Окр(оПр,10)/Окр(вПр,10)-377.836,"ЧДЦ=1; ЧГ=");
все летает.

Не понимаю, что это было, и когда еще вылезет?
---
Неужели фиксированная точка с бесконечной точностью?
И целая часть и дробная - с теоретически бесконечной точностью (размер типа - динамический и зависит от самого числа).
Реально ограничения, конечно, установлены. Но достаточно большие.
Из забавного - в табло при выводе числа на экран ограничение на количество выводимых знаков после запятой меньше, чем фактически рассчитываемая точность (если периодическая дробь, например).
---
разбейте данную формулу по частям с учетом приоритета операций
---
А что было в оПр и вПр? Если прямо в табло разделить эти значения - тоже 20 секунд?
---
Если повторить операцию в табло - те же 20 секунд, при этом сами числа по отдельности прекрасно в табло вычисляются. Собственно в табло и удалось подобрать решение. Параметры вычисляются по формулам вида:
оПр = оПр + дан[инд].Пр/ДайПл(дан[инд].Индекс)
то есть никакого криминала, ДайПл - реализует численную аппроксимацию некой функции, причем линейную. Обычные расчеты с плавающей точкой.

Способ решения я представил. Вопрос в том, как это может быть и когда может вылезти еще. Понятно, что 1С это не С и даже не паскаль, но такого я ни разу не встречал, хотя счетные задачи в 7.7 решал, но повторять все тоже самое еще и в 7.7 не буду.
---
Может быть, получается Очень Длинное Число.
1С может оперировать с в принципе неограниченными числами. Нет проблем вычислить 23957623492.9572532452345234534957340257356 / 34957348957579.3457934532534534257349. Но, чем число длиннее, тем расчеты с ним будут дольше.
---
Никогда об этом нигде не читал. Получается возник вопрос а как 1С хранит числа? Неужели фиксированная точка с бесконечной точностью?

(7) тип числа в 1С хранится с неепической точностью.
А разве не что то типа doble - казалось бы плавающая точка и все?

Тогда получается, что при организации объемных вычислений нужно заранее решать вопрос о точности и все расчеты вести со ссылками на таблицу значений с фиксированной точкой, ну или через реквизиты, неожиданный вывод. Подумаю - как это проверить.
---
А разве не что то типа doble - казалось бы плавающая точка и все?
Нет конечно. Ни в одной нормальной финансовой программе не используются вычисления с плавающей точкой.
Почитай про ограничения типа double и иже с ним. Если проводить аналогии с другими языками, то тип числа в 1С скорее ближе к BigDecimal в java.
Во многих языках подобных типов в стандартных либах нет и используются сторонние библиотеки.
---
Неужели фиксированная точка с бесконечной точностью?
И целая часть и дробная - с теоретически бесконечной точностью (размер типа - динамический и зависит от самого числа).
Реально ограничения, конечно, установлены. Но достаточно большие.
Из забавного - в табло при выводе числа на экран ограничение на количество выводимых знаков после запятой меньше, чем фактически рассчитываемая точность (если периодическая дробь, например).
---
обычно все проще. Обычно в расчетах участвуют числа получаемые из БД, где уже прописана необходимая точность. А магических чисел нужно избегать во всех ЯП.
---
А что в Строка(оПр) ? Сколько знаков?
---
Хм... Математика в 1С очень медленная. Частично из-за неоптимизированности, но большей частью из-за того, что тип числа в 1С хранится с неепической точностью. Известный способ ускорения вычислений на порядки - хранить операнды в реквизитах с фиксированной точностью.
Но чтобы 20 секунд??? Уверен, что это не в длинном цикле получилось 20 секунд?
---
Но вообще, любой скриптовый язык считает минимум в 10 раз быстрее оптимизированных расчетов 1С.
Поэтому обычно всякие численные методы в 1С с большим количеством итераций и вычислений или через внешние скрипты гоняют или через внешние компоненты, для этого написанные (это еще быстрее).
ЗЫ. Написал и задумался. Мог и ошибиться насчет 10 раз. Кажись, если сравнивать с оптимизированными вариантами на реквизитах с фиксированной точностью, то js/vbs все-таки в разы быстрее было, а не на порядок. Вот если не оптимизировать, тогда и два порядка разница была. Давненько уже этими исследованиями баловались.
---
В большинстве случаев вопрос медленности вычислений 1С не встает, потому что типичные задачи решаемые 1С включают работу с БД, на фоне медленности которой разговор о медленности вычислений просто теряет смысл. Всплывает только на вот таких моментах - попытках реализовывать численные математические методы с большим количеством итераций без обращений к БД.
---
Хм... Хотя вот

```1c
    Сообщить(СтрДлина(Строка(1/3)));
```

выдает 29...
Может и поменяли чего с тех пор, что я помню...
Или это только при преобразовании в строку режет...
---
Поэкспериментировал. Видать оптимизации какие-то работают.
1/3 реально считает до 27 знаков после запятой.
Но если что-то более хитрое и сложное посчитать - тогда до 99 знаков после запятой.
ЗЫ. Но есть много промежуточных ступеней. По-ходу, точность результата динамически зависит от размерности операндов.
---
Когда-то студентом написал программу для вычислений с использованием обычных (не десятичных) дробей. Там уже никаких ошибок округления в принципе нет (разве что при выводе конечного результата в виде десятичной дроби)
---
Провел эксперимент

```1c
    а = 1; в = 1; сч = 1; бл = -1;
    Пока сч < 10000 Цикл
    нач = ТекущаяУниверсальнаяДатаВМиллисекундах();
    сч = сч + 1;
    в = в/10;
    а = а + в;
    с = а * а;
    кон = ТекущаяУниверсальнаяДатаВМиллисекундах();
    вр = кон - нач;
    Если бл < вр Тогда
    Сообщить(Строка(СтрДлина(Строка(с)))+ " за " + Строка(вр));
    бл = вр;
    Если вр > 10000 Тогда
    Прервать;
    КонецЕсли;
    КонецЕсли;
    КонецЦикла;
    Сообщить(Строка(сч));
    Сообщить(Строка(СтрДлина(Строка(с)))+ " за " + Строка(вр));
    Сообщить(Строка(с));
```

На выходе
4 за 0
326 за 15
326 за 16
326 за 33
10 000
326 за 16
1,234567901234567901234567901234567901234567901234567901234567­901234567901234567901234567901234567901234567901234567901234­567901234567901234567901234567901234567901234567901234567901­234567901234567901234567901234567901234567901234567901234567­901234567901234567901234567901234567901234567901234567901234­567901234567901234567901
Получается, что хранится до 326 знаков, а время на разовое умножение при этом 15 миллисекунд.
Это не глюк, а фича, и значит это нужно учитывать.