Допустим ОФ выдает результат за 1 еденицу времени, а ТБ за 1024. Рассмотрим простой случай бинарного сада расходящихся тропок где счет обрывается на глубине 10. Вызов таблицы будет мне экономить время только если я смог заглянуть в нее уже на первом уровне. Теперь смотрим, что получится если только на глубине 10 я добрался до таблиц. В этом случае я получу замедление на три порядка....
Извините, это бредятина.
Вы получаете N узлов с числом фигур <= 6. N УЗЛОВ. Ферштееен?
При чем тут глубина расчета?
Для каждого узла вызывается ЛИБО ОФ с дальнейшим кустом, либо базы.
Вы мне хотите сказать. что дальнейшего куста может не быть.
Тогда верьте вобле в 5-фигурке выше. что оценка +2.95.
Не мои проблемы.
Беда значит. Не умеете получается умно паковать данные
Отнюдь, паковать умеем, и сами и сейчас даже SQL сервера сами умеют на лету паковать и распаковывать данные, в базе в сжатом формате все хранить для экономии места и скорости сканов, а мы пользоваться умеем. А вот кусочнотраспаковывать не умеем.
Красные узлы закончат не только эту линию, но и множество других, если там выиграно, или ничья при прочих плохих
Особенно актуалльно для крепостей.
Черные узлы могут, конечно остановиться, и будут посчитаны быстрее.
Но мы знаем, что даже для пятифигурок может быть и минут мало для правильной оценки
Очевидно потому, что длина ФВ ограничена, и точно в пресловутом конце N запросов будут на 3 порядка медленнее
Не будет она из за кэшей на 3 порядка дольше. Самое важное что оценка таблицы будет верной в отличие от расчетной. И наверх будет эскалирована верная оценка в результате чего например движок может увидеть теоретическую ничью с 0.0 и не пойти в эту ветку. А супербыстрый, но дурной расчет с фальшивыми оценками потащит прогу в западню. Такое может быть и более того регулярно бывало у меня лично по переписке когда соперник не пользовался таблицами и лез в ничейные позы, теряя перевес.
Красные узлы закончат не только эту линию, но и множество других,
А теперь нарисуйте картинку, когда красные узлы появились только на листьях, так как до этого в позиции было слишком много фигур. Красные узлы тогда нам ничего не сэкономили, а наоборот
Ну так никто не мешает НЕ использовать базы в этом случае
Можно, и наверняка ближе к концу ФВ используются достаточно ловкие приемы. Речь идет всего лишь о том, что базы могут при некоторых условиях замедлять расчет и в условиях ограниченного времени снижать силу движка. С этого вообще весь спор начался
Не будет она из за кэшей на 3 порядка дольше. Самое важное что оценка таблицы будет верной в отличие от расчетной. И наверх будет эскалирована верная оценка в результате чего например движок может увидеть теоретическую ничью с 0.0 и не пойти в эту ветку. А супербыстрый, но дурной расчет с фальшивыми оценками потащит прогу в западню. Такое может быть и более того регулярно бывало у меня лично по переписке когда соперник не пользовался таблицами и лез в ничейные позы, теряя перевес.
Во-первых, расчетная оценка ОФ не всегда будет искажать граф, даже скорее всего чаще не будет. А во-вторых, поэтому может быть полезнее посчитать дальше
А теперь нарисуйте картинку, когда красные узлы появились только на листьях, так как до этого в позиции было слишком много фигур. Красные узлы тогда нам ничего не сэкономили, а наоборот
Похоже, опять у Вас утро не задалось.
КАЖДЫЙ красный узел есть экономия времени. Вы сами признали
Для ЛЮБОГО отдельно взятого красного узла скорость меньше
Вот и конструируйте Ваши exceptions и прочую муть. Это ничего не докажет
Ваши абстрактные рассуждения уже бессмысленно повторяются
Во-первых, расчетная оценка ОФ не всегда будет искажать граф, даже скорее всего чаще не будет.
Это очень сильно от типа эндшпиля зависит. Поэтому движок который их не различает, будет как правило проигрывать тому, который умеет оценивать риск получить по мозгам из-за игнора таблиц.
Вы не согласны, что каждый красный узел есть финита
С этим я конечно согласен. Просто если Вы финиту сходу не получили, а должны были считать и вот наконец на глубине 10 вдруг осталось 7 фигур, то от вашей финиты мало пользы. Перерисуйте дерево, где красные точки возникают только на глубине, когда комп и так обрывает расчёт. Именно для борьбы с этой ситуацией и введены вышеуказанные параметры.
Что значит проигрывать? При ограничении по времени расчет дальше (без таблиц) может быть полезнее
Я говорю про случай когда один движок не пользует вообще, а другой не пользует только для тех эндшпилей где это не нужно. Ферзь против коня например с пешками.
Проигрывать значит получать нули вместо ничьих или половинки вместо единиц, теряя очки за счет дурного и бесполезного расчета того, что давно посчитано в тех эндшпилях где между оценками на лету и табличными расхождение может быть большое.
Владимирович вон приводил пример ладейника с крайней пешкой. Движок который будет считать что там у сильнейшей стороны все хорошо туда провалится, например, разменяв слонов и потеряет пол очка. Легко.
Просто если Вы финиту сходу не получили, а должны были считать и вот наконец на глубине 10 вдруг осталось 7 фигур, то от вашей финиты мало пользы. Перерисуйте дерево, где красные точки возникают только на глубине, когда комп и так обрывает расчёт
ЗАЧЕМ перерисовывать дерево?
Вы вообще точно понимаете, о чем говорите?
Дерево не меняется. Оно только растет.
Меняются оценки в узлах.
Если в узле 6(7) фигур, вызываются таблицы.
Поскольку для каждого узла вызов таблиц быстрее, чем ОФ, если там нет лишнего ферзя, то согласну математической индукции, это верно и для N узлов
И если Вы не хотите этого понимать, Вам нужно предоставить более серьезные аргументы
Я говорю про случай когда один движок не пользует вообще, а другой не пользует только для тех эндшпилей где это не нужно. Ферзь против коня например с пешками.
Проигрывать значит получать нули вместо ничьих или половинки вместо единиц, теряя очки за счет дурного и бесполезного расчета того, что давно посчитано в тех эндшпилях где между оценками на лету и табличными расхождение может быть большое.
Владимирович вон приводил пример ладейника с крайней пешкой. Движок который будет считать что там у сильнейшей стороны все хорошо туда провалится, например, разменяв слонов и потеряет пол очка. Легко.
Это все верно конечно.
Но представьте себе, что например в 10-фигурном окончании диск слишком завертелся от "испробывания" баз и в результате движок точно посчитал шестифигурники, но не успел заметить удар на 10-м ходу в восьмифигурнике