Вопрос о форматах чисел с плавающей запятой.

[Aether]

Добрый день.

Обращаю внимание, что многие программисты чаще всего используют для хранения формат С double (64бит double-precision IEEE 754) для вещественных чисел. Естественно понятно, что С float (32бит single-precision) обеспечивает диапазон и точность меньшие, чем современные калькуляторы, что можно расценивать, как недостаток. Но почему избегается хранение в полноценном формате C long double (80бит)? Вычисления, всё равно, если правильно понимаю происходят с 80 битными числами?

[Алексей++]

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

[darkelf]

Обращаю внимание, что многие программисты чаще всего используют для хранения формат С double (64бит double-precision IEEE 754) для вещественных чисел. Естественно понятно, что С float (32бит single-precision) обеспечивает диапазон и точность меньшие, чем современные калькуляторы, что можно расценивать, как недостаток. Но почему избегается хранение в полноценном формате C long double (80бит)?

В отличии от double поддержка типов float и long double в оригинальном стандарте C89 была ограниченной. Например была функция strtod(), которая возвращала double, но не было strtof()/strtold(), аналогично был sin(), а sinf()/sinl() не было (при этом в компиляторах могла быть поддержка этих функций, но т.к. в стандарте они не были описанными, то и поддержка считалась нестандартной). В стандарте C99 это уже поправили, но, насколько я понимаю, все уже привыкли пользоваться double.

Плюс, если я правильно помню, до определённого момента сам тип long double размером 80-бит считался Intel x86 специфичным (он появился в сопроцессоре x87 и, похоже, по крайней мере в начале, был не особо поддержан другими производителями процессоров).

Вычисления, всё равно, если правильно понимаю происходят с 80 битными числами?

Для архитектур x86 и x86-64 при работе через FPU - да. Через SSE, я так понимаю, что уже будут вычисления 64-х битные. Для других процессорных архитектур - могут быть другие варианты.

[Dale]

Первый компилятор C был разработан для компьютера DEC PDP-11 как замена ассемблера. Конструкции ранних версий языка фактически отображались на архитектуру компьютера один к одному (автоинкремент переменных, индексный доступ по указателю и т. п.). Поэтому, если что-то в языке порой покажется странным, достаточно задаться вопросом: "а как это было реализовано на PDP-11?", и все сразу становится ясно.

Блок операций с плавающей точкой PDP-11 умел работать с числами 32 и 64 бита, которые и превратились в языке в float и double соответственно. При этом все операции внутри выполняются по стандарту как double и при необходимости переводятся в float. Выглядит странно, что для сложения двух float они сначала преобразуются в double, а затем результат операции приводится обратно к float? Весьма. Однако блок операций с плавающей точкой PDP-11 нужно было явно переключать в режим либо одинарной, либо двойной точности. Два формата одновременно он поддерживать не умел. Поэтому его в начале выполнения программы инициализировали в режиме с большей точностью и больше не трогали, так Томпсону и Ритчи показалось рациональнее.

Формат 80 бит появился позже, а C - язык довольно консервативный и активно сопротивляется новшествам (иначе где бы сейчас была его хваленая переносимость). Уши PDP-11 торчат из него и поныне.

[Aether]

Спасибо за развёрнутые ответы.

В среде нашей инженерии сейчас обсуждаем тему о CAD системах, а именно о формате передачи проектных моделей и чертежей. На настоящий момент у нас всё согласно принципу: "Тут каждый сам себе Бетховен", что на деле сильно мешает. Конструкторы используют большую гамму CAD систем, почти каждая из которых имеет свои закрытые форматы хранения. Покупать средства доступа для каждого формата - сомнительная перспектива, поэтому взор падает на имеющиеся открытые стандарты, такие, как, например, DXF. Однако, их эволюция привела к тому, что накопились значительные рудименты, сильно осложняющие ввод и вывод полезной составляющей. Сам использую для обмена моделями формат IGES, свои задачи он решает, но тем не менее, его полная поддержка CAD программами не всегда обеспечена, что сводит всё к громоздкому описанию с использованием лишь примитивов: точек, линий, дуг.

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

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

[RXL]

