Обсуждение интерфейса для доступа к ЭБ

Главная Форумы Шашечные программы Программа Каллисто Обсуждение интерфейса для доступа к ЭБ

Просмотр 15 сообщений - с 16 по 30 (из 59 всего)
  • Автор
    Сообщения
  • #370556
    Kallisto
    Участник

    Какое это имеет значение? Все равно индекс тем или иным способом надо расчитывать. Единственно, что движок должен будет учесть, что скорость доступа к сжатой базе меньше. А узнать о сжатости базы он сможет из формата базы.

    #370557
    booot
    Участник

    32-битного индекса хватит на все 7-ми фигурные таблицы (и меньше). Начиная с 8-ми фигур количество позиций в классе переваливает за возможности 32-битного числа. Но проблему вижу не в этом. Сгенерить 8-ку, а так же вероятно 9-ку — дело не очень сложной техники, подкрепленной солидной вычислительной мощью современных компьютеров. А вот как ее потом использовать максимально эффективно? Грузить всю таблицу в память можно себе позволить для 6-фигурки. С определенными ограничениями — часть 7-ми фигурки. Но начиная с 8-ми нужно придумывать нечто иное. Какой-то менеджер памяти, который будет по ходу перебора оперативно подгружать в память различные куски различных таблиц, следить за частотой их использования и по каким-то правилам замещать ранее подгруженные куски таблиц новыми. Предлагаю обсуждение общего формата ЭБ начать именно с этого вопроса: предположим, что мы уже сгенрили 8-ку и 9-ку :-)

    #370558
    NS
    Участник

    предположим, что мы уже сгенрили 8-ку и 9-ку

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

    #370559
    Kallisto
    Участник

    booot, так ты займешься генерацией больших баз?

    Я так думаю, что 8-ка не влезет. Проблему можно решать кешированием и использованием доступа к базам, которых нет в памяти, только в узлах достаточно далеких от листьев.

    Можно поинтересоваться, как с этим справляются чекерсные программисты.

    А по интерфейсу замечания есть?

    #370560
    NS
    Участник

    У Чинука полная 8-ка несколько Гигов, но не факт что они хорошо сжали, и можно использовать неполные ЭБ.

    #370561
    Kallisto
    Участник

    У Чинука полная 8-ка несколько Гигов, но не факт что они хорошо сжали, и можно использовать неполные ЭБ.

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

    #370562
    NS
    Участник

    С потерей инфы по половине позиций, а если сжать с потерей инфы по 90% позиций? Что лучше — потерять в скорости доступа в 1000 раз, или сделать неполные ЭБ с десятипроцентным наполнением?
    Это не утверждение, это вопрос :)

    #370563
    Kvadrat
    Участник

    У Plus600 безранговая 8-ка = 3.77 Gb
    А почему вы не хотите рассмотреть такой класс как 4 на 4 простые? Большинство партий проходит через такое окончание. И в память, вероятно, оно влезет.

    #370564
    Kallisto
    Участник

    Что лучше — потерять в скорости доступа в 1000 раз, или сделать неполные ЭБ с десятипроцентным наполнением?

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

    Kvadrat, я не думаю, что 4х4 намного полезней, чем другие 8-фигурные.
    Важно не количество партий проходящих через какую-то конкретную таблицу, а способность этой таблицы настолько отличаться от ОФ, что это будет сказываться на результате партий.

    #370565
    Kallisto
    Участник

    На всякий случай приведу слова Мартина Фиерца, когда он генерил 7vs1 базу для поддавков (для крепков он посчитал такие базы излишними):

    and my code to compute the binomial coefficient of n and k (I hope that’s what it’s called in English; it’s = n!/(k!*(n-k)!) ) promptly overflowed past the size that a 32-bit integer can hold, and my database builder crashed when computing the 7-1-piece database

    #370566
    Kallisto
    Участник

    Все, буду делать реализацию вот этого интерфейса:


    struct EdBoard1
    {
    // все поля идут по порядку a8, c8, и т.д. до g1
    unsigned char board[32];
    };

    struct EdBoard2
    {
    unsigned char *wman;
    unsigned wman_cnt;

    unsigned char *wkings;
    unsigned wkings_cnt;

    unsigned char *bman;
    unsigned bman_cnt;

    unsigned char *bkings;
    unsigned bkings_cnt;
    };

    // интерфейсный класс для доступа к эндшпильным базам
    struct EdAccess
    {
    // возвращаемые значения

    const draw = 0;
    const win = 10000;
    const lose = -10000;
    const db_not_found = 32000;

    // коды для обозначений шашек

    const white = 1;
    const black = 2;
    const empty = 4;
    const king = 8;

    // флаги для доступа к базе

    const in_mem = 1;


    // загрузить базы
    // пока такие типы игр:
    // russian
    // russianlosers
    // brazil
    // brazillosers
    // pool
    // poollosers
    // checkers
    // checkerslosers

    unsigned Load(char *game_type) = 0;


    // получить тип базы

    char *GetBaseType() = 0;


    // оценка позиции (всегда ход белых)

    int GetResult(EdBoard1 *board, unsigned flags) = 0;
    int GetResult(EdBoard2 *board, unsigned flags) = 0;


    // получить указатель на таблицу по материалу

    unsigned GetTable(unsigned wm, unsigned wk, unsigned bm, unsigned bk) = 0;


    // получить указатель на таблицу по материалу и по наиболее продвинутой шашке

    unsigned GetTable(unsigned wm, unsigned wk, unsigned bm, unsigned bk, unsigned rank) = 0;


    // проверка загруженности таблицы целиком в память

    unsigned IsTableInMemory(unsigned table);


    // получить индекс в таблице

    unsigned __int64 GetIndex(EdBoard1 *board) = 0;
    unsigned __int64 GetIndex(EdBoard2 *board) = 0;


    // получить оценку по указателю на таблицу и индексу

    int GetResult(unsigned table, unsigned __int64 index, unsigned flags) = 0;


    };

    Если бы вы знали, сколько мне пришлось протратить усилий из-за того, что часто интерфейсы конфликтуют между собой, то не отнеслись бы к обсуждению столь индифферентно :)

    #370567
    NS
    Участник

    Игорь, если бы ты сразу сделал поддержку доступа только через массив — то никакого обсуждения бы и не потребовалось :)

    Можно было обойтись только одной функцией.

    Медленно, зато очень просто.

    #370568
    Kallisto
    Участник

    Медленно, зато очень просто.

    Вот это самая большая проблема интерфейсов — неуниверсальность.
    Кто-то обязательно был бы недоволен потерей скорости на ровном месте, хоть и копеечным. А так, я надеюсь, что любой будет удовлетворен.

    #370569
    Kallisto
    Участник

    Сделал библиотеку для доступа к базам Каллисто. Теперь осталось «самое простое» — встроить ее в оболочку и отладить.

    В качестве демонстрации работы с базами напишу код для SiDra.

    #370570
    Kallisto
    Участник

    Вот сделал доступ к базам:

    http://www.igorkorshunov.narod.ru/kallisto_ed.rar (примерно 226 килобайт).

    Интерфейс в фале EdAccess.h

    Примеры доступа в исходниках SiDra (ED.cpp). Правда сделал пока неэффективно. Она обращается к базе в каждом узле дерева.
    Скорость упала более чем в два раза :)
    Но не это пока главное.

    Для получения результата пока можно пользоваться только одной функцией:
    virtual int GetResult(EdBoard1 *board, unsigned flags) = 0;

    Для получения интерфейса к протоколу добавлена еще одна функция. В исходниках SiDra она самая нижняя.

    Попытайтесь подключиться!

Просмотр 15 сообщений - с 16 по 30 (из 59 всего)
  • Для ответа в этой теме необходимо авторизоваться.
141 запросов за 1,339 секунд.