Главная В клубе 1954 Войти
Здравствуйте, гость Правила · Помощь

»  Оценка карты играющего при заданном сносе, Определение результата игры для мизера и игры на взятки Подписаться | Сообщить другу | Версия для печати
      » 8/11/2017, 14:33,  Кутруповезет 
Рассказываю эту историю по порядку.
Года два назад в теме «стоит ли играть мизер?» обсуждался некий мизер со своим ходом после прикупа для двух стратегий сноса:
https://www.gambler.ru/forum/index.php?show...dpost&p=1481354
Пытались определить, какой снос лучше. Один из участников обсуждения - ув. Pochemuk - использовал метод Монте-Карло и программу Алексея Словеснова «Bridge-Preference Studio». Он написал генератор случайных раскладов, сгенерил 200 раскладов вистующих и «прорешал каждый при помощи BPS». При этом каждый конкретный расклад вручную посылал на BPS и сохранял результат. Были получены результаты для двух сносов – довольно близкие. Далее прикинули СКО и дисперсию и пришли к выводу, что для этого конкретного мизера достоверность полученных результатов совершенно недостаточна – мало число испытаний. А для получения достоверного результата в этом случае нужно от 5000 до 15000 испытаний, что сделать с помощью текущей версии программы BPS нереально. Т.е. вопрос о лучшем сносе для той карты остался открытым. Не привожу здесь тот мизер, потому что дело не в нем, а в способе получения результата.

Весной этого года я снова обдумывал эту тему и этот метод получения результата. Решил написать автору BPS Алексею Словеснову письмо с просьбой немного усовершенствовать его программу. В письме я просил Алексея добавить в его программу такие возможности:
• для заданных карт и сноса играющего - генерировать случайный расклад карт у вистующих, и производить розыгрыш,
• задавать необходимое число розыгрышей,
• выдавать конечный результат серии – процентную долю исходов игры разного типа.
В своей просьбе я ссылался на то, что энтузиасты тратят часы и дни своего времени на попытки решения таких задач, на то, что большая часть того, что требуется для реализации такого усовершенствования программы, уже имеется (есть и генератор случайных раскладов, и, самое главное - высококачественный решатель), и на то, что для BPS определение лучшего сноса – это новый большой класс решаемых задач.

Через некоторое время Словеснов выполнил мою просьбу, за что ему огромное спасибо. Причем сделал он это намного лучше, чем просили! Он не стал вводить случайные расклады с помощью ММК, а сделал точное решение – полный перебор всех 184756 раскладов. Эту версию программы он назвал «версия 5.01 7 июня 2017»:
http://slovesnov.users.sourceforge.net/ind...?bridge,russian
С помощью этой версии любой желающий может, задав 10 карт играющего и 2 карты сноса, получить ожидаемый результат игры. Результат выдается в виде вероятностей получения 0, 1, 2, …10 взяток. На расчет требуется несколько минут в зависимости от карты и производительности компьютера.

Далее я попытался предложить Словеснову кое-что подправить и сделать некоторые другие усовершенствования. Однако он сообщил, что у него теперь нет ни времени, ни желания заниматься этим делом, а потом и вовсе перестал отвечать. Даже на своем собственном сайте он выложил новую версию программы 5.01, но не дал к ней никаких пояснений.

Думаю, что последняя версия BPS многим будет полезна, тем более что там выложены и исходные коды. Ниже приведу краткие объяснения и комментарии к работе этой программы.
• Новая опция - последняя в меню "дополнительно"/"(преферанс) решить все расклады противников",
• опция работает как для мизера, так и для игры на взятки,
• результаты расчета получаются при копировании в буфер обмена в виде вероятностей получения 0, 1, 2, …10 взяток,
• для начала расчета необходимо, чтобы были заданы 10 карт у игрока и 2 карты в сносе,
• (не уверен, что обязательно, но рекомендуется) – карты играющего следует располагать в верхней части экрана,
• возможны два варианта расчета: когда сделан первый ход (одна карта на столе), и когда первый ход еще не сделан,
• в случае второго варианта расчета, когда первый ход не сделан, для каждого из 184756 раскладов определяется оптимальный первый ход. То есть, это подразумевает игру на картах, открытых ДО первого хода. (Нужно заметить, что в преферансе такая возможность действительно есть, если первый ход у вистующих, и для этого случая программа все посчитает верно. Но играющему расклад перед своим первым ходом не известен никогда (по правилам вистующие открывают карты только после хода играющего), поэтому для первого хода играющего такой лучший ход и расчет не имеет практического смысла. Словеснову я посоветовал убрать эту возможность расчета с первым ходом играющего и не заданной картой выхода, но он уже замолчал).