Double, в пересчете на десятичные знаки, позволяет хранить 15 знаков (52 бита). Точнее было бы хранение в целом формате, скажем, в микронах, либо определение в заголовке документа размерности единицы измерения.

[Aether]

Double, в пересчете на десятичные знаки, позволяет хранить 15 знаков (52 бита). Точнее было бы хранение в целом формате, скажем, в микронах, либо определение в заголовке документа размерности единицы измерения.

Да, это тоже хорошая идея. Мысль использовать формат с фиксированной запятой посещала, как в минималистичном варианте: 32 бит целое со знаком отражает измерение в четвертьмикронах - для повышения точности при вычислениях. Таким образом, получается математическое пространство длиной в 1 073 741 824 мкм, то есть примерно 1 км. Так и использование 64 бит, как 32:32 бита, соответственно целая и дробная часть в мм. Получается математическое пространство в примерно 4300 км. Если задавать исходную единицу измерения в документе, то таким форматом можно хранить, вероятно, не только чертежи, но и любую картографию, хоть планетарного характера.

Сложности с реализацией вычислений, особенно на С. На ассемблере мне знакомо использование комбинаций ADD + ADC для вычисления сумм больших целых чисел. Впрочем, вопрос также и в том, что для вычисления без значимой потери точности необходимо увеличение размерности самих чисел. Например: функция окружности R^2 = (x - xc)^2 + (y - yc)^2. Предположим мы делаем рендеринг дуги, и зная координаты точки в математическом пространстве: x и y, зная центр дуги xc, yc, находим текущий радиус Rt, который затем сверяем с R для установления свойства: закрашивать или нет.

Так вот, в итоге Rt = sqrt((x - xc)^2 + (y - yc)^2), где, как аргументы, так и результат имеют одну размерность, например, int_32. А вот промежуточные (x - xc)^2, имеют размерность int_64. И так далее, каждое умножение будет умножать и размер аргументов, хоть в результате всё приведётся к искомому int_32.

[RXL]

64-битный тип long long int доступен и на 32-битных платформах. Описан в 2007-м году в дополнении к C99 (ISO/IEC 9899). Т.ч. подробности реализации на ассемблере можно опустить.
80-битный long double описан в 2001-м году в дополнении к C99.

Я бы сделал так:
- хранить 32-битное целое (с утвержденным порядком байт) в условных единицах: в рамках документа этого должно хватить каждому(tm);
- условную единицу прописать в заголовке, она нужна, по сути, только для человеко‑понятной визуализации и для подготовки программ ЧПУ;
- расчеты делать в double (мантиса 52 бита), можно считать исходные значения в условных единицах;
- промежуточные результаты расчетов можно хранить в long double (матниса 64 бита).

[Aether]

Интересный момент, кстати, как со станками с ЧПУ, так и с IGES. Программы в "G" кодах допускают задание дуги двумя способами: либо через радиус, начальную и конечную точки, либо через центр дуги взамен радиуса. Формат IGES определяет дугу только через центр дуги и точки её начала и конца. Так вот, в последнем случае система получается как-бы переопределена на один аргумент. До сих пор не полностью представляю пересчёт? При вычислении с конечной точностью в системе всё равно будет присутствовать некая разность, не говоря о том, что требуемое может просто не построиться. Также, стоит отметить, что при больших радиусах центр дуги может уйти за пределы математического пространства формата. С точки зрения математики имело бы смысл строить дугу по трём точкам, делая перерасчёт на радиус, как производное для служебных и информационных нужд.

[RXL]

Считаю, что математический подход в физическом описании плохо подходит. Ведь чертежник не поставит иглу циркуля на -2000 мм за полем ватмана и рабочие инструменты станков работают в стесненных условиях. Указывать центр дуги - плохой подход, все точки должны попадать в диапазон координат документа.

[Sla]

Хм... а полярные координаты уже отменили?

[RXL]

Для дуги на плоскости (в объеме) в полярных координатах потребуется центр, радиус и два (четыре) угла. Вместо этого имеем две точки и радиус. Фактически тот же самый объем информации.
Для чего могут понадобиться полярные координаты?

[Sla]

Напомню
Полярная координата имеет две координаты Угол (полярный) и Радиус (полярный)

