Круг на плоскости

[evg_m]

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

m:=0;
for x:=-R to R do 
for y:=_R to R do
  if x*X+y*y <=R*R then inc(m);

[Serge_Bliznykov]

evg_m, Вы неправы.
напоминаю условия задачи:

На вход программе подаются 3 вещественных числа 0<=r<=1000000, x и y.

Что Ваш код выдаст для, например, r=7.75 x=0.345 y=6.778 (цифры взяты с потолка, я даже не рисовал круг и не знаю, сколько точек реально попадёт в круг....

как вариант, предложенный JUDAS вообще относится к решению данной задачи - я вообще не понимаю... При чём здесь углы? я уже не говорю про round() - это же найдёт целые точки близкие к окружности, но отнюдь не факт, что лежащие внутри (если снаружи и близко, то тоже посчитается). А внутренние точки как определять?

ну и последнее.
JuniorProger (пост #6) и puporev (пост #7) предложили, имхо, нормальный вариант с перебором по одной оси (количество точек по другой оси будет вычислять по формуле n:=n+(right_border-left_border+1);
Возможно, этот вариант потребует небольших доработок.
Но мне кажется это нормальное, правильное и быстрое решение задачи.

[TinMan]

Сообщение от Serge_Bliznykov

JuniorProger (пост #6) и puporev (пост #7) предложили, имхо, нормальный вариант с перебором по одной оси (количество точек по другой оси будет вычислять по формуле n:=n+(right_border-left_border+1);
Возможно, этот вариант потребует небольших доработок.
Но мне кажется это нормальное, правильное и быстрое решение задачи.

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

Влияния знака можно избежать, если сдвинуть систему координат на целое число так, чтобы круг находился полностью в положительной области (по x и y). Тогда решение JuniorProger с поправками puporev годится. Либо можно учитывать знак явно при вычислениях границ.

[JUDAS]

спасибо Stilet !
кстате у меня там ошибка цикл дол 360 ноль пропустил.

вообще относится к решению данной задачи - я вообще не понимаю

не понимаете, полистайте учебник по математике.
Как относится - просто я указал как найти все точки на круге !

[puporev]

Какой бы вариант перебора не был принят, все равно при R=1000000 это либо будет работать очень долго, либо вообще не будет. Вероятно есть способ решения, связанный с какими-то математическими закономерностями.

[evg_m]

evg_m, Вы неправы.
напоминаю условия задачи:
Цитата:
На вход программе подаются 3 вещественных числа 0<=r<=1000000, x и y.

ну в таком случае

Rint:=tranc(R)+1; // чуть-чуть больше чем круг
R2:=tranc(R*R); // чтобы много раз не считать
for x:=-Rint to Rint do
for y:=-Rint to Rint do 
  if x*x + y*y <=R2 then inc(m);

хотя да надо еще будет учесть отклонение центра от целочисленной координаты. будем думать.
т. е. будет что-то вроде

 if (x-dx)*(x-dx) +(y-dy)*(y-dy)<=R2

где dx, dy искомые отклонения от целочисленных. (и они 0<=dx<1)
ну и еще добавить по 1

Rint=trunc(R)+2

чтобы квадрат заведомо накрыл круг.

P.S. то же в пост #3. с мелкими несущественными нюансами.

[JuniorProger]

Сообщение от Stilet

Из учебников математики. http://ru.wikipedia.org/wiki/%D0%9E%...81%D1%82%D1%8C

Ну во-первых, нужно было сказать, как далее указал сам JUDAS, что в данном решении ошибка!!!

кстате у меня там ошибка цикл дол 360 ноль пропустил

Сообщение от Stilet

Цитата:
Какой параметр показывает количество точек?
Счетчик цикла.

Во-вторых, счетчик цикла дойдёт (с учетом исправленной ошибки) до 360. Т.е. по-вашему в любой окружности 360 точек?
По-моему, это, мягко говоря, ерунда!

[JuniorProger]

Сообщение от Serge_Bliznykov

ну и последнее.
JuniorProger (пост #6) и puporev (пост #7) предложили, имхо, нормальный вариант с перебором по одной оси (количество точек по другой оси будет вычислять по формуле n:=n+(right_border-left_border+1);
Возможно, этот вариант потребует небольших доработок.
Но мне кажется это нормальное, правильное и быстрое решение задачи.

Я тоже так считаю

[evg_m]

Во-вторых, счетчик цикла дойдёт (с учетом исправленной ошибки) до 360. Т.е. по-вашему в любой окружности 360 точек?

Нет, все целые точки лежат на лучах с углами в целые градусы (0-360). а могут и не лежать

[JuniorProger]

Сообщение от TinMan

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

Влияния знака можно избежать, если сдвинуть систему координат на целое число так, чтобы круг находился полностью в положительной области (по x и y). Тогда решение JuniorProger с поправками puporev годится. Либо можно учитывать знак явно при вычислениях границ.

Функция trunc не зависит от знака! Сам проверял: она берет целую часть от модуля числа, потом добавляет знак, если был таковой. Поэтому не важно, какое число (положительное или отрицательное), trunc всегда возьмет только целую часть!

И еще хотел добавить, что я учел, что границы могут быть либо:
1. обе положительные;
2. одна положительная другая отрицательная;
3. обе отрицательные.

Нужно всего лишь повнимательнее посмотреть на решение и подумать над ним
Поправки не нужны