О точности полученных результатов. Результаты, полученные с помощью последней версии программы BPS, мне кажутся очень правдоподобными. Подобные расчеты на Гамблере несколько раз выкладывал ув. Extasy, и даже грозился сделать их общедоступными. Я сравнил приведенные на сайте результаты Extasy с результатами Словеснова для десятка разных раскладов. Все результаты оказались совершенно одинаковы, точнее, совпадающими до 8 знака. Это, конечно, радует.
      » 8/11/2017, 18:39,  extasy 
Загрузил программу Словеснова. Действительно, очень полезное нововведение.
Протестировал на 1 раскладе, результаты совпали с работой моей программы.

Для расчетов простых типов задач программу Словеснова можно использовать. Тем более есть графический интерфейс.

Мне интересно только одно, как ему удалось распараллелить рекурсивную задачу и насколько эффективно работает многопоточность по сравнение с одним потоком.

Для расчета задачи до взятия прикупа есть идея как эффективно распараллелить - можно создать свою хэш-таблицу на каждый прикуп и каждый поток будет решать отдельную задачу.
Но в задаче с фиксированным сносом непонятно как распараллелить, ибо там множественные обращения к единственной хэш-таблице на разной глубине рекурсии.

По поводу моей программы - я уже длительное время над ней не работал. Привинтил простенький интерфейс, который нужно довести до ума.
Надеюсь, в скором времени возобновлю работу.

--------------------
the elephant has you..
      » 9/11/2017, 16:19,  Pochemuk 
extasy ( 8 нояб. 2017, 18:39)
Мне интересно только одно, как ему удалось распараллелить рекурсивную задачу и насколько эффективно работает многопоточность по сравнение с одним потоком.

Ну, он же исходники не жадничает выкладывать smile.gif

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

А есть ли смысл? Я еще не пробовал, но BPS теперь считает быстрее, чем твоя программка?
      » 9/11/2017, 16:24,  Pochemuk 
Кутруповезет ( 8 нояб. 2017, 14:33)
Но играющему расклад перед своим первым ходом не известен никогда (по правилам вистующие открывают карты только после хода играющего), поэтому для первого хода играющего такой лучший ход и расчет не имеет практического смысла.

В Скачках и некоторых других конвенциях вистующие вскрываются перед атакой играющего. Но не на мизере, разумеется.
      » 9/11/2017, 16:30,  Pochemuk 
Чёрт!

После установки программа не запускается. Мол не найдена какая-то точка входа в процедуру.
      » 9/11/2017, 16:38,  extasy 
Pochemuk ( 9 нояб. 2017, 16:19)
extasy ( 8 нояб. 2017, 18:39)
Мне интересно только одно, как ему удалось распараллелить рекурсивную задачу и насколько эффективно работает многопоточность по сравнение с одним потоком.

Ну, он же исходники не жадничает выкладывать smile.gif

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

А есть ли смысл? Я еще не пробовал, но BPS теперь считает быстрее, чем твоя программка?

Не, там нереально в исходниках разобраться сколько литров ни возьми, все на Си, насколько помню.

BPS, хоть и многопоточная, но медленнее моей однопоточной проги.
Пока лень тестировать нормально, но 1 расклад у меня считался на 70% быстрее.

Другое дело, что моя прога требует немало оперативки для хэш-таблицы. А BPS совсем мало ест памяти.

