>> что такое там было всегда, только было скрыто от глаз
Такое есть в каждой программе, преобразующей входные двоично-десятичные данные в чисто двоичные, которые обсчитываются быстрее, т.к. вся математика происходит в native (для двоичной логики) представлении безо всяких условностей типа «если при сложении младшей тетрады получилось число, большее 9, то следует прибавить 6, а единичку добавить к старшей тетраде…» и т.п.
Только обычно вся эта математика в библиотеках скрыта от глаз пользователя и последний раз я с подобного рода глюками встречался аж 14 лет назад в ChiSoft PASCAL'е (авт. Антон ЧИЖОВ) для MSX. Но там это было документировано и мотивировалось экономией ОЗУ (вот ведь были времена — на чем приходилось копейки экономить). А здесь глюк сидит в печальной памяти Dialog manager'e (это только предположение), к созданию которого, стыдно сказать, приложил голову (или другое место?) наш соотечественник (проскальзывало где-то в этой ветке).
>> с точность, большей, чем ОТОБРАЖАЕТСЯ ПОТОМ
Скорее всего просто некто неправильно задал формат отображения числа в окошке, результатом чего явилось «выскакивание» незначащей 4-й цифры и чудесное превращение ее в значащую. С соотвествующими «прелестями».
>> именно неточнось отображения
Если бы только отображения — так и при вводе координаты в результате уплывают, т.к. в качестве величины начинает использоваться «исправленное» значение. Если точно известен иходный размер, то его можно набить ручками, хотя это и не очень удобно. А если неизвестен? Тогда приходится пользоваться тем, что есть или смотреть в info palette
Вся цифирь, не проходящая через горнило ADM, например cохранение в EPS или PDF переводит координаты в десятичную форму корректно.
>> с этим что-то надо делать...
Это вопрос к ZG
Такое есть в каждой программе, преобразующей входные двоично-десятичные данные в чисто двоичные, которые обсчитываются быстрее, т.к. вся математика происходит в native (для двоичной логики) представлении безо всяких условностей типа «если при сложении младшей тетрады получилось число, большее 9, то следует прибавить 6, а единичку добавить к старшей тетраде…» и т.п.
Только обычно вся эта математика в библиотеках скрыта от глаз пользователя и последний раз я с подобного рода глюками встречался аж 14 лет назад в ChiSoft PASCAL'е (авт. Антон ЧИЖОВ) для MSX. Но там это было документировано и мотивировалось экономией ОЗУ (вот ведь были времена — на чем приходилось копейки экономить). А здесь глюк сидит в печальной памяти Dialog manager'e (это только предположение), к созданию которого, стыдно сказать, приложил голову (или другое место?) наш соотечественник (проскальзывало где-то в этой ветке).
>> с точность, большей, чем ОТОБРАЖАЕТСЯ ПОТОМ
Скорее всего просто некто неправильно задал формат отображения числа в окошке, результатом чего явилось «выскакивание» незначащей 4-й цифры и чудесное превращение ее в значащую. С соотвествующими «прелестями».
>> именно неточнось отображения
Если бы только отображения — так и при вводе координаты в результате уплывают, т.к. в качестве величины начинает использоваться «исправленное» значение. Если точно известен иходный размер, то его можно набить ручками, хотя это и не очень удобно. А если неизвестен? Тогда приходится пользоваться тем, что есть или смотреть в info palette
Вся цифирь, не проходящая через горнило ADM, например cохранение в EPS или PDF переводит координаты в десятичную форму корректно.
>> с этим что-то надо делать...
Это вопрос к ZG
- Рейтинг
- 5
Arkady wrote:
>
> >> 64.125 pt
> >> если двигать квадрат с такой стороной по полосе, то рано
> или поздно "и это пройдет"
>
> Надо же, и правда :-( Самое страшное — при достаточно долгом
> перемещении размер ПОСТЕПЕННО меняется. Немного, но все-таки…
неудивительно.. тут уже будут 2 погрешности округления для Х1, Х3 и плюс погрешность округления при вычислении ширины=Х3-Х1.
проверил под 8 илом (правил аишник):
150.00072 pt округляется до 150, а
150.00073 pt округляется до 150.001 и
150.00072479 округляется до 150, а
150.0007248 округляется до 150.001
>
> >> 64.125 pt
> >> если двигать квадрат с такой стороной по полосе, то рано
> или поздно "и это пройдет"
>
> Надо же, и правда :-( Самое страшное — при достаточно долгом
> перемещении размер ПОСТЕПЕННО меняется. Немного, но все-таки…
неудивительно.. тут уже будут 2 погрешности округления для Х1, Х3 и плюс погрешность округления при вычислении ширины=Х3-Х1.
проверил под 8 илом (правил аишник):
150.00072 pt округляется до 150, а
150.00073 pt округляется до 150.001 и
150.00072479 округляется до 150, а
150.0007248 округляется до 150.001
"Глюки" не тока в CS, но уже и в этой ветке (см. топик) 
))
На своей Iiyame 19" 1600х1200 (это типа поля много) в сантиметрах тягал разные кубики да кружочки, терпения хватило минут на 20, побывал в разных уголках рабочего поля, как ни странно, но при перетаскивании размеры не менялись... Ага, ща скажут, что типа у меня beta версия Ила )
Не думал, что данная тема может так развиться
))На своей Iiyame 19" 1600х1200 (это типа поля много
) в сантиметрах тягал разные кубики да кружочки, терпения хватило минут на 20, побывал в разных уголках рабочего поля, как ни странно, но при перетаскивании размеры не менялись... Ага, ща скажут, что типа у меня beta версия Ила )Не думал, что данная тема может так развиться
Arkady wrote:
> А что, разве отношение точки к миллиметру — конечная
> десятичная дробь?
а причем тут это?
пример:
после ввода какого-то значения в чем угодно в тысячных долях пункта получилось: 283464.
пересчитываем в милиметры:
283464*25.4/(1000*72)=99.9998
это точный результат. пятого знака просто нет.
> А потом, как объяснить появление размеров
> вида 600.0005 pt для размеров, заданных именно в pt?
расскажите о методе получения. у меня ни вышло.
> При четырех значащих цифрах мы должны вычислять пятую,
> незначащую цифру.
хех - нет ее. размер в тысячных долях пункта нацело делицца на 72 и все.
> 1. Нарисуй прямоугольник с одной из сторон 1000 pt
> 2. В Transform palette подели этот размер на 11
> 3. Согласно правилам округления должен получится результат
> 9.9091 (четыре значащих цитфры, реально получается
> периодическая десятичная дробь 9.09(09) ). А что получилось?
у меня сначала 9.9091, через несколько миллисекунд - 9.9092.
> А что, разве отношение точки к миллиметру — конечная
> десятичная дробь?
а причем тут это?
пример:
после ввода какого-то значения в чем угодно в тысячных долях пункта получилось: 283464.
пересчитываем в милиметры:
283464*25.4/(1000*72)=99.9998
это точный результат. пятого знака просто нет.
> А потом, как объяснить появление размеров
> вида 600.0005 pt для размеров, заданных именно в pt?
расскажите о методе получения. у меня ни вышло.
> При четырех значащих цифрах мы должны вычислять пятую,
> незначащую цифру.
хех - нет ее. размер в тысячных долях пункта нацело делицца на 72 и все.
> 1. Нарисуй прямоугольник с одной из сторон 1000 pt
> 2. В Transform palette подели этот размер на 11
> 3. Согласно правилам округления должен получится результат
> 9.9091 (четыре значащих цитфры, реально получается
> периодическая десятичная дробь 9.09(09) ). А что получилось?
у меня сначала 9.9091, через несколько миллисекунд - 9.9092.
>> вы сначала посчитайте, каково должно быть разрешение выводного устройства для того чтобы заметить разницу в 0,0005 мм, помедитируйте над результатом, а потом и погойворим.
Устройство здесь ни причем, так что предлагаю говорить прямо сейчас. Советую Вам прочитать любой учебник по мат. основам измерений и перед Вами откроется простая истина — чтобы получить достоверную N-ю цифру, необходимо вычислить недостоверную N+1 цифру. При этом в результат записываются N цифр.
Если же эту самую N+1 цифру выдавать за достоверную — будем иметь то же самое, что и происходит сейчас в transform palette. Или Вы считаете, что автоматическое преобразование 1000pt в 999.9998 pt — это нормально? А формат листа 297.0001 мм — тоже в порядке вещей?
Устройство здесь ни причем, так что предлагаю говорить прямо сейчас. Советую Вам прочитать любой учебник по мат. основам измерений и перед Вами откроется простая истина — чтобы получить достоверную N-ю цифру, необходимо вычислить недостоверную N+1 цифру. При этом в результат записываются N цифр.
Если же эту самую N+1 цифру выдавать за достоверную — будем иметь то же самое, что и происходит сейчас в transform palette. Или Вы считаете, что автоматическое преобразование 1000pt в 999.9998 pt — это нормально? А формат листа 297.0001 мм — тоже в порядке вещей?
И в продолжении темы — неужели в Adobe совсем уже такие дураки сидят, что ни с того ни с сего сделали в «считающих» окнах AI четыре цифры (те же «0,0005 мм»), оставив в аналогичных местах PhSh и InD, да и в Info самого AI всего три цифры. Помимо весьма сомнительной целесообразности такой точности представления — в чем Вы и сами, как я вижу, не сомневаетесь, поведение этой цифры при вычислениях в окне дает веские основание предположить, что это и есть та самая «N+1» цифра, которая должна служить для правильного вычисления последней, третьей значащей цифры. Все бы ничего, но эта же «N+1» цифра используется при вводе данных из этого же окошка, т.е. получается накапливающаяся ошибка.