Константы чисел с плавающей запятой

[Aether]

Добрый вечер.

Хочу поинтересоваться вот каким вопросом: предположим есть задача в вычислении коэффициентов, и они будут представлять из себя числа с плавающей запятой. В будущем, эти коэффициенты будут использоваться в расчётах, чувствительных к точности, например, замена 81,0015783 и 81,0015784 может радикально переломить ситуацию. Таким образом, как целесообразнее отобразить эти коэффициенты в программе: как числа в десятичной системе с значащим количеством знаков, или всё же сделать шестнадцатеричное их представление?

Попутно: если записать число с плавающей запятой с количеством знаков большем вместимости выбранного формата, но не превышающее, разумеется, границ формата, то компилятор произведёт округление самостоятельно?

[Dale]

как целесообразнее отобразить эти коэффициенты в программе: как числа в десятичной системе с значащим количеством знаков, или всё же сделать шестнадцатеричное их представление?

Если достоверно известно, что числа представляются в IEEE 754, то без разницы: компилятор/интерпретатор все равно приведет к нужному внутреннему представлению. Для читающего программу "магическая" последовательность десятичных цифр практически так же лишена смысла, как и последовательность шестнадцатеричных. Если же используется арифметика произвольной точности (Decimal или нечто наподобие), лучше не играться с внутренним представлением и оставить в десятичном виде, ибо чревато.

Кстати, у Вас есть измерительный прибор, способный достоверно отличить 81,0015783 от 81,0015784?

Попутно: если записать число с плавающей запятой с количеством знаков большем вместимости выбранного формата, но не превышающее, разумеется, границ формата, то компилятор произведёт округление самостоятельно?

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

[Алексей++]

Aether,

x*810015783/10000000

 

[Aether]

Если достоверно известно, что числа представляются в IEEE 754, то без разницы: компилятор/интерпретатор все равно приведет к нужному внутреннему представлению. Для читающего программу "магическая" последовательность десятичных цифр практически так же лишена смысла, как и последовательность шестнадцатеричных.

Суть то в чём: когда первая программа находит коэффициент, то при отображении его числа уже происходит округление - это неотъемлемое свойство при переводе из двоичной формы в десятичную.
2⁰ = 1
2^-1 = 0,5
2^-2 = 0,25
2^-3 = 0,125
2^-4 = 0,0625
2^-5 = 0,03125
Как видно, хвост в десятичной начинает стремительно расти.

В то же время при записи такого округлённого значения во второй программе будет произведено преобразование в формат с плавающей запятой, и тут снова что-то отвалится.

Кстати, у Вас есть измерительный прибор, способный достоверно отличить 81,0015783 от 81,0015784?

Дело не в приборе, изначально АЦП (12 бит) переводит сигнал с датчика в двоичный вид. Однако, этой исходной информации нужно придать смысл, и для этого используется аппроксимация вида:
y(x) = e ^ (Ax⁵ + Bx⁴ + Cx³ + Dx² + Ex + F)

Естественно, точности double IEEE 754 хватает в десятичном представлении, но меня заинтересовала сама суть проблемы и её правильное решение, особенно в случае, когда использование избытка при выборе формата нежелательно.

Я бы сначала поискал эти данные в стандарте выбранного Вами языка программирования (который из темы и поста никак не следует).

Сорри, языки "C", "NASM", "MPASM". Да, вероятно, стоит посмотреть.

x*810015783/10000000

?

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

[Dale]

Как видно, хвост в десятичной начинает стремительно расти.

Я увидел совершенно другое: "вес" этого хвоста стремительно уменьшается. Не в количестве цифр счастье, главное - с какой погрешностью представлена реальная величина.

Можно, например, безумствовать c триллионами значащих цифр числа π, а можно вспомнить, что классический радиус электрона имеет порядок 10^-15м со всеми вытекающими, и прикинуть, сколько из этих разрядов нужно для практических применений, и начиная с какого разряда работа идет исключительно на книгу рекордов Гиннесса.