Буду реализовывать многопоточность. В принципе знаю как, но для расчета задач с фикс. сносом прогнозируется небольшой прирост порядка 300%, причем увеличение числа ядер компьютера уже не даст преимуществ и 4-ядерный комп будет давать максимум нужных потоков.
То есть, на 1 руке у нас цикл по всем возможным ходам (врядли, больше 8) и на каждый ход выделим свой поток. Но жертвуем альфа-бета отсечением на 1 итерации, поэтому ускорение будет не в теоретические 8 раз(точнее, количество раз по числу различных ходов с первой руки), а раза в 3 (максимум, учитывая издержки на формирование потоков).
Но тут пока непонятно, как поведут себя потоки при запросах к единой хэш-таблице: у нас же будет постоянная запись/считывание раскладов.

Зато многопоточность идеально подойдет для случая самой тяжелой задачи - то есть, расчета МО до взятия прикупа. Там на каждый прикуп создаем свою хэш-таблицу и выделяем свой поток. Поэтому, ускорение будет пропорционально числу ядер процессора.
Пожалуй, для случая 8-ядерного процессора можно добиться х10 увеличения производительности для этой задачи.

--------------------
the elephant has you..
      » 9/11/2017, 16:53,  Pochemuk 
Ну так у нас лучше организованы транспозиции. Поэтому и быстрее.

У Словесного тоже немало памяти требуется. Но у него другая организация хеш-таблиц. Прямое кэширование с вытеснением, что считается самой быстрой формой. Только вытеснение не немедленное, а отложенное - в каждую ячейку-страницу таблицы можно записать до 4 значений, прежде чем начнут стираться.

И если какая-то ячейка переполнится и начнет очищаться, то это ни к чему плохому не приведет.

А у тебя сейчас - кэширование с открытой адресацией.
Во-первых, он начинает сильно тормозить, если хеш таблица заполнена более, чем на 50-60%.
А во-вторых, теоретически (и практически у тебя это получилось сделать) возможно ее переполнение с непредсказуемыми результатами.

Поэтому ее и приходится делать большой, в отличие от хеш-таблицы с вытеснением.

Может быть стоит попробовать так, как у Словеснова. Но еще лучше - в чистом виде вытеснение. Это самый быстрый вариант при достаточной памяти. А при недостаточной - краха все равно не будет. Только медленнее будет считать.

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

Это сообщение отредактировал Pochemuk - 9/11/2017, 17:19
      » 9/11/2017, 17:20,  extasy 
Pochemuk ( 9 нояб. 2017, 16:53)
Ну так у нас лучше организованы транспозиции. Поэтому и быстрее.

У Словесного тоже немало памяти требуется. Но у него другая организация хеш-таблиц. Прямое кэширование с вытеснением, что считается самой быстрой формой. Только вытеснение не немедленное, а отложенное - в каждую ячейку-страницу таблицы можно записать до 4 значений, прежде чем начнут стираться.

Может быть стоит попробовать так. Но еще лучше - в чистом виде вытеснение. Это самый быстрый вариант при достаточной памяти.

Я уже давно реализовал 4 ячейки с вытеснением.
Но на малых таблицах это будет плохо работать в любом случае, ибо будет частая перезапись нужных раскладов.
Pochemuk ( 9 нояб. 2017, 16:53)
Если разрабатывать многопоточность на общих таблицах, то придется разрабатывать механизм блокировки и транзакций. т.е., если один поток обрабатывает какую-то ячейку таблицы, то остальные не могут даже ее считать и ждут, пока она обновится и освободится.

В том то и дело. Не хотелось бы вникать в тонкости многопоточности, если это не даст существенного прироста на простом типе задач.
Эти блокировки явно будут время отнимать. Если там профит 100% всего, то нет смысла мучаться, тем более и так задача достаточно быстро решается в одном потоке.
А для сложных задач уже можно использовать частные таблицы и реализовать это достаточно просто.

--------------------
the elephant has you..
      » 9/11/2017, 17:26,  Pochemuk 
extasy ( 9 нояб. 2017, 17:20)
Я уже давно реализовал 4 ячейки с вытеснением.
Но на малых таблицах это будет плохо работать в любом случае, ибо будет частая перезапись нужных раскладов.

