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

Самый простой способ — просто разбить вычисления на количество шагов (расстояние / радиус).
Способ быстрый — взять вектор движения каждого угла прямоугольника. Далее — проверить пересечения векторов движения и линий неподвижного прямоугольника. В случае с кругом — взять вектор движения центра круга, получить от него два равноудаленных (на расстояние радиуса) вектора с одинаковой длиной. Затем от неподвижного круга получить отрезок-диаметр круга, направленный перпендикулярно вектору движения первого круга. После точно так же проверяются пересечения линий (только уже не восьми, а трех).
Извиняюсь, если где-то чего-то неправильно написал (и буду рад, если меня поправят), но мне почему-то кажется это именно так :-)

Лэйауты в Java действительно оставляют желать лучшего — но первый блин, как говорится, всегда комом.
Впрочем, привыкнув, можно интерфейс любой сложности сделать на 2х-3х типах лэйаутов.

Для привередливых есть MiG Layout

Правильно. Я занимаюсь тематикой недвижимости очень давно, и идея с игрой на основе недвижимости проскакивала еще когда вышел замечательный, но не получивший поддержки, тандем Google + Monopoly. Цены будут если выбираться реальные, то они будут не соответствовать спросу в игре. Для рынка квартир норма вложения на несколько лет вперед, а учитывая просадку рынка, то «выстрел» будет может лет за 5 (хотя будем ждать колебаний доллара). Намного интереснее было бы рассмотреть симулятор биржи (если такового еще не существует), только с реальными данными, но простите, врядли такие возможности будут по сбору. А вообще я давно жду Transport Tycoon Deluxe на вебе и в многопользовательском режиме… :)

С познавательной точки зрения подход, определённо, интересный, но на практике есть более быстрый и надёжный алгоритм. Считается количество пересечений горизонтального луча из точки с рёбрами полигона. Чётное число пересечений — точка снаружи, нечётное — внутри. Этот алгоритм более быстрый, т.к. для определения факта пересечения луча и отрезка не требуется считать тангенсы, и даже можно обойтись без деления. А более надёжный, т.к. факт пересечения можно определить с абсолютной точностью (т.е. нет погрешности, этого >eps).

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

если вкратце то никто не знает как выглядит пространство на расстояниях меньше планковской длины, по крайней мере ясно, что понятные нам частицы и волны там существовать не могут, иначе их энергия должна быть запредельной поэтому теория струн предлагает поместить туда дополнительные измерения, по сути это лишь формулы описывающие как могло бы пространство вести себя там, посмотреть как это выглядит пока нельзя.
а вообще популярно и хорошо на эту тему пишет Брайан Грин в книгах «Элегантная Вселенная. Суперструны, скрытые размерности и поиски окончательной теории» и «Ткань космоса. Пространство, время и текстура реальности»

просто прочитайте CLR via C# Рихтера и всё

книга какая то совсем детская, советую " Visual С# 2008 Базовый курс Карли Уотсон "
весьма неплоха написана :)

А я обычно делаю как создатель Maemo в свое время. Запускаю в консоли $ pwgen -A0 5 и долго читаю :)

Кому интересно — Таненбаум, «Распределённые системы» — отличная книга по теме. Базовые вещи описаны очень хорошо. Есть на русском языке.

Sony Bloggie CM5 — для повседневных съемок.
VHoldR Contour HD 1080p — для экстремальных съемок.

Записал как способ обфусцирования javascript.

Какой-то чувак неэфективный способ предлагает. Я слышал о другом.
Молодой (М) HR пришел работать к опытному (О). На столе пачка из 500 резюме.
М: О нет! На рассмотрение такого количества резюме нужно минимум 3 дня, а у нас только день.
Опытный берет две третьих пачки и выкидывает в мусорку.
М:?????
О: Не люблю неудачников…

Насколько я знаю, в MyISAM таблицах есть специальное поле, где хранится число записей, поэтому в любой момент времени мы знаем, сколько там данных, не выполняя запрос. Кроме того, в MyISAM быстро отрабатывает запрос SELECT COUNT(*).
В InnoDb количество записей оценивается на основе реальных данных в таблице. А кол-во рядов (в том же phpmyadmin, например) это приблизительные данные. И не забывайте про транзакции.
Кстати, SELECT COUNT(*) там будет работать медленно, поэтому нужно ставить WHERE и желательно по индексированному полю.

У нормальных провайдеров есть такая штука как «сравнение по маске». Т.е. пароль клиента, конечно, хранится в Radius-сервере нехешированным, максимум там — обратимое шифрование (привет безопасная аутентификация CHAP), но он никому не отображается, даже сотрудникам техподдержи. Последние видят только чушь типа BBBsBBddd, т.е. «три больших, маленькая, две больших, три цифры». Это и есть маска, по ней и сравнивают пароль по телефону.

От путаниц 0-O, I-l-1 спасает железно.

Если такой подход не помогает — меняют пароль, что поделаешь.

Если текст в UTF-8 (или в других вариациях Unicode), то диапазон «а-яА-Я» не захватит буквы «Ё» и «ё»
Unicode Cyrillic Charts[http://www.unicode.org/charts/PDF/U0400.pdf]