Дело не в приборе, изначально АЦП (12 бит) переводит сигнал с датчика в двоичный вид.

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

Однако, этой исходной информации нужно придать смысл, и для этого используется аппроксимация вида:
y(x) = e ^ (Ax⁵ + Bx⁴ + Cx³ + Dx² + Ex + F)

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

[Aether]

Я увидел совершенно другое: "вес" этого хвоста стремительно уменьшается. Не в количестве цифр счастье, главное - с какой погрешностью представлена реальная величина.

Я сейчас проделал небольшой эксперимент, оказалось, что десятичная запись с запасом на пару знаков сверх количества значащих для формата чисел, даёт результат идентичный шестнадцатеричному представлению. То есть, мой компилятор округляет.

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

Дело не в точности самих чисел, а в идентичности представления, например:
5.123456789123456789123456789
будет представлено в float, как:
5.12345695495605470000
записи:
5.12345678
будет достаточно, чтобы получился тот же итог:
5.12345695495605470000
Тем не менее, более идентичным и компактным будет:
0x40A3F35C

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

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

[Dale]

Дело не в точности самих чисел, а в идентичности представления, например:
5.123456789123456789123456789
будет представлено в float, как:
5.12345695495605470000
записи:
5.12345678
будет достаточно, чтобы получился тот же итог:
5.12345695495605470000

Откуда взялось столько значащих цифр у float? Возможно, имеется в виду double?

Если речь идет об обработке значений из реального мира, например, результат того же 12-битного АЦП, то записи 5.123 хватит за глаза. Последующие цифры - самообман и никакого реального смысла не несут.

Тем не менее, более идентичным и компактным будет:
0x40A3F35C

Насчет компактности полностью согласен. Только вот какая от нее реальная польза? Экономия нескольких байт исходного кода на диске в несколько терабайт? Внутреннее представление ведь компактнее от этого не станет.

По части идентичности - тут не так однозначно. Если обстоятельства вынудят повысить точность вычислений с одинарной до двойной, для магической константы 5.123456789123456789123456789 ничего по сути не изменится, компилятор сделает необходимые преобразования сам. А вот с константой 0x40A3F35C все не так просто, ее придется пересчитать, найти и заменить в исходниках. Если эта честь выпадет самому автору, это еще полбеды, а вот если с этим придется разбираться постороннему человеку, автор узнает немало нового о своем умении программировать, а также ориентации и прочих деталях частной жизни (такова традиция, увы).

Интерполяция - одна из сторон эмпирического подхода при описании физических процессов.

Согласен, потому и удивился необычной формуле. Как-то привычнее в подобных случаях видеть полином, сплайн и т.п. Или реально измеряется не сама величина, а ее логарифм?

[Aether]

Откуда взялось столько значащих цифр у float? Возможно, имеется в виду double?

Это просто пример, так-то, конечно у float 7 значащих цифр. Хотя, как показала практика, указывать лучше на пару цифр больше, то есть 9.

Если обстоятельства вынудят повысить точность вычислений с одинарной до двойной, для магической константы 5.123456789123456789123456789 ничего по сути не изменится, компилятор сделает необходимые преобразования сам. А вот с константой 0x40A3F35C все не так просто, ее придется пересчитать, найти и заменить в исходниках.

Да, согласен. Возможно, поэтому такого подхода я в общем случае и не замечал.

Согласен, потому и удивился необычной формуле. Как-то привычнее в подобных случаях видеть полином, сплайн и т.п. Или реально измеряется не сама величина, а ее логарифм?

