Oberon space
General Category => Общий раздел => Тема начата: vlad от Март 14, 2011, 02:25:46 pm
-
оригинальная ветка: http://forum.oberoncore.ru/viewtopic.php?p=61461#p61461
Суть проблемы, вроде как, состоит в том, что три дискретных числовых оси не совпадают. Эти дискретные числовые оси соответствуют десятичному представлению и двум двоичным (SHORTREAL и REAL).
Суть проблемы не только в различии представления, но и вообще в потере точности при вычислениях. Те же самые грабли вы получите с одним и тем же вещественным типом, сравнив на равенство результаты 2/3 и 4/6. Так что идея запретить в языке сравнение вещественных типов не такая уж и плохая, учитывая что многие руководства по граблям так и пишут "не сравнивайте на равенство вещественные типы".
-
некоторые рефаловцы вообще считают что плавающая точка это зло :-)
-
Суть проблемы не только в различии представления, но и вообще в потере точности при вычислениях.
Да, потеря точности есть. И с этим фактом принципиально ничего не поделать. Увеличение разрядности уменьшит погрешность, но не решит проблему в корне. Подчёркиваю (уже повторно), что с этим я даже не предлагаю бороться.
Но как можно запретить сравнивать вещественные числа? Ведь необходимость в этом обычно исходит из самой задачи.
Я начинаю склоняться к мысли, что проблема сравнения вещественных чисел всё-таки решабельна.
-
Плавающая точка - это не зло, а объективная реальность, данная нам в стандарте IEEE Standard 754 и закреплённая в языке. :)
-
Но как можно запретить сравнивать вещественные числа? Ведь необходимость в этом обычно исходит из самой задачи.
Ну в смысле как? Как обычно: (x + погрешность) > y > (x - погрешность). Причем погрешность выбирается "из самой задачи".
-
Ну в смысле как? Как обычно: (x + погрешность) > y > (x - погрешность). Причем погрешность выбирается "из самой задачи".
Да, я сейчас так и поступаю (кстати, сравнение как таковое в этом варианте никуда не делось).
Но свои "хотелки" я уже озвучил: перенести решение с уровня задачи на уровень языка (чем и рассмешил Info21 :)).
-
Ну в смысле как? Как обычно: (x + погрешность) > y > (x - погрешность). Причем погрешность выбирается "из самой задачи".
Да, я сейчас так и поступаю (кстати, сравнение как таковое в этом варианте никуда не делось).
Дык. Конечно речь о сравнении на равенство. Больше/меньше проблем не создает.
Но свои "хотелки" я уже озвучил: перенести решение с уровня задачи на уровень языка (чем и рассмешил Info21 :)).
Общего решения пока нет, переносить нечего :) А проблема есть. Для начала неплохо бы ее явно обозначить - например, запретив сравнение на равенство :) А чтоб не так жестко, предоставить какую-нибудь стандартную функцию: eq(x, y, eps).
-
Кроме того, что я просто не хочу запрещать сравнение вещ. чисел на равенство, я ещё и не представляю как это сделать безболезненно. Ведь вместо банальных x и y в общем случае могут быть сложные выражения (либо x и y вычисляются перед использованием в логическом выражении), тип результата которых станет известен только на этапе выполнения программы. И что должна делать программа, если этот тип окажется вещественным? Аварийное завершение?
-
Кроме того, что я просто не хочу запрещать сравнение вещ. чисел на равенство, я ещё и не представляю как это сделать безболезненно. Ведь вместо банальных x и y в общем случае могут быть сложные выражения (либо x и y вычисляются перед использованием в логическом выражении), тип результата которых станет известен только на этапе выполнения программы. И что должна делать программа, если этот тип окажется вещественным? Аварийное завершение?
Гхм. Если речь идет о статически-типизированном языке (а-ля оберон), то тип всех выражений известен на этапе компиляции. Независимо от сложности. Так что "оказаться вещественным" он может только на этапе компиляции.
-
Аварийное завершение?
Если речь идет о статически-типизированном языке (а-ля оберон), то ...
Хорошо, тогда вопрос снимается.
А что Вы скажете по поводу идеи, которую я изложил здесь: http://forum.oberoncore.ru/viewtopic.php?f=29&t=3327&p=61464#p61464 (http://forum.oberoncore.ru/viewtopic.php?f=29&t=3327&p=61464#p61464) (см. также предыдущий пост)
-
А что Вы скажете по поводу идеи, которую я изложил здесь: http://forum.oberoncore.ru/viewtopic.php?f=29&t=3327&p=61464#p61464 (http://forum.oberoncore.ru/viewtopic.php?f=29&t=3327&p=61464#p61464) (см. также предыдущий пост)
ИМХО, нельзя просто брать и чего-то отсекать. Вещественные числа - это сложно. Можно принять какие-то "умолчания" и попытаться сделать просто. Но не в языке, с претензией на максимальную прозрачность и отсутствие скрытых граблей. По моему опыту, стыковок между вещественными/целыми бывает не так уж и много и их хочется видеть в явном виде. И либо эти стыковки совсем не парят (показать на экране график функции, так что +/- пиксел не принципиален) и тогда нужно какое-нибудь дубовое (максимально быстрое) округление. Либо это принципиальная штука (разница в пиксел принципиальна, потому что она заметна в случае позиционирования фигур с "почти одинаковыми" координатами) и никакие встроенные в компилятор штуки не спасут - нужен индивидуальный подход.
-
Примерно из той же оперы. Есть такой фрэймворк на маке (вроде и не только) - quartz. Грубо говоря, чтоб рисовать где только можно и как только можно. Там все круто - забудьте о пикселах, вот вам вещественные координаты, антиалиасинг и т.д. Классно. Только при ближайшем рассмотрении оказывается, что для того, чтобы нарисованное выглядело прилично на мониторе - нужно знать, что такое пиксел и формировать координаты соответственно. Например, горизонтальна линия с координатами (0,0) - (100,0) и толщиной 1 - выглядит неприемлимо. А вот с координатами (0,0.5) - (100,0.5) - нормально. А вот линия с толщиной 2 - наоборот. Приличное рисование геометрических примитивов в таком фрэймворке - страшный гемор и требует "особенного" подхода к округлению и преобразованиям между целыми и вещественными. В компилятор такую фигню не засунуть в принципе.
-
ИМХО, нельзя просто брать и чего-то отсекать. Вещественные числа - это сложно. Можно принять какие-то "умолчания" и попытаться сделать просто. Но не в языке, с претензией на максимальную прозрачность и отсутствие скрытых граблей. По моему опыту, стыковок между вещественными/целыми бывает не так уж и много и их хочется видеть в явном виде. И либо эти стыковки совсем не парят (показать на экране график функции, так что +/- пиксел не принципиален) и тогда нужно какое-нибудь дубовое (максимально быстрое) округление. Либо это принципиальная штука (разница в пиксел принципиальна, потому что она заметна в случае позиционирования фигур с "почти одинаковыми" координатами) и никакие встроенные в компилятор штуки не спасут - нужен индивидуальный подход.
Спасибо, интересное мнение.
Но пока я всё-же остаюсь при своём мнении. Если абсолютная точность принципиально недостижима, то реализация неточного сравнения - это не "скрытые грабли", а разумный компромисс. Нужно только не забыть прописать об этом в спецификации!!!
PS: 0.1 # 0.1 -- вот это конкретные грабли. :D
-
Есть такой фрэймворк на маке (вроде и не только) - quartz. ... Приличное рисование геометрических примитивов в таком фрэймворке - страшный гемор и требует "особенного" подхода к округлению и преобразованиям между целыми и вещественными.
Думаю, что дело здесь в откровенно плохой реализации (без учёта реального растра, на котором нужно рисовать). Скажем, в том же MS Visio таких проблем не возникает (там другие проблемы :)).
-
Есть такой фрэймворк на маке (вроде и не только) - quartz. ... Приличное рисование геометрических примитивов в таком фрэймворке - страшный гемор и требует "особенного" подхода к округлению и преобразованиям между целыми и вещественными.
Думаю, что дело здесь в откровенно плохой реализации (без учёта реального растра, на котором нужно рисовать).
Не, реализация там не причем. Там просто приняты другие "правила" рисования. Они по-своему хороши и с математической точки зрения намного естественнее и правильнее классических "пиксельных" правил. Причем это все хорошо работает, например, для принтеров, потому что масштабы не те. А на мониторах это нифига не работает и реализация не может "правильно учесть растр" - она не может знать в какую сторону ей сместить линию с координатой 0.5 (вверх или вниз), поэтому она рисует две полупрозрачные линии с координатами 0 и 1.
-
А на мониторах это нифига не работает и реализация не может "правильно учесть растр" - она не может знать в какую сторону ей сместить линию с координатой 0.5 (вверх или вниз), поэтому она рисует две полупрозрачные линии с координатами 0 и 1.
А должна была бы округлить координату 0.5 до целого и нарисовать одну плотную линию в нужном месте с точностью до межпиксельного расстояния. А вот с наклонными линиями тактика всё-же должна быть наверно другой.
-
А на мониторах это нифига не работает и реализация не может "правильно учесть растр" - она не может знать в какую сторону ей сместить линию с координатой 0.5 (вверх или вниз), поэтому она рисует две полупрозрачные линии с координатами 0 и 1.
А должна была бы округлить координату 0.5 до целого и нарисовать одну плотную линию в нужном месте с точностью до межпиксельного расстояния. А вот с наклонными линиями тактика всё-же должна быть наверно другой.
Не может она сама округлить. Потому что ожидается, что линии 0.5000001 и 0.4999999 должны быть визуально неотличимы. Так же как 0.9999999 и 1.0000001.
P.S. Да, с наклонными вообще песня...
-
А на мониторах это нифига не работает и реализация не может "правильно учесть растр" - она не может знать в какую сторону ей сместить линию с координатой 0.5 (вверх или вниз), поэтому она рисует две полупрозрачные линии с координатами 0 и 1.
А должна была бы округлить координату 0.5 до целого и нарисовать одну плотную линию в нужном месте с точностью до межпиксельного расстояния. А вот с наклонными линиями тактика всё-же должна быть наверно другой.
Все не так просто. Действительно, получение сглаженных линий толщиной в один пиксель та еще задача!
Для целей сглаживания (anti-aliasing) применяются не пиксельные координаты, а логические. В разных методах сглаживания применяются разные разные способы сопоставления логических и пиксельных координат. В Qt, например (http://doc.qt.nokia.com/4.7/coordsys.html), при выключенном сглаживании пиксели рисуются справа и снизу от логической точки, при включенном сглаживании - вокруг математической точки. В AGG строго вокруг логической точки в любом случае; для рисования примитивов в один пиксель созданы отдельные рендереры.
Поэтому, действительно, приходится танцевать с бубном, чтобы получить вменяемый результат. Но округление здесь совсем не причем - во всем виновато субпиксельное сглаживание ;)
-
Субпиксельное сглаживание оно ведь учитывает специфику TFT-матрицы, поэтому сглаживание далеко не всегда субпиксельное. Особенно не шрифтов, а просто линий.
А Qt без сглаживание смотрится просто отвратно. Там такие мохры у линий вылазят, это что-то.
Лучшее сглаживание – это dpi хотя бы как у iPhone 4 и никакого софтверного сглаживания.
-
Субпиксельных сглаживаний много ;)
То, что заявлено MS как ClearType - да, пытается учитывать то, что вывод будет идти на TFT матрицу. В других случаях оно никак не связано с физической поверхностью вывода графики.
Без сглаживания везде плохо смотрится, если не прямоугольники рисовать.
-
Субпиксельных сглаживаний много ;)
То, что заявлено MS как ClearType - да, пытается учитывать то, что вывод будет идти на TFT матрицу. В других случаях оно никак не связано с физической поверхностью вывода графики.
Без сглаживания везде плохо смотрится, если не прямоугольники рисовать.
Ой, ну таки не надо пытаться что-то куда-то вешать разработчику приложений мобильные платформы, которым я таки периодически являюсь. :-)
В Симбиане нет сглаживания, в iOS нет сглаживания, и все отлично смотрится. Просто потому, что dpi высокое. Нет сглаживания, нет и артефактов и работает быстрее.
Про мелкософты не скажу, ибо не интересуюсь, но вот таки в Haiku рендерер шрифтов таки умеет использовать субпиксельное сглаживание. И я видел работы по субпиксельному сглаживанию уменьшеных картинок.
Но сглаживание это от бедности. Для того, чтобы было нормально, нужно нормальное dpi. На уровне dpi принтеров лазерных.
И таки да, еще раз – есть просто сглаживание (с помощью того же альфа-канала), а есть субпиксельное сглаживание, когда учитывается наличие как раз тех самых субпикселей, то есть тот факт, что у нас точка не точка на экране а троеточка. По большей части субпиксель не используется.
-
Хороший DPI это круто, не спорю. На iPhone действительно все смотрится круто.
В Haiku шрифты как рас сглаживаются AGG :) И там субпиксель это не точка в троеточии, а 1/256 пикселя.
Приведу две картинки с сайта AGG (http://antigrain.com). Один и тот же текст сдвигается на 1/10 пикселя. с субпиксельным сглаживанием и без оного. Там, где логическая точка равна 1/256 пикселя результат оччень даже симпатичный. Но, возвращаясь к вопросу об округлении, чтобы нарисовать линию в один пиксель надо постараться и поиграться с координатами.
-
Хороший DPI это круто, не спорю. На iPhone действительно все смотрится круто.
В Haiku шрифты как рас сглаживаются AGG :) И там субпиксель это не точка в троеточии, а 1/256 пикселя.
Приведу две картинки с сайта AGG (http://antigrain.com). Один и тот же текст сдвигается на 1/10 пикселя. с субпиксельным сглаживанием и без оного. Там, где логическая точка равна 1/256 пикселя результат оччень даже симпатичный. Но, возвращаясь к вопросу об округлении, чтобы нарисовать линию в один пиксель надо постараться и поиграться с координатами.
Epic fail – в обоих случаях рендеринг шрифта таки использует оную троеточку. Предлагаю увеличить картинку и заценить прекрасное расслоение одной линии на три. Позиционирование изображение тут да, субпиксельное (даже если убрать троеточку), но сглаживание тут обычное, попиксельное :-) Попиксельное сглаживание позволяет делать субпиксельное позиционирование.
-
И да, таки на счет Haiku я в курсе, потому как я этой системой пользуюсь периодически, ну и вообще я старый BeOS'ник :-) И там (Haiku) шрифты умеют как просто через grayscale/alpha сглаживаться, так и использовать субпиксельное сглаживание.
А позиционирование с точность в 1/256 пикселя просто потому, что альфаканал у нас имеет диапазон значений от 0 до 255 :-)
Кстати, очень интересно было бы посмотреть на это все не в rgba, а в yuv420p например :-) Что-то мне подсказывает, что там будет фиг а не позиционирование с десятыми долями точек без цветовых артефактов. Ибо там даже нормально с точностью до одной точки не всегда получается сделать.
-
расслоение одной линии на три.
Ну где на три, а где и на пять-шесть.
Этот текст отрендерен, вероятнее всего, в рендерере RGBA или BGRA, что дает размытие черного цвета на составляющие при субпиксельном сдвиге. Ничего криминального, нормальный эффект. При применении Grayscale renderer было бы строго серенькое с черненьким, т.е. никакого цвета.
Еще раз подчеркнуть хочу, что субпиксельное сглаживание - это способ работы с картинкой в логических координатах, причем эти координаты на два-три порядка отличаются от пиксельных координат. Делать это имеет смысл только при относительно низких DPI. Никакого отношения к использованию TFT и факта разложения пикселя на тройку цветов в общем случае это не имеет.
О чем спорим? ;)
-
Кстати, вот на этой картинке из википедии:
(http://upload.wikimedia.org/wikipedia/commons/7/7e/ClearType01.png)
У меня лично хуже всего смотрится линия нумер 2 – она серая, размытая, какая-то невнятная. Линия 1 и линия 3 смотрятся практически идентично, у линии 3 чуть виден красноватый отблеск по верхней кромке, в остальном они практически идентичны. Линия 1 без сглаживания вообще, линия 2 с попиксельным сглаживанием (и естественно субпиксельным позиционированием), линия 3 с субпиксельным сглаживанием.
Смотрю с ноута 15-шки, разрешение 1440x900. Не вижу причин использовать линии типа 2 вообще. Если только у кого-то старые десктопные мониторы с 72 dpi или около того остались еще. Если нужно позиционирование точнее 1 пикселя, тогда имеет смысл использовать линии третьего типа.
Статья в вики (http://ru.wikipedia.org/wiki/ClearType#.D0.A8.D0.B0.D0.B3_1._.D0.A1.D1.83.D0.B1.D0.BF.D0.B8.D0.BA.D1.81.D0.B5.D0.BB.D1.8C.D0.BD.D1.8B.D0.B9_.D1.80.D0.B5.D0.BD.D0.B4.D0.B5.D1.80.D0.B8.D0.BD.D0.B3)
PS. Посмотрел на эту картинку с iPhone, различий в линиях не увидел вообще.
-
расслоение одной линии на три.
Ну где на три, а где и на пять-шесть.
Этот текст отрендерен, вероятнее всего, в рендерере RGBA или BGRA, что дает размытие черного цвета на составляющие при субпиксельном сдвиге. Ничего криминального, нормальный эффект.
Это не так хотя бы потому, что первый образец по определению никто субпиксельно не сдвигал, сдвигали четко на 1 пиксель рывком, так вот, там в точности то же самое расслоение. Кроме того, при определенном значении субпиксельного сдвига расслоение на второй картинке должно было бы полностью пропасть, этого не случилось.
Отрисовка шла скорее всего через freetype (agg это умеет), а freetype умеет субпиксельно сглаживать при рендеринге, в отличае от agg. Вообще отрисовка шрифтов не показательна, ибо тут слишком много слоев рендеринга наворочено. В частности зависит и от самого шрифта многое, от того же хинтинга например. :-)
-
И таки да. спорим мы о терминах :-) Это всегда очень увлекательно. :-)
Я таки предлагаю не путать субпиксельное позиционирование граф. элемента с субпиксельным сглаживанием.
-
Набор операций сравнения действительных чисел <, =, > заменить на один из наборов <, >= или <=, > .
И что это таки даст?
С любым из этих наборов я смогу проверить на строгое равенство и внезапно получить хрень.
Ну: пусть у нас есть < и >=
a, b: REAL;
is_eq : BOOL;
is_eq := NOT ( (a < b) OR (b < a) )
Тут достаточно одного < :-)
-
Набор операций сравнения действительных чисел <, =, > заменить на один из наборов <, >= или <=, > .
И что это таки даст?
С любым из этих наборов я смогу проверить на строгое равенство и внезапно получить хрень.
Не, понятно, что можно получить хрень. Просто если хрень получается громоздкая, то больше шансов задуматься, прежде чем ее написать :)
-
Не, понятно, что можно получить хрень. Просто если хрень получается громоздкая, то больше шансов задуматься, прежде чем ее написать :)
А она будет громоздкая? Будет ведь нечто вроде eq(a,b) и все.
-
Не, понятно, что можно получить хрень. Просто если хрень получается громоздкая, то больше шансов задуматься, прежде чем ее написать :)
А она будет громоздкая? Будет ведь нечто вроде eq(a,b) и все.
Прежде чем написать такую "eq" - придется подумать, нафига сделали такое ограничение в языке (убрали равенство). Тогда, глядишь, у этой eq появится третий параметр...
-
Набор операций сравнения действительных чисел <, =, > заменить на один из наборов <, >= или <=, > .
И что это таки даст?
Ответил в оригинальной теме, чтобы автор предложения мог видеть мой ответ.
Вдруг, он скажет в ответ что-то такое, о чём я даже не задумывался. :)
-
Но округление здесь совсем не причем - во всем виновато субпиксельное сглаживание ;)
Тема субпиксельного сглаживания очень интересна и достойна отдельного обсуждения.
Алексей, предлагаю её отделить.
-
Cтандартное решение:
Введение в язык соответствующей функции evbool(expression:boolean):boolean которая вычисляет выражкние expression в соответствие с предопределенной в языке констатной eps
и переопределенного варианта evbool(expression:boolean; const neweps:real):boolean -смысл введения этой функции в ЯП - оптимизация вычисления expression на этапе компиляции...
В целях безопасности можно выдавать ошибку компиляции в тех случаях когда expression содержит сравнения значений переменных с плавающей точкой.
-
Ну, таки да. Причем это можно как вшить в язык, так и сделать либой. На выбор. Либой наверно даже лучше.
-
Cтандартное решение:
Введение в язык соответствующей функции evbool(expression:boolean):boolean которая вычисляет выражкние expression в соответствие с предопределенной в языке констатной eps
Да, неплохой вариант. Чем-то перекликается с тем что я предлагал, только у меня эта обёртка логических выражений (с вещественными операндами) как бы вшита в язык, и программист не имеет возможности её обойти. И к тому же машинно-зависимая константа eps не фигурирует в языке.
-
Ну, таки да. Причем это можно как вшить в язык, так и сделать либой. На выбор. Либой наверно даже лучше.
Cомневаюсь,если конечно мы хотим оптимизации вычислений и/или возможности избежать потенциальных проблем на ЭТАПЕ КОМПИЛЯЦИИ...
-
Cомневаюсь,если конечно мы хотим оптимизации вычислений и/или возможности избежать потенциальных проблем на ЭТАПЕ КОМПИЛЯЦИИ...
Хочу пример того, что мы сможем выловить на уровне языка и не сможем выловить на уровне библиотеки (применительно к рассматриваемому вопросу конечно же).
-
Хочу пример того, что мы сможем выловить на уровне языка и не сможем выловить на уровне библиотеки (применительно к рассматриваемому вопросу конечно же).
Хочу пример того как мы сможем это сделать :D
-
расслоение одной линии на три.
Ну где на три, а где и на пять-шесть.
Этот текст отрендерен, вероятнее всего, в рендерере RGBA или BGRA, что дает размытие черного цвета на составляющие при субпиксельном сдвиге. Ничего криминального, нормальный эффект.
Это не так хотя бы потому, что первый образец по определению никто субпиксельно не сдвигал, сдвигали четко на 1 пиксель рывком, так вот, там в точности то же самое расслоение. Кроме того, при определенном значении субпиксельного сдвига расслоение на второй картинке должно было бы полностью пропасть, этого не случилось.
Обе картинки взяты из статьи (http://antigrain.com/research/font_rasterization/index.html) про рендеринг текста. Та картинка, что со сдвигом в пиксель, сделана с выравниванием по пиксельной сетке; другая с субпиксельным выравниванием/сглаживанием.
Отрисовка шла скорее всего через freetype (agg это умеет), а freetype умеет субпиксельно сглаживать при рендеринге, в отличае от agg. Вообще отрисовка шрифтов не показательна, ибо тут слишком много слоев рендеринга наворочено. В частности зависит и от самого шрифта многое, от того же хинтинга например. :-)
Здесь надо иметь ввиду следующее. AGG достаточно большая библиотека, предназначенная для рендеринга векторной графики. Рендеринг текста в ней делается сложно - берется шрифтовая информация (набор кривых второго/третьего порядка) для каждого символа и производится отрисовка этой информации (набора кривых). Шрифтовая информация просится у ОС (WinAPI/freetype) или напрямую из шрифтовых файлов (почему нет?).
На графическую поверхность картинку выводит именно AGG, и "гладкая" картинка сделана именно ей. Поэтому AGG и может обеспечить вывод текста с субпиксельной точностью. На практике это означает, что можно позиционировать картинку (текст в том числе) с точностью до 0.1 пикселя (можно и меньше фракцию делать, но видно это начинается где-то с 0.1-0.3 пикселя в зависимости от цвета и примененных фильтров).
PS. Текст в википедии очень уж рекламный и MS-ный.
-
Набор операций сравнения действительных чисел <, =, > заменить на один из наборов <, >= или <=, > .
И что это таки даст?
Ответил в оригинальной теме, чтобы автор предложения мог видеть мой ответ.
Вдруг, он скажет в ответ что-то такое, о чём я даже не задумывался. :)
Автор предложения может видеть все ответы и здесь. Форум целиком виден для не зарегистрированных пользователей, а ссылку на тему я там оставил.