| | | | |
Некоторые нюансы вывода графиков функций | Полный текст материала
Другие публикации автора: Алексей Легкунец
Цитата или краткий комментарий: «... Обсуждение проблем построения графиков функций на дискретном устройстве, каким является, например, экран ...» |
Важно:- Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
- Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
- При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
- Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.
Добавить свое мнение.
| | Содержит полезные и(или) интересные сведения | [1] | 4 | 66.7% | | | | Ничего особенно нового и интересного | [2] | 2 | 33.3% | | | | Написано неверно (обязательно укажите почему) | [3] | 0 | 0% | | Всего проголосовали: 6 | | | Все понятно, материал читается легко | [1] | 2 | 33.3% | | | | Есть неясности в изложении | [2] | 4 | 66.7% | | | | Непонятно написано, трудно читается | [3] | 0 | 0% | | Всего проголосовали: 6 |
Отслеживать это обсуждение
Всего сообщений: 1502-08-2009 19:56
10-09-2008 09:00сообщение от автора материала что бы верно отобразить график функции, для начала было бы неплохо знать ЧТО это за функция, т.е. иследовать её (нахождения экстремумов - минимумов и максимумов, асимптот и тд).
Из приведенного в скобках вряд-ли что-либо понадобиться.Об асимптотах речь лучше вообще не вести. А вот ООФ(область определения функции и точки разрывов 2-го рода-бесконечные) желательно считать.Тогда пользователя не будут доставать ошибки при вводе х1 и х2, когда последнии выпадают из ООФ.
А я в свое время численно подбирал шаг по х таким, чтобы длина отрезка от предыдущей к текущей точке (именно отрезка, а не его проекции на ось х, который и будет шагом) была приблизительно одинакова (обычно 3-4 экранные точки).
Подобный процесс ,т.е, фактически, неравномерная растяжка оси Х затрудняет оцифровку последней (Это очень важно при расмотрении функции в масштабе, как рассматривать неизвестный участок?)и к тому же чтобы уместить весь график (замечу х1 и х2 заданы)где-то прийдется шаг увеличивать,т.е терять часть информации.
Иначе весь график не поместится. (получаете график резких подъемов и спусков?) Как вы с этим боритесь?
Однако замечу, совершенствование метода вывода графиков подобного вашему не приводит к решению "проблеммы" ,в результате одни выводятся лучше другие хуже или вообще не выводятся. Я считаю что график должен быть информативен, и достоверен и если я беру информацию с графика то она должна быть достоверна,
и поэтому собственно я поднял эту тему.
|
|
09-09-2008 23:12Я думал, здесь будет хотябы затронута проблема вычисления функции вводимой на лету, во время работы программы...
А какие именно проблемы вас интересуют? |
|
09-09-2008 08:17>>> Собственно, с заранее заложенными функциями в программу никаких особых мер и принимать не надо - ведь заранее известны свойства функции.
Излишне категорично. Опустим тот момент, что даже аналитическая функция может оказаться достаточно сложной, чтобы определить все ее экстремумы и особые точки. А как Вам, например, такой вариант:
Вы разрабатываете универсальную процедуру рисования графиков функций. Конкретная функция, график которой нужно нарисовать, будет передаваться в данную процедуру через параметры (по указателю). Никакого пользовательского ввода нет, но конкретный вид функции на этапе разработки "графопостроителя" неизвестен. |
|
09-09-2008 07:57Я думал, здесь будет хотябы затронута проблема вычисления функции вводимой на лету, во время работы программы... Собственно, с заранее заложенными функциями в программу никаких особых мер и принимать не надо - ведь заранее известны свойства функции. По-другому дело будет обстоять если пользователь вводит необходимую функцию во время выполнения программы. |
|
03-09-2008 08:17Господа, для того, что бы верно отобразить график функции, для начала было бы неплохо знать ЧТО это за функция, т.е. иследовать её (нахождения экстремумов - минимумов и максимумов, асимптот и тд). Возможно покажеться бредом, но именно так в програме можно учесть все минимальные загибы и отклонения. Однако такой способ не всегда может дать результат. Опираясь на опыт данный мне сотоварищами-пользователями, скажу, что необходимо точно контролировать ввод и проверять на корректность. |
|
24-08-2008 03:01>>> не в координатах аргумента, а в координатах экрана
>>> Можно пример рисунка с этими "характерными загибами"
Вот пусть к примеру у нас на предыдущем пикселе экрана значение функции (гипербола) равно -1, а на следующем шаге - 1. Мы не увидим "загиба" в области нуля. Для этого требуется, чтобы график функции строился так, что 2 реальных координат соответствует 1 пикселу экрана. То есть для разрешения 640*480 это равно 1280, или от -640 до +640. Или больше: от -1000 до 1000. Но я могу подобрать функцию, которая (при желании) будет так себя вести на отрезке -1...+1. Например, 1000/х. Короче, повторю второй раз: автором проблема поднята, но не решена. Лично мне метод Антона Григорьева показался очень хорошим, для решения подобных задач подходящим, пока правда на практике такой подход я не проверил, а как известно, практика - критерий истины. |
|
16-08-2008 22:27Смысл статьи, как я понял, - что надо задавать шаг не в координатах аргумента, а в координатах экрана. Но это, в общем-то, общеизвестно, так строят не только маститые математики (http://graphinpas.narod.ru/ или Адаменко А.Н. "Паскаль на примерах..."), но и школьники (http://amar-runyak.ucoz.ru/publ/3-1-0-16). Если мысль материала попробовать четко и логически изложить с примерами решения, не углубляясь в "теоретические" исследования, используя при этом общепринятую терминологию, и переместить из свитков в раздел для новичков, материал был бы полезен.
Для Антона Григорьева:
А я в свое время численно подбирал шаг по х таким, чтобы длина отрезка от предыдущей к текущей точке (именно отрезка, а не его проекции на ось х, который и будет шагом) была приблизительно одинакова (обычно 3-4 экранные точки). Такой способ: а) позволял строить плавные линии (без изломов) на участках, где функция резко возрастала или убывала; б) позволял корректно изображать линии разрыва, когда функция уходила на + или - бесконечность; б) помогал обнаруживать линии разрыва, где функция скачкообразно меняла значение. |
|
16-08-2008 04:48сообщение от автора материала Чтобы детально рассмотреть функцию, естественно необходимо уменьшать интервал.
А такие функции как sin(1/x) возле нуля имеют бесконечную частоту.
Поэтому там посмотреть ее невозможно. А вблизи нуля на интервале
1Е-13-1,00000000001E-13 она смотрится нормально. Ближе уже не подойти не позволяет как я понял модуль Math.(Разным х но близким дает одно и тоже значение функции,вероятно это связано с типом Extended). Так что здесь похоже предел . 1-10 Терагерц-это все что может стандартный модуль(и скорее всего тип
Extended). |
|
16-08-2008 03:33>>> То есть если взять график гиперболы на большом промежутке, то характерные загибы в области нуля мы не увидим.
Можно пример рисунка с этими "характерными загибами", если это не сложно? Мне просто интересно, почему их нельзя увидить просто выставив правильным массштаб. |
|
16-08-2008 01:24Я в своё время менял DX в зависимости от наклона функции на предыдущем шаге - чем больше наклон, тем меньше шаг, чтобы длина отрезка функции оставалась примерно постоянной. Понадобилось ввести ограничение на минимальный шаг, чтобы программа не уходила в глубокую задумчивость на некоторых видах функций. Функции типа гиперболы строились в итоге очень хорошо, даже с их разрывами научился бороться - если одна точка очередного отрезка оказывалась существенно выше верхней границы прямоугольника вывода, а другая - существенно ниже, отрезок не выводился. В большинстве случаев это давало неплохие результаты. Но, конечно, функции типа sin(1/x) выглядели с некоторыми деффектами. |
|
16-08-2008 00:54>>> Я как-то в студенческие годы
Это все замечательно, но решением не является. Увы :-( Мелкие детали построения функций теряются. То есть если взять график гиперболы на большом промежутке, то характерные загибы в области нуля мы не увидим. Кстати, проблему автор поднял, но так и не решил. Хотелось бы узнать, как он предлагает бороться с приведенных эффектом. Я тоже работал в студенческие годы с преобразованием координат, но именно из-за потери "мелких" деталей графика отказался от него. Кстати, я рассчитывал Dx в зависимости от ширины графика - то есть (Правый_предел-Левый_предел)/Ширину_экрана. Иногда делил это число на 2, чтобы получать более "гладкие" графики |
|
15-08-2008 11:58Я как-то в студенческие годы обходился без применения шага рисования dx, а пользовался обычным преобразованием координат.
Т.е. ядром были всего четыре функции:
function XToLeft(X: Double): Integer;
function YToTop(Y: Double): Integer;
function LeftToX(Left: Integer): Double;
function TopToY(Top: Integer): Double;
В данном случае (Left, Top) – это экранные координаты, а (X, Y) координаты в прямоугольной системе координат. К слову сказать, другая система координат не обязана быть прямоугольной.
Теперь, в чем суть построения функции function f(X: Double): Double.
Пусть дана прямоугольная область на экране, скажем, размера 640x480. Используя функции преобразования координат процесс построения графика можно описать таким образом:
for Left:= 0 to 640 do
begin
Top:= YToTop(F(LeftToX(Left)));
Paint(Left, Top);
end;
При таком подходе количество шагов цикла никогда не будет превышать ширину рисуемой области (в данном случае это 640 точек).
Ну и сама реализацию этих функций:
function XToLeft(X : Extended): Integer;
begin
Result := Trunc(Center_X + X * ScaleOfX);
end;
function YToTop(Y : Extended): Integer;
begin
Result := Trunc(Center_Y - Y * ScaleOfY);
end;
function LeftToX(X : Integer): Extended;
begin
Result := (X – Center_X) / ScaleOfX;
end;
function TopToY(Y : Integer): Extended;
begin
Result := (Center_Y - Y) / ScaleOfY;
end;
Здесь (Center_X, Center_Y) – центр прямоугольной системы координат в экранных координатах, и ScaleOfX, ScaleOfY – масштабы по осям X и Y соответственно. Таким образом, варируя эти параметры, можно смещать центр координат в любую сторону и растягивать график в направлении любой из оси или увеличивать или уменьшать его.
|
|
15-08-2008 03:52Я так понял, к статье должен быть пример?
Текст был прислан нам автором именно в таком виде, без примера. |
|
15-08-2008 03:34Тема интересная. Теория имхо, изложена правильно. Сам делал нечто подобное. Но хотелось бы посмотреть решение автора, а с этим проблемка.... Я так понял, к статье должен быть пример?
|
|
|
|