Когда мне попадается прибор с нелинейной характеристикой, то сперва я снимаю с него данные, чтобы понять: как выглядит картина в целом. Далее перевожу табличный вид к графическому, и строю, как в нормальных координатах, так и в логарифмических. В данном случае получилось даже хуже: исходная функция y = f(x) близка к прямой, если строить её в координатах: y2 = ln(y) и x2 = ln(x). Однако, это неприемлемо, так как на входе АЦП из-за дискретизации будет сильное искажение в определённом диапазоне. Пришлось применить небольшую схему со "своей нелинейностью", которая частично компенсирует эффект ln(x), и всё приводится к: y = e ^ f2(x), но для вычисления f2(x) с достаточной точностью необходимо использовать полином пятой степени.

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

[Dale]

Пришлось применить небольшую схему со "своей нелинейностью", которая частично компенсирует эффект ln(x), и всё приводится к: y = e ^ f2(x)

У меня для подобных случаев припасена коробочка AD8307. Практически не требует дополнительных деталей, и при неплохих параметрах цена на Али порядка 20 рублей за штуку.

[Aether]

У меня для подобных случаев припасена коробочка AD8307.

Спасибо за ликбез, таким способом я ещё не пользовался.

[Dale]

Спасибо за ликбез, таким способом я ещё не пользовался.

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

[Aether]

Откуда взялось столько значащих цифр у float? Возможно, имеется в виду double?

Кстати, есть довольно интересный эффект, например, мы присвоим переменной типа float значение "2.3". Однако, на деле невозможно абсолютно точно передать его в двоичное представление, какой бы разрядности не был формат. Иными словами, после присвоения будет записано 0x40133333, что при полном переводе в десятичное представление будет составлять:
2.2999999523162841796875

Естественно, число значащих цифр для одинарной точности невелико, и при округлении будет то же самое, то есть 2.3, но в CAD и CAM системах на этой почве происходят неприятные неожиданности, например, при обходе контура с коррекцией диаметра инструмента с круговой интерполяцией станок неожиданно встаёт, так как разница между радиусом траектории и инструмента становится отрицательной. Когда я сам пишу постпроцессор, то иногда страхуюсь, проверяя подобные случаи, и при необходимости добавляю 1 мкм - на реальной обработке это не скажется, а от нюансов избавит. Также при перестройке 3D геометрии в CAD происходят такие случаи, что пользователь, округлив значение угла, особенно до 3-4 знака, создаёт ситуацию невозможности в сборке. Но, это уже опытные конструктора знают, и обходят, изменяя обычно стратегию моделирования.

[Dale]

Кстати, есть довольно интересный эффект, например, мы присвоим переменной типа float значение "2.3". Однако, на деле невозможно абсолютно точно передать его в двоичное представление, какой бы разрядности не был формат.

Так это ведь вполне естественное свойство рациональных чисел - представление в виде дроби с бесконечным (в общем случае) числом разрядов. Основание системы счисления тут ни при чем, будь то двоичное, десятичное или любое другое. Просто по прихоти эволюции наш первый с младенчества счетный инструмент - пальцы - имеет разрядность 10, поэтому для нас число 2.3₁₀ кажется "круглым". А если взять, скажем, число 2³/₇, которое в принципе ничем не хуже, чем 2³/₁₀, то получим совершенно безобразное десятичное представление: 2,4285714285714286... Зато в семеричной системе красота: 2.3₇.

Какую бы систему счисления мы ни взяли, для нее все равно найдутся свои "неудобные" числа. Мы вот привыкли к десятичным дробям, а у меня в шкафчике при этом лежит набор конических сверел с шагом ¹/₁₆ дюйма, который способен довести его обладателя до сумасшествия, если под рукой нет калькулятора (или на худой конец миллиметрового штангеля)...

Иными словами, после присвоения будет записано 0x40133333, что при полном переводе в десятичное представление будет составлять:
2.2999999523162841796875

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

Тут, пожалуй, суть даже не в округлении...

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

Нужно нам после этого гоняться за этими блохами в седьмом-восьмом знаке?

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

Это интересный эффект, можно поподробнее?

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