В том то и дело. Не хотелось бы вникать в тонкости многопоточности, если это не даст существенного прироста на простом типе задач.
Эти блокировки явно будут время отнимать. Если там профит 100% всего, то нет смысла мучиться, тем более и так задача достаточно быстро решается в одном потоке.
А для сложных задач уже можно использовать частные таблицы и реализовать это достаточно просто.

А ты сравнивал производительность с прямым вытеснением (без массива в каждой ячейке)?

Думаю, кстати, что там на 4-ядерном процессоре выигрыш будет раза в 1,5-2. Ведь одно ядро будет обслуживать систему, второе тоже сильно не загрузишь. Остаются 2 ядра, которые на маленьких хеш-таблицах будут мешать друг другу. А на больших и без многопоточности неплохо работает.

А как там с мультитэйблом?

Это сообщение отредактировал Pochemuk - 9/11/2017, 17:38
      » 9/11/2017, 17:39,  Dukhin 
Pochemuk ( 9 нояб. 2017, 16:30)
Чёрт!

После установки программа не запускается. Мол не найдена какая-то точка входа в процедуру.

на xp тоже не пошло, dll подсунул - на что-то другое ругаться начало.
на форумах советуют что-то там править и пересобирать.

а на w7 нормально работает
      » 9/11/2017, 17:43,  Pochemuk 
Dukhin ( 9 нояб. 2017, 17:39)
Pochemuk ( 9 нояб. 2017, 16:30)
Чёрт!

После установки программа не запускается. Мол не найдена какая-то точка входа в процедуру.

на xp тоже не пошло, dll подсунул - на что-то другое ругаться начало.
на форумах советуют что-то там править и пересобирать.

а на w7 нормально работает

У меня заработало после того, как я изничтожил предыдущую установку и установил новую с нуля.
      » 9/11/2017, 23:36,  extasy 
Pochemuk ( 9 нояб. 2017, 17:26)
А ты сравнивал производительность с прямым вытеснением (без массива в каждой ячейке)?

Не помню, может быть. В любом случае смысла мало и прироста не будет.

Pochemuk ( 9 нояб. 2017, 17:26)
А как там с мультитэйблом?

Никак. Врядли мультитэйбл улучшит ситуацию, только на системах с малым количеством оперативной памяти, где будут часто происходить перезаписи на коллизиях.
А на нормальных обьемах памяти прирост будет в пределах 5%, уверен.

Техническими средствами сложно оптимизировать систему. Зато можно покопать спец. алгоритмы, типа поиска хорошего хода во взятку. Тут поле непахано. Уже сейчас простые алгоритмы поиска в 1.5-3 раза ускоряют перебор. А если разработать более изощренные алгоритмы анализа лучшего хода, то можно еще в разы поднять скорость.

Это сообщение отредактировал extasy - 9/11/2017, 23:46

--------------------
the elephant has you..
      » 10/11/2017, 00:37,  Pochemuk 
extasy ( 9 нояб. 2017, 23:36)
Техническими средствами сложно оптимизировать систему. Зато можно покопать спец. алгоритмы, типа поиска хорошего хода во взятку. Тут поле непахано. Уже сейчас простые алгоритмы поиска в 1.5-3 раза ускоряют перебор. А если разработать более изощренные алгоритмы анализа лучшего хода, то можно еще в разы поднять скорость.

Давай называть вещи своими именами smile.gif

Поиск хорошего хода - это одна из целей алгоритма и результат его работы. В конечном счете он находит лучший ход или множество лучших ходов в каждой позиции.

А то, о чем ты говоришь, правильнее было бы назвать "прогнозирование лучшего хода".

Что касается прироста при прямом вытеснении, то тут не соглашусь ...

Вот смотри ... Есть хеш-таблица со страничной организацией. На каждой странице до 4-х кэшируемых позиций.

Если эта таблица мала, то страницы часто полностью заполнены. Приходится иногда пробегать всю страницу в поисках нужной позиции. А если такая не найдена, то удалять самую старую, записывать на ее место новую, менять указатель (номер) самой старой на следующую. Т.е. накладные расходы велики.

Если таблица велика, то страницы пусты или заполнены на 1-2 элемента. В этом случае число коллизий на такой страничной хеш-таблице будет соразмеримо с числом коллизий на таблице с прямым вытеснением. Но при этом будут все равно дополнительные накладные расходы на просмотр почти пустых страниц.

