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

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

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

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

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

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

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

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

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

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

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

--------------------

Мои статьи можно почитать на сайте "Преф-Ревю"

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

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

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

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

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

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

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

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

--------------------

Мои статьи можно почитать на сайте "Преф-Ревю"

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

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

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

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

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

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

Это сообщение отредактировал Pochemuk - 30/11/2017, 22:21

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

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

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

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

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

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

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

--------------------

the elephant has you..

А смы-ы-ысл?

Проверки и всякая защита от дурака - обязаны быть. Хотя бы для того, чтобы не рассчитал совсем не то, что хотел. Ну или не подвесил прогу, потому что на руке 9 карт, из них три бубновых туза.

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

ну что там, не уменьшили время подсчёта с 7 до 6 часов?)

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

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

А с вводом из строки это совсем не так.