Также при перестройке 3D геометрии в CAD происходят такие случаи, что пользователь, округлив значение угла, особенно до 3-4 знака, создаёт ситуацию невозможности в сборке.

Это, видимо, у сборщиков кувалды слишком маленькие. Сомневаюсь, что на том же ВАЗе точности такого же порядка, и ничего - уговаривают деталь встать на место.

[Aether]

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

Не совсем, при кратном основании проблема идентичности представления отсутствует, то есть, число, записанное в двоичной системе, будет одинаково выражено при 4, 8, 16, 2ⁿ основаниях. Естественно, это не отменяет существования иррациональных чисел и простых дробей с не кратным данной системе знаменателем.

Просто по прихоти эволюции наш первый с младенчества счетный инструмент - пальцы - имеет разрядность 10, поэтому для нас число 2.3₁₀ кажется "круглым".

Довольно давно я разговаривал с человеком, который занимается археологией и историей. Так вот, от него я узнал, что этот вопрос до недавнего, по историческим меркам, времени не был столь однозначен. В юго-восточной Азии широко пользовались пятеричной, причём одной рукой загибали единицы, а другой "десятки", то есть пятёрки, таким образом, на руках можно было считать от 0 до 30. На ближнем востоке у шумеров использовалась шестидесятеричная система счёта - одной рукой считали до 12 - число фаланг на руке, зажимая нужную фалангу большим пальцем, а другой двенашки, которых могло быть пять, итого: 12 * 5 = 60, а максимальное число, которое можно было выразить на руках - 72. В северной Европе пользовались просто двенадцатеричной, которая в современном виде представлена в метрологии англоязычных стран: 1 фут = 12 дюймам, 1 дюйм = 12 коротким линиям. В центральной Европе и доколумбовской Америке имела ход восьмеричная система счёта.

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

Какую бы систему счисления мы ни взяли, для нее все равно найдутся свои "неудобные" числа.

Конечно.

Мы вот привыкли к десятичным дробям, а у меня в шкафчике при этом лежит набор конических сверел с шагом ¹/₁₆ дюйма, который способен довести его обладателя до сумасшествия, если под рукой нет калькулятора (или на худой конец миллиметрового штангеля)...

А вот, что касается штангеля, линеек, рулеток - дюймовые мне приятнее, казалось бы 1 мм и 1,27 мм штрихи, но 1,27 видно чётче.

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

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

Нужно нам после этого гоняться за этими блохами в седьмом-восьмом знаке?

В CAD прямого рисования - AutoCAD и его производные - нужно. В параметрических CAD нет, но там свои особенности, хотя это направление я считаю более правильным. Стратегия увеличения точности, будь то переход на 128 бит формат, не оправдана.

Это интересный эффект, можно поподробнее?

Я полагаю, у Вас скорее всего работы с коррекцией не будет, но может встретиться такое:
Круговая интерполяция - это команды G2/G3. Для указания дуги необходимы три привязки, и существуют две стандартные системы их указания: через начальную, конечную точки и радиус, либо через начальную, конечную точки и центр дуги. В практике, обычно, используется первый вариант, так как человеку он понятнее. Радиус при этом можно указывать с "+" и с "-" - это направление хода дуги.

Так вот, начальная точка задана начальным положением, а в синтаксисе G2/G3 необходимо передать конечную точку и радиус, например:
G1 X0. Y0. F100; Обработка прямого участка до X = 0. и Y = 0.
G2 X20. Y0. R10. F100; Обработка дуги.

А это не прокатит:
G2 X20. Y0. R9.999 F100
G2 X20.001 Y0. R10. F100

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

Это, видимо, у сборщиков кувалды слишком маленькие. Сомневаюсь, что на том же ВАЗе точности такого же порядка, и ничего - уговаривают деталь встать на место.

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

[Dale]

На ближнем востоке у шумеров использовалась шестидесятеричная система счёта

Все мы латентные шумеры: до сих пор делим час (и угловой градус) на 60 минут, минуту - на 60 секунд. Десятичные градусы также не прижились.

