Насколько квалифицированным надо быть чтобы написать эту программу,насколько это сложно?
Очень надеюсь на ваши советы.
Сап,Реахтур.Знаю здесь много талантливых тыжпрограммистов,которым я хочу задать вопрос:насколько сложен механизм/алгоритм "Акинатора"?
Насколько квалифицированным надо быть чтобы написать эту программу,насколько это сложно?
Очень надеюсь на ваши советы.
Насколько квалифицированным надо быть чтобы написать эту программу,насколько это сложно?
Очень надеюсь на ваши советы.
Тебе нужна просто большая база ответов, что от тыжпраграммистов зависит не сильно D:
24.02.2015, 19:01
http://rutracker.org/forum/viewtopic.php?t=546159
Вот здесь (книга 1991 года) есть программа игры "Животные" на Бейсике - фактически тот же Акинатор (страница 65).
Нужно еще погуглить "игра Животные".
http://www.sql.ru/forum/946301/igra-ugaday-zhivotnoe-ispolzuya-principy-oop-v-delphi-pomogite-pozhaluysta
Вот здесь (книга 1991 года) есть программа игры "Животные" на Бейсике - фактически тот же Акинатор (страница 65).
Нужно еще погуглить "игра Животные".
http://www.sql.ru/forum/946301/igra-ugaday-zhivotnoe-ispolzuya-principy-oop-v-delphi-pomogite-pozhaluysta
Y и Н на одной кнопке же, лол.
Как это сделал бы я.
1. Тут все пишут про базу знаний, но зыбывают про базу вопросов. Это первое что я бы подготовил. Вопросы типа: Это реалньный персонаж? Это мужчина? Старше 25. и т.п.
2. Создал бы БД. с полями isReal, isMan, isOlder25 и т.п.
3. Выводим вопрос: Это реальный персонаж? По результату делаем запрос в базу. Получаем пустой сет, но пока продолжаем задавать вопросы, допустим, если сет пустой задаем 5 вопросов. После того как задали эти 5 вопросов пишем "Я сдаюсь, напиши что это за персонаж". Запомненные вопросы и имя персонажа вносим в нашу базу.
4. Если вернулось больше одной записи, продолжаем задавать вопросы, пока не вернется 1 запись. Как только запись будет 1 выводим имя перса. И спрашиваем у пользака правильно ли мы угадали или нет. Если да - конец. Если нет, предлагаем ввесити имя перса (пополняем базу)
как-то так.
1. Тут все пишут про базу знаний, но зыбывают про базу вопросов. Это первое что я бы подготовил. Вопросы типа: Это реалньный персонаж? Это мужчина? Старше 25. и т.п.
2. Создал бы БД. с полями isReal, isMan, isOlder25 и т.п.
3. Выводим вопрос: Это реальный персонаж? По результату делаем запрос в базу. Получаем пустой сет, но пока продолжаем задавать вопросы, допустим, если сет пустой задаем 5 вопросов. После того как задали эти 5 вопросов пишем "Я сдаюсь, напиши что это за персонаж". Запомненные вопросы и имя персонажа вносим в нашу базу.
4. Если вернулось больше одной записи, продолжаем задавать вопросы, пока не вернется 1 запись. Как только запись будет 1 выводим имя перса. И спрашиваем у пользака правильно ли мы угадали или нет. Если да - конец. Если нет, предлагаем ввесити имя перса (пополняем базу)
как-то так.
Гхм... уважаемые минусующие, извините, что я не использовал терминов типа "бинарные деревья" и не нагуглил распечатку сурцов древних как говно мамонта, а также не пустился в пространные размышления. Я всего лишь попытался описать алгоритм который можно максимально просто реализовать. Да возможно он не идеален. Но с него можно начать, а походу будет ясно что в нем не так и куда копать. Вот. А вы... со своими минусами... и даже без объяснений... фу такими быть.
Возможно из-за "создал бы БД с полями", вместо "таблицу с полями" или запятую не там поставил. Реактор же. Ну и вообще криво написал конечно. Но это же не ТЗ, просто набросок. Формировали, думаю, как у меня написано давали проходить друзьям знакомым.
В 2004 как минимум http://web.archive.org/web/20040101000000*/http://akinator.com
Для введения новых вопросов придётся добавлять поля. Я, конечно, не спец по внутренностям СУБД - но зачем увеличивать размер отдельной записи полями, которые чаще всего не нужны?
Так что скорее таблицы вида
id_вопроса; текст вопроса
id_персонажа; название
id_вопроса; id_персонажа; число ответивших "Да"; число ответивших "нет"
Так что скорее таблицы вида
id_вопроса; текст вопроса
id_персонажа; название
id_вопроса; id_персонажа; число ответивших "Да"; число ответивших "нет"
Для понимания проще построчное хранение, нагляднее. Потом, если человек разберется в алгоритме, вариант хранения подберет. А так то да, поднял меня из мертвых. Давно ничего не писал. ))
Я чего пост написал вообще
Пришла идея алгоритма на подобии Акинатора,но который не персонажей угадывает,а сможет поставить диагноз,пусть и примерно(а возможно и намного точнее нынешних врачей) и уж точно лучше интернет оветчиков типа на мейл.ру
Сам фармацевт,но как прогер кодер-я профан
Пришла идея алгоритма на подобии Акинатора,но который не персонажей угадывает,а сможет поставить диагноз,пусть и примерно(а возможно и намного точнее нынешних врачей) и уж точно лучше интернет оветчиков типа на мейл.ру
Сам фармацевт,но как прогер кодер-я профан
Экспертные системы. В принципе, давно существуют, но широкого применения пока вроде не нашли (по крайней мере - в чистом виде они).
Но есть и немалое число недостатков (в основном - связанных с нестандартными ситуациями). Так что поточнее основной массы советчиков, но рекомендации "вали к врачу" не отменяет (хотя, я так думаю - об этом и речи е было :-) )
Но есть и немалое число недостатков (в основном - связанных с нестандартными ситуациями). Так что поточнее основной массы советчиков, но рекомендации "вали к врачу" не отменяет (хотя, я так думаю - об этом и речи е было :-) )
На мой взгляд, с этой идей только побаловаться можно. Что-то серьезное - врятли.
Копипаст из http://www.old-games.ru/forum/showthread.php?t=58360
Игра не моя, переписывал на GWBasic по памяти из "Науки и жизни". Претендует на звание самой короткой. Играть лучше толпой. В институте даже как-то втюхал ее под видом экспертной системы. Может использоваться при построении БД для уточнения критериев классификации сущностей:
Код:
10 OPTION BASE 1: DIM D$(1025): D$(1)="ЭТО КОТ": I=1: ON ERROR GOTO 80
20 PRINT D$(I);: INPUT O$: O$=LEFT$(O$,1)
30 IF I"" GOTO 70
40 IF O$="Д" OR O$="д" THEN PRINT "УРРА-А!": I=1: GOTO 20
50 D$(I*2+1)=D$(I): INPUT "А КТО ЭТО";O$: D$(I*2)="ЭТО "+O$
60 INPUT "ЧЕМ ОТЛИЧАЕТСЯ";D$(I): I=1: GOTO 20
70 IF O$="Д" OR O$="д" THEN I=I*2: GOTO 20: ELSE I=I*2+1: GOTO 20
80 PRINT "НЕ ХВАТАЕТ МОЗГОВ!": END
Игра не моя, переписывал на GWBasic по памяти из "Науки и жизни". Претендует на звание самой короткой. Играть лучше толпой. В институте даже как-то втюхал ее под видом экспертной системы. Может использоваться при построении БД для уточнения критериев классификации сущностей:
Код:
10 OPTION BASE 1: DIM D$(1025): D$(1)="ЭТО КОТ": I=1: ON ERROR GOTO 80
20 PRINT D$(I);: INPUT O$: O$=LEFT$(O$,1)
30 IF I"" GOTO 70
40 IF O$="Д" OR O$="д" THEN PRINT "УРРА-А!": I=1: GOTO 20
50 D$(I*2+1)=D$(I): INPUT "А КТО ЭТО";O$: D$(I*2)="ЭТО "+O$
60 INPUT "ЧЕМ ОТЛИЧАЕТСЯ";D$(I): I=1: GOTO 20
70 IF O$="Д" OR O$="д" THEN I=I*2: GOTO 20: ELSE I=I*2+1: GOTO 20
80 PRINT "НЕ ХВАТАЕТ МОЗГОВ!": END
Сам алгоритм у него довольно прост, но это компенсируется с лихвой огромным количеством данных. Общая идеологий механизма элементарна: если у тебя есть море параметров, то этого хватит, чтобы идентифицировать что угодно.
Представь, что тебе надо идентифицировать всех людей на планете, не давая им при этом уникальные идентификационные номера (как в паспортах). И теперь вместо того, чтобы говорить гос. службам свой номер паспорта, ты диктуешь им кучу своих биометрических параметров: цвет глаз, рост, вес, возраст, длину волос, размер носа, толщину губ, расстояние между бровями, угол линии лба... (предположим, что при изменении параметра надо его "перерегистрировать" на паспортном столе) На самом деле, такой подход за вычетом его адовой сложности был бы рабочим, что легко понять: хрен ты найдешь людей с одинаковой внешностью (не считая близнецов). Примерно так и устроен их алгоритм: если это не один и тот же персонаж, а два разных, то они хоть чем-то да отличаются друг от друга, поэтому при хорошем наборе данных не нужно никаких умных механизмов, чтобы это вычислить.
Представь, что тебе надо идентифицировать всех людей на планете, не давая им при этом уникальные идентификационные номера (как в паспортах). И теперь вместо того, чтобы говорить гос. службам свой номер паспорта, ты диктуешь им кучу своих биометрических параметров: цвет глаз, рост, вес, возраст, длину волос, размер носа, толщину губ, расстояние между бровями, угол линии лба... (предположим, что при изменении параметра надо его "перерегистрировать" на паспортном столе) На самом деле, такой подход за вычетом его адовой сложности был бы рабочим, что легко понять: хрен ты найдешь людей с одинаковой внешностью (не считая близнецов). Примерно так и устроен их алгоритм: если это не один и тот же персонаж, а два разных, то они хоть чем-то да отличаются друг от друга, поэтому при хорошем наборе данных не нужно никаких умных механизмов, чтобы это вычислить.
В свете последних событий...
нет, лол
просто посмотри короткие примеры вокруг
игра просто задает вопросы, ответ на которые дает то или иное направление.
и вопросы и ответы дают сами игроки.
изначально можно вообще вписать в БД один ответ
игра("животные", например) будет спрашивать "это собака?"
скорее всего играющий загадал не собаку,
поэтому игра спросит что он загадал ("дельфина")
и спросит, как отличить собаку от дельфина - ("живет в море")
отлично, теперь у игры есть один вопрос "это животной живет в море?" и два варианта - для "да" и для "нет"
т.е. следующий игрок загадавший и ответивший - добавит вопрос для ветки "да" или "нет", и так далее ...
понятное дело что можно усложнить, и можно отмодерировать чтобы игроки не врали, но суть игры очень проста.
просто посмотри короткие примеры вокруг
игра просто задает вопросы, ответ на которые дает то или иное направление.
и вопросы и ответы дают сами игроки.
изначально можно вообще вписать в БД один ответ
игра("животные", например) будет спрашивать "это собака?"
скорее всего играющий загадал не собаку,
поэтому игра спросит что он загадал ("дельфина")
и спросит, как отличить собаку от дельфина - ("живет в море")
отлично, теперь у игры есть один вопрос "это животной живет в море?" и два варианта - для "да" и для "нет"
т.е. следующий игрок загадавший и ответивший - добавит вопрос для ветки "да" или "нет", и так далее ...
понятное дело что можно усложнить, и можно отмодерировать чтобы игроки не врали, но суть игры очень проста.
А я бы на структуру данных посмотрел...
Меня (как профана в программировании) интересовала попытка устроить программу типа Акинатора не как базу данных. А как метапоисковик с поиском по предыдущим результатам. Т.е. в интернете наверняка уже есть данные различных личностей и персонажей, наверняка не все в виде таблиц, поэтому придется использовать поиск по тексту. Насколько это реализуемо?
Помогите, "тыж программисты", уменьшить уровень моей безграмотности.
Помогите, "тыж программисты", уменьшить уровень моей безграмотности.
Софтина вообще простая, как и алгоритм.
Я так это вижу:
1) БД - 3 таблицы: персонажи (2 поля id и имя), свойства (2 поля id, связаный вопрос), связи (3 поля id, id персонажа, id свойства).
Свзаные вопросы должны быть построены так что бы ответ был ди или нет.
2) Алгоритм: сортирум связи по количеству свойств (задаем связаный вопрос). На основании ответа расширяем фильтр поиска (ищем по id). Производим поиск по составному фильтру по id до тех пор пока id персонажа не будет уникальным. Уникальный id и даст имя персонажа. Если фильтр содержит скажем 15 значений сдаемся и просим назвать персонажа - результат заносим в таблицу персонажей, а набор фильтров в таблицу связей. Вот и все.
3) Исходные данные, на самом деле главный гемор это набор свойств тем не менее 100 параметров будет более чем достаточно. Ну и 2 - 3 персонажа и связей предустановить.
Шарим в web и через некоторое время БД будет наполнена данными от самих пользователей.
Я так это вижу:
1) БД - 3 таблицы: персонажи (2 поля id и имя), свойства (2 поля id, связаный вопрос), связи (3 поля id, id персонажа, id свойства).
Свзаные вопросы должны быть построены так что бы ответ был ди или нет.
2) Алгоритм: сортирум связи по количеству свойств (задаем связаный вопрос). На основании ответа расширяем фильтр поиска (ищем по id). Производим поиск по составному фильтру по id до тех пор пока id персонажа не будет уникальным. Уникальный id и даст имя персонажа. Если фильтр содержит скажем 15 значений сдаемся и просим назвать персонажа - результат заносим в таблицу персонажей, а набор фильтров в таблицу связей. Вот и все.
3) Исходные данные, на самом деле главный гемор это набор свойств тем не менее 100 параметров будет более чем достаточно. Ну и 2 - 3 персонажа и связей предустановить.
Шарим в web и через некоторое время БД будет наполнена данными от самих пользователей.
"Одним из первых примеров саморепродуцирующихся программ явилась игровая программа с названием «Animal». По правилам игры человек должен загадать животное, а программа, задавая ему вопросы, должна это животное отгадать. В программу была заложена возможность обучения: если она не могла отгадать животное, то человек должен был ввести в нее вопрос, который помог бы программе сделать это. При этом программа модифицировалась и копировала себя в один из подкаталогов файловой системы."
эта игра еще и один из первых вирусов)
эта игра еще и один из первых вирусов)