Да ... в условиях нехватки памяти страничная организация хешей позволяет более эффективно ее использовать, что ведет к снижению числа коллизий.
Но при достаточной памяти оба метода выходят на плато - увеличение размера перестает заметно влиять на число коллизий. И на этих плато прямое вытеснение оказывается более эффективным за счет простоты.
      » 10/11/2017, 03:10,  платан 
Таким образом, единственный способ борьбы со всеми этими программами, равно как и обычными игроками - делать как можно более невероятный снос, который ни одна программа никогда в жизни не просчитает!
      » 11/11/2017, 11:35,  Pochemuk 
К сожалению, новая версия BPS у меня дома не работает. Тому как там здесь у меня тоже XP. А для XP нет какой-то динамической библиотеки. Жаль ...

А на работе нет времени и возможности таким заниматься ...
      » 28/11/2017, 19:57,  Morozko_prr 
Погонял тут на досуге прогу Словеснова на посчитанных мною ранее (ВРУЧНУЮ !!!) мизерах. Ответственно заявляю, что у нее очень и очень неплохой результат по МО. Погрешность не превышает 0,01 СЧМ (в скобках дается мой результат расчета):

1) На мизере Сашуна (В)_9(Д)_1097_ТД10987 (Ход чужой):
-2,00503 (-2,01365). Время расчета проги - 409 мин(**) (у меня с учетом занятости, отдыха и перепроверок моих расчетов ВРУЧНУЮ уходило примерно 2 недели в среднем),
---
Если же схитрить и задать 1-й ход мизериста в 8 бубен (предварительно заменив 9б на 8б), то результат будет:
-2,01608, а время расчетов уменьшится до 65 мин (т.е. в 6 с лишним раз !!!)

2) Мизер 10(Д)_8(9)_10987_10987 (1-й Ход свой в 10п):
-1,13708 (-1,13623 (*)). Время работы проги - 4 мин.

3) Мизер (10Д)_89_10987_10987 (1-й Ход свой в 9тр):
-1,02466 (-1,04755, возможно у меня имеется ошибка, но м.б. и нет (*)). Время работы проги - 3 мин.

---
(*) Я считал эти МО с вычетами (из общего количества всевозможных раскладов вистующих) расклады, где у них 9/10-ная на руке с раздачи (коих примерно 3000 штук), а также ДОПОЛНИТЕЛЬНО вычетов из числителя тех раскладов, где мизер не ловится из-за отсутствия достаточного количества переходов между руками вистующих для ловли мизера (коих примерно 2830/4080 ).

---
Проге же Словеснова, как я понимаю, пофиг есть ли на руках у вистующих 9/10 с раздачи или нет...

(**) Проц Core I5 (4-х ядерный, частота 3,1 Ггц) был загружен на 100%, а вот памяти, кстати, прога мало ест...


--------------------
Мои статьи можно почитать на сайте "Преф-Ревю"
      » 28/11/2017, 21:07,  extasy 
Morozko_prr (28 нояб. 2017, 19:57)
1) На мизере Сашуна (В)_9(Д)_1097_ТД10987 (Ход чужой):
-2,00503 (-2,01365). Время расчета проги - 409 мин(**)

(**) Проц Core I5 (4-х ядерный, частота 3,1 Ггц) был загружен на 100%, а вот памяти, кстати, прога мало ест...


Почти 7 часов?? как такое может быть?

Моя прога этот мизер посчитала за 57 сек на посредственном компе.

Запустил BPS - действительно, крайне медленно считает этот мизер. Думаю, это какая-то ошибка в коде, так долго не должно считать. Почти наверняка косяк в том, что при расчете мизера не с 1й руки забыли прикрутить хэширование.

Это сообщение отредактировал extasy - 28/11/2017, 22:47

--------------------
the elephant has you..
      » 28/11/2017, 21:11,  Сашун 