В северной Европе пользовались просто двенадцатеричной

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

В центральной Европе и доколумбовской Америке имела ход восьмеричная система счёта.

А также в среде некогда многочисленных пользователей PDP-11.

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

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

когда бухгалтер, например, пишет в графе 2.3, то он не знает, что это на самом деле будет записано, как 2.2999...

Но так и не следует записывать. Представлять валюты в виде мантисса-порядок - довольно серьезный промах программиста. Для этого применяются специальные типы с фиксированной точкой, в разных языках программирования они называются по-разному (money, fixed, numeric, decimal, ...), но суть одна - с ростом числа разрядов точность представления не уменьшается.

Круговая интерполяция - это команды G2/G3. Для указания дуги необходимы три привязки, и существуют две стандартные системы их указания: через начальную, конечную точки и радиус, либо через начальную, конечную точки и центр дуги. В практике, обычно, используется первый вариант, так как человеку он понятнее. Радиус при этом можно указывать с "+" и с "-" - это направление хода дуги.

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

G2 X20. Y0. R10. F100; Обработка дуги.

А это не прокатит:
G2 X20. Y0. R9.999 F100
G2 X20.001 Y0. R10. F100

Тут не понял подвоха. Вроде с точки зрения стандарта ISO 6983-1 преступлений нет, с точки зрения геометрии тоже. Ну разве что в первом случае радиус чуть уменьшился, во втором конечная точка чуть сместилась. Построить эту фигуру циркулем и линейкой вполне реально, почему станок не справляется?

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

Вот что действительно непонятно, так это построение дуги по 6 координатам (3 пары: начало, конец, центр). На самом деле независимы из них только 5, 6-я вычисляется по ним. Если значения не согласованы, действительно возникает неопределенность, и контроллер имеет право впасть в ступор. Тут в стандарте действительно заложен источник ошибок.

[Aether]

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

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

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

О, эта терминология, ход дуги бывает короткий (+) и длинный (-), соответствует расположению центра дуги либо с одной стороны, либо с другой. А за направление интерполяции отвечает команда G2 - по часовой, G3 - против. Знак "-" используется очень редко.

Тут не понял подвоха. Вроде с точки зрения стандарта ISO 6983-1 преступлений нет, с точки зрения геометрии тоже. Ну разве что в первом случае радиус чуть уменьшился, во втором конечная точка чуть сместилась. Построить эту фигуру циркулем и линейкой вполне реально, почему станок не справляется?

Смотрим детальнее:
x1 = 0. y1 = 0.
x2 = 20. y2 = 0.
Таким образом, дуга минимального радиуса будет представлена половиной круга. Соответственно, её диаметр будет равен (20. - 0.) = 20. А радиус 20./2 = 10. С точки зрения геометрии, невозможно построить дугу с радиусом меньшим 10. - его просто не хватит.

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

Вот что действительно непонятно, так это построение дуги по 6 координатам (3 пары: начало, конец, центр). На самом деле независимы из них только 5, 6-я вычисляется по ним. Если значения не согласованы, действительно возникает неопределенность, и контроллер имеет право впасть в ступор. Тут в стандарте действительно заложен источник ошибок.

Сейчас такое решение используется в машинах листового раскроя совместно с инкрементной системой отсчёта, например, ESAB Combirex:
+200++100+
аналогична предыдущей G2 X20. Y0. R10. F100;
Ошибки там бывают, в том числе конские, а в целом, я думаю, что переопределение используется для расчёта среднего значения.

[Dale]

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

Я живых студентов давно уже не видел, но вроде их сейчас при подготовке к ЕГЭ должны на такие типовые вещи натаскивать? Не построил касательную - не стал студентом. Говорят, сейчас там все строго, ни шпаргалок, ни мобилок, ни суфлеров.

дуга минимального радиуса будет представлена половиной круга.

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