Если для станка с ЧПУ нужно нарисовать дугу с радиусом (декартовым) больше чем стол станка, то нужно переносить координаты в область видимости, например нижний левый угол и от него вести все расчеты

Я не знаю как считаю CAD системы, но ты ведь знаешь, что точность станка ЧПУ зависит от механической точности (шага) самого станка. И если "шаг" в микронах, то и точность вычислений может не превышать точности станка.

Это как оцифровывать аналоговый сигнал с точностью в 48 бит при погрешности измерителя (датчика) 0,1%.

Добавлено через 8 минут и 45 секунд:
Вопрос не в объеме координат, а в точности вычислений, если я правильно понял

[Aether]

Считаю, что математический подход в физическом описании плохо подходит. Ведь чертежник не поставит иглу циркуля на -2000 мм за полем ватмана и рабочие инструменты станков работают в стесненных условиях. Указывать центр дуги - плохой подход, все точки должны попадать в диапазон координат документа.

Представим стол вертикального фрезерного станка X:Y = 1000x500 мм - распространённый размер. Предположим у нас изделие в форме сабли, расположенное вдоль X и имеющее прогиб около 30 мм. В этом случае радиус будет намного превышать размер стола - десятки метров. Чертёжник, строящий это вручную может, вообще нарисовать прямоугольник, поставить радиус 15000 мм и это уже проблема технолога в том, чтобы получить искомое. Деталь изготавливается по размерам, а не по картинке. Однако при работе в электронном виде происходит следующее: предположим мы изберём в качестве единицы хранения целочисленный тип данных с 32 битной ёмкостью. Если за единицу принять микрон, то математическое поле будет в микронах от -2000000000...2000000000 или -2...2 км. В итоге при задании дуги через радиус может возникнуть конфуз - при размере самого объекта в 1 м, радиус может оказаться, например, более 3 км, что приведёт к некоторому переполнению и краху модели. В принципе граничные условия - проблема любой разрядности...

Хм... а полярные координаты уже отменили?

Для чего могут понадобиться полярные координаты?

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

Вопрос не в объеме координат, а в точности вычислений, если я правильно понял

Вопрос, как всегда: а хватит ли нам 640Кб? Инженерам нужно единое пространство, чтобы рисовать и мосты размером с километр, и мизерные детальки в десятые мм. В ходе построения могут быть преобразования, когда небольшое отклонение одного параметра значительно искажает геометрию. Точность в микрон у станка, означает, что его конструктив работает с долями микрона, а микрон - это гарантированный им результат... С другой стороны хочется простоты и без раздутия.

[Sla]

Не ищите проблем там, где их нет

Рекомендую восполнить знания о погрешностях

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

Для каждого станка, могут быть разные микропрограммы.  Но все они, практически, понимают PU PD, PenUp, PenDown.

Так вот в таком случае - действительно объем данных может зашкаливать

а хватит ли нам 640Кб?

Причем здесь это.
Вы хотите отдавать макет без постобработки? Ню, ню...

[Aether]

Возможно, на примере будет понятнее: все знают, что такое газораспределительный (ГРМ) механизм в двигателе Вашего авто? Его главные поверхности - это профили кулачков и их углы установки. Конструкторы должны этот контур предоставить, естественно, что с точки зрения физики, заход в кулачке должен быть выполнен по логарифмической спирали, рабочие точки также являются параметрами. В итоге, конструктору выгоднее создать математическую модель этого вала с необходимыми параметрами, чтобы потом можно было легко манипулировать режимами - изготовить десяток валов и методом последовательного приближения получить нужную диаграмму работы ДВС.

На настоящий момент решение выглядит следующим образом: написание плагина к LibreCAD, с последующим выводом в DXF. Программа действует так: по указанным параметрам формирует образующие кулачков по точкам (точек десятки тысяч), затем производит интерполяцию в примитивы - дуги и линии так, чтобы точность не выходила за заданные пределы. Получается набор из уже десятков элементов. Далее идёт вывод в DXF, который хоть и работает, но имеет кучу нюансов, и весит с десяток Мб, что не удобно.

[Sla]

Поясняю
DXF - это, грубо, PU PD примитив - точка
А для станка - примитивом может быть микропрограмма