Morozko_prr (28 нояб. 2017, 20:57)
1) На мизере Сашуна (В)_9(Д)_1097_ТД10987 (Ход чужой): ... Время расчета проги - 409 мин(**)
----------------
(**) Проц Core I5 (4-х ядерный, частота 3,1 Ггц) был загружен на 100%, а вот памяти, кстати, прога мало ест...

Какой кошмар! 7 часов машинного времени, чтобы определить лучший снос при простейшем мизере smile.gif

Что-то не так в Вашем королевстве © . Начинающие справляются со сносом на таком мизере, примерно, секунд за 20-30, а чуть больше опытные игроки - секунд за 5 smile.gif

--------------------
С уважением, А.Малышев
      » 28/11/2017, 23:19,  Morozko_prr 
extasy (28 нояб. 2017, 21:07)
Morozko_prr (28 нояб. 2017, 19:57)
1) На мизере Сашуна (В)_9(Д)_1097_ТД10987 (Ход чужой):
-2,00503 (-2,01365). Время расчета проги - 409 мин(**)

(**) Проц Core I5 (4-х ядерный, частота 3,1 Ггц) был загружен на 100%, а вот памяти, кстати, прога мало ест...


Почти 7 часов?? как такое может быть?

Моя прога этот мизер посчитала за 57 сек на посредственном компе.

Запустил BPS - действительно, крайне медленно считает этот мизер. Думаю, это какая-то ошибка в коде, так долго не должно считать. Почти наверняка косяк в том, что при расчете мизера не с 1й руки забыли прикрутить хэширование.

Николай !
Так опубликуйте же, наконец, свою прогу !!! Еще в марте 2017 г. обещали опубликовать ?!

--------------------
Мои статьи можно почитать на сайте "Преф-Ревю"
      » 28/11/2017, 23:53,  extasy 
Morozko_prr (28 нояб. 2017, 23:19)

Николай !
Так опубликуйте же, наконец, свою прогу !!! Еще в марте 2017 г. обещали опубликовать ?!

Интерфейс не готов. Могу код скинуть для компиляции. Если есть навыки в программировании, то проблем в запуске не будет.

--------------------
the elephant has you..
      » 29/11/2017, 13:50,  Morozko_prr 
extasy (28 нояб. 2017, 23:53)
Morozko_prr (28 нояб. 2017, 23:19)

Николай !
Так опубликуйте же, наконец, свою прогу !!! Еще в марте 2017 г. обещали опубликовать ?!

Интерфейс не готов. Могу код скинуть для компиляции. Если есть навыки в программировании, то проблем в запуске не будет.

Ну, блин и отговорочка !
Какой там нужен супер-пупер интерфейс, а ?!

Я предлагаю такой:
После запуска проги появляется окно с черным фоном и 4-мя последовательными вопросами, на которые User должон дать последовательные же ответы (вопросы и ответы остаются на экране после ввода ответов User-ом):

0) Выбор контракта (если ваша прога умеет считать МО и вероятности розыгрыша еще и НЕмизеров) и масти козыря (Например: 6A, 7C, 8D, 9H, M)

1) Ввести расклад для обсчета (10 карт)

2) Ввести снос (2 карты не входящие в в.у. 10 карт расклада для обсчета)

3) Ввести номер руки (1/2/3).

Потом нажать Enter и запустить обсчет расклада.
---

Через -дцать СЕКУНД (а НЕ сотен минут) уже смотреть результат в виде данных выведенных в столбик:
Кол-во взяток - доля раскладов (=вероятность такого исхода розыгрыша)
МО расклада (сразу ПОСЛЕ сноса, но ДО открытия карт вистующими).

---
Ну не знаю я программирование в достаточном объеме, чтобы написать ЭТОТ, тем не менее, ОЧЕНЬ простой интерфейс.

Ребята, кто шарит в программировании, ну напишите, плиз, в.у. "интерфейс", а !!!

--------------------
Мои статьи можно почитать на сайте "Преф-Ревю"
      » 29/11/2017, 21:20,  Pochemuk 
Morozko_prr (29 нояб. 2017, 13:50)
Ну, блин и отговорочка !
Какой там нужен супер-пупер интерфейс, а ?!

Я предлагаю такой:

И Вы считаете это простым интерфейсом? Это как раз пример очень сложного громоздкого, интуитивно непонятного, недружественного интерфейса.

