- В этой теме 47 ответов, 10 участников, последнее обновление 17 лет, 1 месяц назад сделано
.
-
Сообщения
-
Еще идеи по сжатию — перед RLE применить MTF преобразование (продвинутое, основанное на предсказании очередного исхода по предыдущим), а после — статичный Арифметик (правда он не очень быстр)
Еще идеи по сжатию — перед RLE применить MTF преобразование (продвинутое, основанное на предсказании очередного исхода по предыдущим), а после — статичный Арифметик (правда он не очень быстр)
Главное скорость разжатия. Время сжатия будет все равно существенно меньше времени генерации базы.
Еще идеи по сжатию — перед RLE применить MTF преобразование (продвинутое, основанное на предсказании очередного исхода по предыдущим), а после — статичный Арифметик (правда он не очень быстр)
Главное скорость разжатия. Время сжатия будет все равно существенно меньше времени генерации базы.
Я конечно это понимаю
Арифметик не очень быстр при расжатии (то есть какое-то замедление он даст, и замедлит сильнее чем MTF преобразование — которое практически бесплатно по времени)После RLE он очень сильно улучшает сжатие…
Но чтоб сказать точно — достаточно привести статистику по разной длине повторяющихся последовательностей — по ней легко считается на сколько сожмет статичный арифметик (по Формуле Шеннона)
Если вероятности разной длины последоветельности отличаются сильно — то Арифметик даст весьма много.
По статьям который я прочитал выходит что Энтропийные методы на выходе RLE являются стандартом «де факто»Почитал дискуссию о сжатии данных…
NS, мы с вам одной задачей занимаемся, поэтому хочу из своего опыта посоветовать вам не тратить время на то как выжать еще лишний мегабайт, а луче подумать, как можно преобразовать сами данные под сжатие: что-то удалить, где-то перегруппировать… для творчества простор!А почему у тебя один бит на позицию в безранговых? Вроде два должно быть.
Но чтоб сказать точно…
Чтоб сказать точно — нужно сгенерить 7-ку и 8-ку, сжать и посмотреть что получится. Доступ к несжатой шестерке практически мгновенный, наверное в сотню раз быстрее чем вызов приличной оценочной функции. Если доступ к сжатой семерке будет производиться очень медленно то использование ее в расчете становится практически бессмысленным. Имхо сжатая семерка должна помещаться в 300-500 мегов памяти и иметь при этом скорость доступа хотя бы в сотню тысяч позиций в секунду.
Почитал дискуссию о сжатии данных…
NS, мы с вам одной задачей занимаемся, поэтому хочу из своего опыта посоветовать вам не тратить время на то как выжать еще лишний мегабайт, а луче подумать, как можно преобразовать сами данные под сжатие: что-то удалить, где-то перегруппировать… для творчества простор!А почему у тебя один бит на позицию в безранговых? Вроде два должно быть.
Преобразование данных под сжатие — хорошо описано в статье о ЭБ в Чинуке.
//
На самом деле 5 позиций в байте для ЭБ на три результата (с удаленными позциями с возможным взятием), и 8 позиций в байте для классов ЭБ на два результата (Два результата после удаления позиций с возможным взятием)На хороших алгоритмах сжатия выигрывается не мегабайт, а сжимается в разы!
У Чинука хранится от 20 до 80 и больше позиций в Байте (и это практически полные ЭБ, исключены только некоторые классы позиций), при Этом их Сжатые ЭБ еще вдобавок сжимаются RAR-ом в пару раз.
100 000 доступов в секунду скорей всего достижимо (скорей всего можно получить бОльшую скорость доступа к сжатым ЭБ в памяти), но нужно проводить тесты.Но чтоб сказать точно…
Чтоб сказать точно — нужно сгенерить 7-ку и 8-ку, сжать и посмотреть что получится. Доступ к несжатой шестерке практически мгновенный, наверное в сотню раз быстрее чем вызов приличной оценочной функции. Если доступ к сжатой семерке будет производиться очень медленно то использование ее в расчете становится практически бессмысленным. Имхо сжатая семерка должна помещаться в 300-500 мегов памяти и иметь при этом скорость доступа хотя бы в сотню тысяч позиций в секунду.
Сжатая семерка влезет в такие объемы даже при использовании простого RLE
Можно спросить у Коршунова (если он посчитал семерку), сколько с его алгоритмом сжатия она занимает места.Преобразование данных под сжатие — хорошо описано в статье о ЭБ в Чинуке.
А можешь дать ссылку на статью?
http://www.cs.ualberta.ca/~chinook/
http://www.cs.ualberta.ca/~jonathan/Papers/Papers/databases.psНо статья достаточно старая.
Вот, решил подкинуть данные.
Не слишком у многих есть 10-ка Тундры, но те, кто имеет — могут видеть такую картину:
ЭБ5(+4+…) — 2МБ,
ЭБ6 — 29МБ,
ЭБ7 — 328МБ,
ЭБ8 — эээ… ну, можно посчитать кому интересно.
То, что после дроби — это «полная» версия сжатой базы; то, что до дроби — это то, что используется (по дефолту).
Я думаю стоит выложить результаты сюда.
Можно сделать вывод, что играя против слабого соперника, у которого нет ЭБ, ЭБ не нужны. А возможно даже и вредны, т.к. программа начинает видеть ничьи там, где их не видит соперник.
Любопытно, как будет играть программа обладающая 24-х фигурной базой. 😯
Если не придумывать никаких новых алгоритмов, то будет играть как попало.
И вряд ли будет способна выигрывать. Разве что у самых слабых.Напоролся на теже грабли — программа не выигрывает у слабых движков. (перестала выигрывать).
Только похоже виновата в этом не ЭБ, а случайное перемешивание ходов в корне. Ход из Хеша надо наверх вытягивать…Если программа досчиталась до ничьи по ЭБ, то ход из Хеша — это ход который давал перевес при меньшей глубине обдумывания.
проверил, версия 0.06 теперь устраивает погром KestoG1.2 и KestoG1.3
Правда кроме продвижения хода из Хеша вперед в корне я еще исправил несколько ошибок внесенных ночью.ЗЫ. Нельзя по ночам программы писать
ЗЫЗЫ. Запустил матч с Каллисто 3.23, надеюсь что исправленная версия не проиграет этот матч.
ЗЫЗЫЗЫ — все предыдущие матчи давали искаженный результат, так как оказалось что на Двух Гигах памяти в матче с Каллисто2 с ЭБ6 начинался своп, причем у Каллисто2 всё нормально, а у Scfi — падение NPS в десятки раз когда в переборе встречается много позиций из ЭБ.
В итоге — зевки.
- Для ответа в этой теме необходимо авторизоваться.