6-7-фигурный эндшпильный генератор. 2-я версия

О технические детали ничего не могу сказать! Никакое представление о програмирование не имею (исключая аматьорские опиты в прошлом на BASIC :ermm: )

Примерно так представляю...

Позиция 1 [база для белых- krpp~krp]
1. Ra1 [Rb1 = draw; Rc1 = draw; Rd1 = draw, ... - т.е. без записания вариантов, а только указание, что после этих ходов - ничья]
1. ... Rh8, Rg8, Rf8, Re8... [Ra7 = draw; Ka6 = draw; b5 = draw, ...]

Позиция 2 после ходов 1. Ra1 Rh8
2. Ra2 [Ra3 = draw; Ra4 = draw; Ra5 = draw, ...]...
2.... Rh7 [Rh6= draw, Rh5 = draw]

—-
зам.1 - можно очень быстро проверить на одной 4-ти фигурной базе (kr~kn), что в конце концов получаеться.

зам.2 - (бред продолжаеться! ) даже, если подумать, в некоторые базы, в зависимости от наших емпирических знаний, можно записывать ничьи (так как они меньше как количества, чем выигрыши), или переработать структуру записей - типа true/false.

зам.3 - извините, но уж больно скачать базы (несколько месяцов трачу время на это, диск запольняеться и т.д., а для 7-ми фигурные говорите о годы работы и байти/диски как атомов во Вселеной) - нужно искать какое-то более рациональное разрешение. И вот сегодня начал писать!

зам.4 если что-то мое существо вообще не можеть понять и противиться - почему базы для белых и базы для черных. В принципе они должны быть зеркальные. Воображаю, что маленкая программа можеть успешно чередовать одну базу как за белых, так и за черных (180 градусов перевернутых позициях) Не говоря о том, решение с позиции силы - если база одна (для белых и черных), сами составители движков, чтобы эту базу пользовали, будут строить свой движок с этой дадености. А возможно я невообразимо тупый! :|

зам.5 - на некоторое время буду рассуждать (бредить) и беседовать сам с собой по теме! :|

В качестве мозгового штурма:

Можно, например, так:
1. Некий заголовок, который хранит параметры
2. Установить порядок фигур, например KkQqPP (порядок в параметрах)
3. Файл начинается их таблицы из 64 чисел—-положение белого короля. Каждое число в таблице это смещение следующей таблицы. Для каждой фигуры может использоваться некий множитель для выравнивания (например, 4096). В параметры размер и множитель
4. Потом идет таблица из 64 чисел—-положение черного короля и т. п.
5. На последнем уровне вместо таблицы пара чисел: число ходов до мата. Может даже в таком формате:
0x00 ничья
0x80 позиция неверная
0x9x оценка представлена двумя байтами: у первого надо взять четыре бита, у второго все восемь
Старший бит показывает, кто матует.

Самый развернутый, самый быстрый, но самый большой.

На предпоследнем уровне можно в таблицу помещать не все 64 клетки, а меньше

зам. 6 - опять извините за логорею, но революционное время для шахмат эти месецы, вот и не сдержалься!

Ну вот вы посчитайте количество позиций, количество байт сколько нужно на хранение результата ОДНОЙ позиции - и перемножив эти числа получите - число на сколько байт потянет ваша база. Потом сравните с размером моей базы.

Например. Число позиций в 4-х фигурном KQ-KR 64*63*62*61 разделить на 8 (отбросим повороты доски и зеркальные отражения) и умножить на 2 т.к. одна и та же позиция с ходом белых и с ходом черных - это по сути 2 разные поциции и нужно обе их хранить, например с ходом белых там выигрыш в 22 хода а с ходом черных - в 35 ходов.

== итого число позиций которые нужно хранить равно около 4 000 000.
Т.е. 4 миллиона. ВСЯ база KQ-KR и с ходами белых и с ходами черных у меня занимает примерно 1,4 миллиона байт. Без выбрасывания ничейных и т.п. Значит в среднем в каждом ОДНОМ байте у меня хранится информация о 3-х позициях.

А там может быть и выигрыш в 235 ходов и проигрыш в 100 ходов. (конкретно в KQ-KR такого нет, но в других есть и они примерно такую же плотность записи имеют). Вот когда поймете почему так может получаться, тогда и можно будет что-то объяснять. Если люди не знают азов темы, то нет смысла что-то объяснять. Может кто-нибудь не знает даже что такое байт.

Чтобы было понятнее - позиции из младших эндшпилей в старшей базе не хранятся. Ничейные позиции и информацию о них удалить из базы или не записывать НЕВОЗМОЖНО. Чтобы это стало возможно - нам нужно будет хранить дополнительную информацию в базе, и от этого база будет занимать не меньше а В ДЕСЯТКИ РАЗ больший размер.

Skipper_NORTON

Все же решился ответить!

Считать байты/позиции не буду! По опять постараюсь поразсуждать вслух! :devil:

І. (имхо) Концепция.

Концепция о создании эндшпилных баз, на которой они реализованны, безнадеждно отстала. Она была создана давно, при других хардуерных и софтуерных особеностях. И идет по колеи, которые нужно изменить.

Не смейтесь! Уже столько перемен концепциий, фундаментов и укоренившиесся представлений пережил в своей жизни, так что если что-то моложе 100 (как минимум) лет, не считаю возможным величать как верное!

(имхо) – если вижу какую-то слабость у вашей теории/практики, то это, что база должна подчиняться требованиям оболочки/движка, а я думаю что наоборот!

ІІ. (имхо) целое больше своей части, часть меньше целого (это доказано и доказуемое).

если a=b+c (где b и c положительные числа, больше нуля),

то тогда a>b, a>c, а также верно и то, что b<a и c<a,
где:
a - все 7-ми фигурные позиции
b - выигрышные 7-ми фигурные позиции
c - ничейные 7-ми фигурные позиции.

ІІІ. (имхо) Решение a=b+c (numerus clausus; tertium non datur)

Если создать только базу b, то мы получаем косвенным путем также все решения по базу c, таким способом получам косвенным способом и вся база a.

Тут приложими тысячелетные принципи:
numerus clausus по всех баз a,b,c - конечное число возможностей/позиции, которые можно просчитать (в нашем случае базы b и c) и записать только базу b.
и
tertium non datur (третьего не дано) – т.е. каждая одна позиция или выигрышная или ничейная (третьего не дано)

Если одна позиция находиться в базу b, то она не можеть находиться (исключено) в базу c, верно также и то, что если одна позиция находиться в базу c, то она не можеть (исключено) находиться в базу b.

(допольнительный вывод) – лучше в движках/оболочках создать несколько функций для этого относительно елементарное обращение к базам, чем создавать огромное количество баз в огромных размеров! Наличие таких баз и ползы от их использование заставить авторов движков/оболочках сделать это!

(имхо) несколько экстравагантно – возможно в некоторые базы, где количество ничей (значительно!?) больше, то можно(ли?)/нужно сохранять для исползования базу с (ничейные позиции), соответствено указывая это в придружающем файле.

ІV. (имхо) Нужно ли сохранять информацию во сколько ходов позиция выигрышная!?
Инфомация полезная, но результать важнее. Если необходимо хранить такую информация без утежнения базу, возможно.

V. (имхо) Использование базу b от оболочки/движка.

Когда получиться позиция, где известно, что наличны базы, то оболочка/движок обращаеться к ним. Тут нужно создать служебный файл, в котором указываються брой всех файлов (примерно 20), в которых выигрышные позиции при конкретное соотношение материала (примерно kq~kr), чтобы избежать неверные результаты поиска. Т.е. если у потребителя нет всех наличных баз, то движок/оболочка должна на это среагировать (здесь могу также поразсуждатя, но не хочу отклонятся от темы)

При обращение к базу оболочка/движок устанавливаеть наличие данной позиции (т.е. true) или ее отсуствия (т.е. false) и на этом основание делаеть ход – для достижения выигрыша делает ход из базу b, для достижения ничей/избежания поражения каждый возможный ход, который не находиться в базу b (т.е. из возможных, скажем 30 ходов в позицию, 12 находяться в базу b – т.е. выигрывающие/проигрывающие, остальные 18 приводять к ничей)

VІ. (имхо) базу b возможно создать только в один вариант (т.е. совместную для белых и для черных)

При наступление события обращения к базу, на основе наличного материала, каждая сторона начинаеть пользовать те ходы, которые соотноситься к ее наличным материалом. Так как база 7-ми фигурная, здесь нет возможности одинаковое соотношения сил у стороны. Конечно, при одинаковый материал (уже говорю о 6-ти или 8-ми фигурные бази) то решение при обращение к базу также возможно.

VІІ. (имхо) некоторые выводи.

Признаюсь, что практически и теоретически ничего не соображаю от програмирование, хотя пользую компютер с 1989 года, но (имхо) некоторой логике в моих разсуждениях есть.

VІІІ. (имхо) Генеральный вывод.

Кто делаеть что-то (в данном случае Вы) имеет как минимум следующие возможности :
(1) делать всего сам,
(2) спрашивать/консультироваться у специалистов (в данном случае – те, которые также работають по эндшпильные базы, другие програмисты),
(3) спрашивать для мнения и посторонных неспециалистов (в данном случае - меня :| ),
и т.д.

И это следуеть из фундаментального универсального принципа – вопросы/проблеми обсуждаються сообща, решения принимаються единолично – т.е. Вы должны принять решения как это сделать – на основе Ваших знаний и информации, собранную при обсуждения от посторонных (в том числе неспециалистов)


зам. - (имхо) знаю разницу между bite и byte.

цитирую: `например с ходом белых там выигрыш в 22 хода а с ходом черных - в 35 ходов`

Не успел понять почему одинаковые позиции решаються различным способом (т.е. различное количество ходов на решение) при белых и черных.

Поставил первую попавшую в голову позицию – и результаты одинаковые. Буду признателен, если дадите пример, где решения различаються для белых и черных.



1.g5 (#24x)


1....g4 (#24x)

——


1.Kf3; 1.Rc3 (#33x)


1...Kf6; 1...Rc6 (#33x)

Вот этого не знал!

Но! задачу нужно решать! :|

Вот сейчась дошло до ума, что (3-4-5) базы у Фрица и Шредера значительно меньше, чем Налимовских. Это за счет сжатия, или какое-то концептуальное колдовство!?
—-

зам. жаль! Целый час бодал свою концепцию , но все же стырать ее не буду! Пусть програмисты смеються!

WildCat, Skipper_NORTON

С этого момента в этой теме буду читатель, а не писатель!

Верно. Хранятся не позиции, вообще говоря, а ОЦЕНКИ позиций. Но в принципе когда говорят что мы "храним все позиции" - можно и подразумевать что хранятся именно оценки. Если кто-то думает что там храняться именно описалова самих позиций - т.е. где какая фигура стоит - то он заблуждается очень глубоко.

Чтобы хранить все оценки, а не хранить описалова позиций, нам нужно знать в каком месте на винчестере хранится оценка любой позиции. Поэтому мы проводим преобразование позиции в число по какому-то принципу. Вот это число и будет означать номер оценки от начала базы. Так как мы заранее не знаем какие позиции станут ничейными - мы не сможем найти закон преобразования позиции в число, если выбросим ничейные! Т.е. мы не знаем изначально что именно нужно выбрасывать! В принципе после построения базы уже можно узнать где находятся ничейные, но все равно изобрести такой закон преобразования в число, в котором не было бы ничейных — практически невозможно.

17.

Позиции которые вы привели, поверьте, хранятся В ОДНОМ экземпляре Или вы думаете что разработчики баз настолько глупые чтобы это хранить в 2-х экземплярах и иметь места для базы в 2 раза больше, чем можно было бы?

А вот возьмите позицию, скажем самую первую которую вы нарисовали. При ходе белых 1.g5 (#24x) - там выигрыш в 24 хода? А может В НЕЙ ЖЕ быть ход черных ? Может. И оценка будет другая. Вот для этого и нужны базы и с ходом белых и с ходом черных.

По таким базам программа вообще, возможно не выиграет имея выигрышную позицию! Т.к. она не будет знать лучший ход, и постоянно будет откатываться назад. Т.е. будет то приближаться то удаляться от мата. А налимовские базы (да и мои тоже) - содержат именно точные оценки, значит по ним программа всегда выиграет если это возможно и всегда будет играть САМЫМ СИЛЬНЫМ образом.

а кто генерировал 5-ку? автор скорпио? вот его и спросить, где

PP

Все очень просто. ЕСТЬ способы уменьшить размер базы, но при этом возрастет время обращения к ним. Оно нужно? Время обращения в оперативную память - еще не существенно, но время обращения к винчестеру - ОЧЕНЬ существенно.

попробовал стандартно tb_hnd = LoadLibrary((LPCWSTR)"d:/ChessDLL.dll");
и потом GetProcAddress функции - отрабатывает.
но при вызвове инициализации InitCHESS(); тут же возникает исключение.

bankuss

У вас проект на чем? Я пробовал сделать посторонее приложение на VS 2005, на C++ и вызывал функции из ChessDLL.dll - никаких исключений не было. Могу и по шагам расписать.

на Си
см.личку - я там написал кое-что

Все таки не укладываюсь в апрель. Я не говорю, когда у меня точно получится завершить все свои тесты, но примерный перерасчет показал что где-то, на 1-2 месяца позже, т.е. в мае, может и в июне. Тогда и закачаю в интернет, последнюю, наиболее оптимизированную версию генератора всех баз до 7-фигурки включительно. Далее, нужно будет считать, на многих компах и лет 10, наверное.

как новая версия?

>> как новая версия?
>>
Тесты скоро закончу (в июне), буду покупать новый домен, и тогда сделаю страничку с возможностью скачать. До сих пор в тестах все работало безупречно.

Эта тема уже давно устарела, и ее пора закрыть. Или удалить. Просьба к модераторам.
Самая "современная" - тема про 4-ю версию генератора. А то, будут люди искать информацию, наткнутся на эту тему, и будут читать то, чего уже нет и давно устарело. (генератора 1-й и 2-й версии уже не существует и приводимые ссылки здесь, уже не работают). Т.е. эта тема - приводит только в заблуждение. Потому что информация в ней, уже не соответствует действительности.

Закройте плиз. А лучше удалите. Мержить темы (соединять) тоже нет смысла - обычно люди обращают внимание на самые первые посты в теме, а того, что здесь написано - уже нету.

Оставьте только последнюю тему - про 4-ю версию генератора.