Вот пользователь пытается ответить на первый вопрос. Как там нужно вводить контракт и масть? Слитно или раздельно? Строчными буквами или прописными? Латиницей или кириллицей? Латиницей? А как правильно пишется "Порше" по английски будет "без козыря"?

И так по каждому вопросу. Мало того, что пользователю нужно помнить массу правил, так стараться еще не опечататься при вводе.

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

Другое дело - графический интерфейс. Написать его сложнее, зато карты в руке могут быть только стандартные, не могут дублироваться, посчитать их количество проще простого, контракт\козырь выбирается из списка. Рука играющего - тоже.

В общем, возможность ошибиться сводится к минимуму. А значит и проверки правильности ввода минимальны.

Не говоря уже о том, что использовать два пальца одной руки на мышке тоже несколько удобнее, чем два пальца разных рук на клавиатуре.
      » 30/11/2017, 14:44,  Morozko_prr 
2 Pochemuk
"Я кричал: «Вы что ж там, обалдели? —
Уронили шахматный престиж!»
Мне сказали в нашем спортотделе:
«Ага, прекрасно – Ты и защитишь !" (В.С.Высоцкий "ЧЕСТЬ ШАХМАТНОЙ КОРОНЫ I. Подготовка" 1972 г.)
---
Мне для работы вполне достаточен и предложенный мною выше интерфейс, а по поводу ошибок введения данных, то при введении неверных - отправлять повторно вопрос и в скобках дать пример правильного ввода...

--------------------
Мои статьи можно почитать на сайте "Преф-Ревю"
      » 30/11/2017, 22:20,  Pochemuk 
Morozko_prr (30 нояб. 2017, 14:44)
Мне для работы вполне достаточен и предложенный мною выше интерфейс, а по поводу ошибок введения данных, то при введении неверных - отправлять повторно вопрос и в скобках дать пример правильного ввода...

А давайте отвлечемся на минуточку от эгоцентрической позиции "мне достаточно" и поймем ту простую истину, что написание такого простого примитивного интерфейса - задача сложная и нетривиальная. По той причине, что мы имеем очень свободный, неструктурированный протокол для входной информации. Т.е. написать в строчке можно любую ахинею, а программе мучайся, разбирайся в ней. Но сначала мучиться придется программисту, который должен "научить" программу отделять корректный ввод от ахинеи. Но т.к. вариантов ахинеи гораздо больше вариантов корректного ввода, то "учить" её будет мучительно больно и трудно.

Если бы я был программистом, то наверное писал бы блок-анализатор ввода на основе детерминированного автомата. Но и его одного было бы мало, т.к. кроме парсинга входной строки потом надо проверять выполнение прочих условий.
Т.е. мы бы получили бы такой мини-компилятор со своим лексическим и синтаксическим анализаторами.

Гораздо проще в таком случае как раз написать графический интерфейс формы ввода. Не как у Словеснова, наверное, а как в "Преф Гуру". Вот это было бы оптимальное соотношение трудоемкости создания интерфейса и его возможностей.

Т.е. кнопки-карты с текстовыми обозначениями, радиокнопки или списки для выбора контракта и руки, переключение руки/сноса по клику на этих областях. Поля для формирования представления руки и сноса. Поле вывода результата, кнопки начала расчета, сохранения результата, выхода.

При этом логика интерфейса уже в процессе тырканья по кнопочкам ведет счет карт. Так что ошибиться и скинуть три карты или взять в руку больше 10 карт ну никак не возможно. Так же невозможно сдублировать карту или ввести несуществующую карту.

Таким образом, в конце остается проверить всего несколько мелких условий, а именно: число карт в руке = 10, в сносе = 2. И все, пожалуй.

Это сообщение отредактировал Pochemuk - 30/11/2017, 22:21
      » 30/11/2017, 23:21,  Dukhin 
а на каком языке исходники?
      » 1/12/2017, 00:06,  extasy 
