Проверил. Формула (3) верна!
mustitz, конечно, эта формула не будет постоянно использоваться при работе с базой. Пожалуй это больше нужно для предварительной оценки размера базы.
Ну ладно, пусть мы ничего не считаем. А просто строим базу и заносим в таблицу смещения (
lookup - это же смещения, я верно понял?). Уже для двух фигур у вас в
lookup-таблице 28 элементов ... Но как будет выглядеть эта таблица, когда доберемся до 6-фигурной базы? Она станет трехмерной? Какого она будет размера? Мне кажется, что она будет огромной, и представлять, по-сути, посчитанные значения для огромного количества вариантов. Хотя, может, я и ошибаюсь...
Формула (3) - она ведь оценивает размер всей
фигурной базы, для всех возможных сочетаний материала. Если нам известно сколько каких фигур, то эта формула упрощается. Например, так:
где
- количество белых простых на первой горизонтали;
- количество белых простых на 2-7 горизонталях;
- количество черных простых;
- количество белых дамок;
- количество черных дамок;
Вот у меня пока и мысли о том, чтобы сгенерить кучу файлов вида
ed_{}{}{}{}{}.
Например, файл
ed_12121 - кусок из 7-ми фигурной базы окончаний -
3 простые (1 на первой горизонтали) плюс 2 дамки белых vs 1 простая плюс 1 дамка черных.
Размер этих кусочков будет определяться по формуле (4). Внутренняя адресация организуется по указанному
mustitz принципу. При работе в память подгружаем только требуемые файлы базы.
Число таких файликов, для описания всех конфигураций
ных баз будет равно:
Код:
n Files
2 6
3 21
4 50
5 99
6 173
7 277
8 416
Вполне приемлемо ведь
(ожидал, гораздо больше).
Это решает все проблемы с расчетом индекса позиции в базе и в базе не держим никаких накладывающихся позиций, ничего лишнего!
Эх, если б не праздники, занялся бы кодингом сейчас вплотную.