Pochemuk (30 нояб. 2017, 22:20)
А давайте отвлечемся на минуточку от эгоцентрической позиции "мне достаточно" и поймем ту простую истину, что написание такого простого примитивного интерфейса - задача сложная и нетривиальная. По той причине, что мы имеем очень свободный, неструктурированный протокол для входной информации. Т.е. написать в строчке можно любую ахинею, а программе мучайся, разбирайся в ней. Но сначала мучиться придется программисту, который должен "научить" программу отделять корректный ввод от ахинеи. Но т.к. вариантов ахинеи гораздо больше вариантов корректного ввода, то "учить" её будет мучительно больно и трудно.

Если бы я был программистом, то наверное писал бы блок-анализатор ввода на основе детерминированного автомата. Но и его одного было бы мало, т.к. кроме парсинга входной строки потом надо проверять выполнение прочих условий.
Т.е. мы бы получили бы такой мини-компилятор со своим лексическим и синтаксическим анализаторами.

Гораздо проще в таком случае как раз написать графический интерфейс формы ввода. Не как у Словеснова, наверное, а как в "Преф Гуру". Вот это было бы оптимальное соотношение трудоемкости создания интерфейса и его возможностей.

Т.е. кнопки-карты с текстовыми обозначениями, радиокнопки или списки для выбора контракта и руки, переключение руки/сноса по клику на этих областях. Поля для формирования представления руки и сноса. Поле вывода результата, кнопки начала расчета, сохранения результата, выхода.

При этом логика интерфейса уже в процессе тырканья по кнопочкам ведет счет карт. Так что ошибиться и скинуть три карты или взять в руку больше 10 карт ну никак не возможно. Так же невозможно сдублировать карту или ввести несуществующую карту.

Таким образом, в конце остается проверить всего несколько мелких условий, а именно: число карт в руке = 10, в сносе = 2. И все, пожалуй.

Вообще, консольный ввод организовать очень просто. Без всяких там проверок, конечно.

Наверное, так и сделаю. Допилю структурно программу, проверю работоспособность на разных типах задач и форматирование вывода результатов и сделаю консольный интерфейс для особо нетерпеливых.

Ну а графику уже потом можно допилить.

А вообще, кто там со Словесновым в контакте - можно передать, что у него с чужого хода хэширование не пашет. Ему наладить код пара минут. И проблема с многочасовыми расчетами решена..

Dukhin (30 нояб. 2017, 23:21)

а на каком языке исходники?

Моя программа на С++, графику делаю через библиотеку Qt.

Это сообщение отредактировал extasy - 1/12/2017, 00:09

--------------------
the elephant has you..
      » 1/12/2017, 00:44,  Pochemuk 
extasy ( 1 дек. 2017, 00:06)
Вообще, консольный ввод организовать очень просто. Без всяких там проверок, конечно.

А смы-ы-ысл?

Проверки и всякая защита от дурака - обязаны быть. Хотя бы для того, чтобы не рассчитал совсем не то, что хотел. Ну или не подвесил прогу, потому что на руке 9 карт, из них три бубновых туза.
      » 1/12/2017, 10:07,  Kirk 
Говорят, что когда еще только внедряли мышь как устройство указания - тогдашние программисты рвали себе волоса на всех частях тела: "блин, это теперь МНЕ надо заранее придумать, что юзер может захотеть..."
      » 1/12/2017, 13:09,  платан 
ну что там, не уменьшили время подсчёта с 7 до 6 часов?)
      » 1/12/2017, 16:21,  Pochemuk 
Kirk ( 1 дек. 2017, 10:07)
Говорят, что когда еще только внедряли мышь как устройство указания - тогдашние программисты рвали себе волоса на всех частях тела: "блин, это теперь МНЕ надо заранее придумать, что юзер может захотеть..."

На самом деле протокол взаимодействия мыши с компом (HID-рапорт) и с пользователем гораздо проще ввода данных из строки. Ибо стандартизирован, а количество допустимых значений в пакетах HID-рапортов сильно ограничено.

Кроме того, HID-рапорты поступают постоянным однородным потоком, ни один из них не имеет преимущества перед другими, ни один из них не влияет на интерпретацию потока.

А с вводом из строки это совсем не так.
« Предыдущая тема | Перечень тем | Следующая тема »
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей: