IPB
ЛогинПароль:

> Игра Калах, самообучающийся алгоритм ИИ
сообщение
Сообщение #1


Уникум
*******

Группа: Пользователи
Сообщений: 6 823
Пол: Мужской
Реальное имя: Лопáрь (Андрей)

Репутация: -  159  +


Всем привет,
сыграем в Калах? smile.gif
Эта игра меня давно занимает, причем с определенной точки зрения. Но сначала о том, что это за игра (не все, может, знакомы). Она очень древняя, пришла (как чуть ли не все игры) с Востока. Известна также под названием Ман-Кала, а также иногда пишут два "л": Каллах. Играют двое на специальной доске камнями. Доска имеет два ряда лунок (по шесть), а по бокам две большие лунки (именно они и называются "калах"). Доска ставится между двумя игроками. Ближайший ко мне ряд лунок - мой, другой - противника. Правый калах - мой, левый - противника.
Прикрепленное изображение
В начале игры во всех лунках (кроме калахов) лежит по шесть камней. Ход заключается в том, что игрок берет все камни из любой своей лунки (не из калаха) и раскладывает их по одному в направлении против часовой стрелки, начиная с ближайшей правой, и тут уже включая свой калах - но не калах противника, который пропускается.

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

Игра заканчивается либо когда в одном из калахов скопилось более половины всех камней (то есть больше 36), и тогда этот игрок выиграл, либо когда в лунках игрока кончились камни, и тогда он проиграл. Вот, кажется, и все правила. На рисунке изображено состояние после моего хода лункой №1. Сейчас снова мой ход.

Игра продавалась у нас, наверняка продается и сейчас. Играть интересно, ситуация на доске меняется иногда молниеносно, предсказать игру на пару ходов очень нелегко. Разумеется, есть и программные реализации (поройтесь в сети). В свое время все сотрудники нашего головного предприятия по производству ЭВМ были страстно увлечены ее электронной версией, проводились соревнования.. smile.gif Понятно, что предсказание хода в данном случае трудно для человека, но не для машины - сбивает с толку необходимость постоянно вести подсчеты, но граф этой игры ветвится не так сильно, так как всякий раз есть не более шести возможных ходов.

Вот именно эта особенность (малое количество ходов) и привлекла меня. Теперь расскажу о другом..
Когда-то давно я прочитал в книжке моего кумира Мартина Гарднера, как сделать машину для игры крестики-нолики. Ничего удивительного, если не сказать, что это было написано где-то в 60-е годы.. smile.gif Машину предлагалось делать из.. спичечных коробков! Меня заинтересовал принцип. А принцип состоял в следующем..

По сути, это был метод кнута и пряника. Нужно было записывать все комбинации, возникающие в игре, зарисовывать их каждую на отдельном коробке. При игре 3х3 это возможно smile.gif. Но не только каждой комбинации соответствовал отдельный коробок, но и каждому возможному в ней ходу тоже. Перед процессом обучения "машины" в каждый коробок нужно было положить по три горошины. Потом нужно было несколько раз сыграть самому (с кем-нить) в эту игру, при каждом ходе фиксируя возникшие комбинации. В конце партии, когда результат (кто выиграл) уже ясен, нужно во все коробки, на которых обозначены ходы выигравшего игрока, должить по горошине. Из всех же тех, которые соответствуют ходам проигравшего игрока - наоборот, вынуть горошину. Я сейчас не ручаюсь за точность повторения алгоритма, но принцип тот.

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

Не правда ли, все просто? Если мое объяснение вам таковым не показалось, найдите книжку Гарднера smile.gif.

Итак, я решил применить тот же принцип к Калаху. Это было давно, жутко давно - когда я впервые дорвался до персоналки. Тогда я это сделал на Бейсике. И ведь работало! Конечно, полный вариант мне был тогда не по зубам - не хватало ни памяти, ни производительности - но я извернулся. Придумал калах-3. Как вы, может, уже догадались, это вариант игры с тремя лунками, в каждой из которых в начале лежит 3 камня.

Да, не очень интересно.. Именно поэтому я помнил это и ждал момента, когда машины подрастут. Тогда я делал все на машине с памятью 512 КБ (аналог DEC Pro 350, кажется). Нынешние машины имеют памяти примерно на три порядка больше (а моя и вообще в 4000 раз). Так что я решил, что момент настал. И сделал все заново. Теперь на Паскале (с прицелом, чтоб выложить сюда smile.gif).

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

Собсно, а что там говорить? Разберетесь.. Это Калах-4 (легко превращающийся в Калах-5,6 и т.д. заменой одной констаныт). Интерфейс крайне уродский, но не хочу доводить его до ума в текстовой версии. Во время игры можно только вводить номер лунки. Между играми можно кое-что еще (хелп по нажатии h). Советую переходить в режим картинки (буква p). Код непричесанный, невычищенный - короче, рабочий, не судите строго. Извиняюсь за отсутствие комментариев. Если будет интерес - снабжу.

Enjoy, как грится! smile.gif И - жду ваших коментариев.. улучшений.. и т.п.

Да, забыл сказать.. Программа сама по себе страшно тупая - она ходит случайным образом. Чтоб ей поумнеть, нужен файл с накопленными данными. Файл у меня есть (для Калах-4), он весит почти 30 МБ - но вы можете сделать его и сами.

Самый интересный вопрос - оценка памяти, необходимой для обучения Калах-5 и 6. Я пока не соображу, как правильно оценить. Если верно, что каждый новый уровень требует примерно на 2.5-3 порядка большей памяти (как при переходе от 3 к 4), то для Калаха-5 потребуется больше 10 ГБ.. И такого количества операционки у меня пока нету.. Но мне кажется, что множитель не постоянен, он растет, но не спец по этим вопросам..
Итак - ваши соображения, господа?.. smile.gif

Старый вариант программы удален! Новый в посте №16


--------------------
я - ветер, я северный холодный ветер
я час расставанья, я год возвращенья домой
 Оффлайн  Профиль  PM 
 К началу страницы 
+ Ответить 
 
 Ответить  Открыть новую тему 
Ответов
сообщение
Сообщение #2


Новичок
*

Группа: Пользователи
Сообщений: 11
Пол: Женский
Реальное имя: Ольга

Репутация: -  0  +


Lapp, все верно, для курсовой работы! ну и самой хочется ее понять, эту программу. smile.gif
Цитата
Это Калах-4 (легко превращающийся в Калах-5,6 и т.д. заменой одной констант)


в графическом режиме при Калах-6 одна лунка выезжает на другую..
 Оффлайн  Профиль  PM 
 К началу страницы 
+ Ответить 
сообщение
Сообщение #3


Уникум
*******

Группа: Пользователи
Сообщений: 6 823
Пол: Мужской
Реальное имя: Лопáрь (Андрей)

Репутация: -  159  +


Цитата(cameron @ 15.12.2009 17:54) *
Lapp, все верно, для курсовой работы! ну и самой хочется ее понять, эту программу. smile.gif
Вторая часть фразы мне нравится больше, но и первая нормально, если серьезный подход smile.gif.

Цитата
в графическом режиме при Калах-6 одна лунка выезжает на другую..
Что ты имеешь в виду под графическим режимом? Этот режим называется у меня в программе "картинка", а графики тут и в помине нет..

Я кое-что сделал, что хотел, но далеко не все. Решил, что хватит тебя (Cameron) мучить, и хоть что-то надо выложить. Я сильно переделал интерфейс - как вывод, так и ввод. При этом больше внимания уделил все же выводу, а ввод остался довольно запутанным, там легко прогу сбить с толку. Картинка получила настраиваемые параметры (см. код). Команды тоже стали немного разумнее, но все же не совсем )).

При запуске выдается "меню". Можно нажимать буковки..

p - play - играть. Если есть база и ход найден в ней - то программа играет "разумно"; нет - случайно.
t - train - тренироваться. Программа играет со случайным процессом, при этом накапливается БД.
r - read - читать БД (если она есть на диске).
w - write - записать накопленную БД. Осторожно: БД затирается без предупреждения.
q - quit - выйти из игры.

В процессе игры теперь не нужно жать энтер - ход делается по сразу по нажатии клавиши. Можно выйти по нажатии Q.

Теперь про обучение.. Для него достаточно в главном меню нажать T. Если хочется посмотреть, как продвигается процесс, нажми N - она будет выводить количество сыгранных партий. Чтобы убрать это - снова N (эта опция не отмесена в меню).

Советую сначала поиграть в рангом 3. Этот случай обучается очень быстро. Запиши накопленную базу и потом считывай.

При ранге 4 обучение тоже довольно быстрое, а игра уже начинает приобретать интерес. Примерный размер базы данных - десятки мегабайт (типа 30-40МБ), что терпимо.

При ранге 5 обучение занимает порядка суток и не заканчивается, поскольку вылетает по памяти (примерно после 3 миллионов сыгранных игр). Размер БД на диске - под 1 ГБ. Полагаю, полный размер потребует нескольких ГБ (может, 4-6), а обучение будет продолжаться не меньше недели.

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

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

Уфф... Разберешься? (Показать/Скрыть)

Любители попридираться могут feel free мордовать меня. Только я вряд ли смогу ответить на большинство вопросов )).


--------------------
я - ветер, я северный холодный ветер
я час расставанья, я год возвращенья домой
 Оффлайн  Профиль  PM 
 К началу страницы 
+ Ответить 
сообщение
Сообщение #4


Новичок
*

Группа: Пользователи
Сообщений: 11
Пол: Женский
Реальное имя: Ольга

Репутация: -  0  +


Lapp, спасибо, что ответил скоро!
сейчас буду разбираться в программе! пока, понятно, воопросов нет. Одни только благодарности smile.gif
 Оффлайн  Профиль  PM 
 К началу страницы 
+ Ответить 
сообщение
Сообщение #5


Уникум
*******

Группа: Пользователи
Сообщений: 6 823
Пол: Мужской
Реальное имя: Лопáрь (Андрей)

Репутация: -  159  +


Цитата(cameron @ 21.12.2009 21:13) *
Lapp, спасибо, что ответил скоро!
сейчас буду разбираться в программе! пока, понятно, воопросов нет. Одни только благодарности smile.gif
Да какие там благодарности, я же так и не сделал пояснений к процедурам.. В принципе, там названия говорящие, но в основном я надеюсь, что ты будешь спрашивать поконкретнее - я отвечу.

Еще про ранг 6 (и частично 5).. То, что я написал выше, требует дополнения.
БД уже достигает таких размеров, что она не может поместиться в оперативную память и, ссответственно, не должна записываться одним файлом. Раз так, нужно для каждого хода считывать соответствующий кусок с диска. И значит, эти куски должны быть достаточно маленькими, чтоб чтение происходило быстро (не больше 1 МБ). Далее, при обучении надо устроить так, чтобы добавление записи в один файл не влекло за собой переписывания остатка БД (то есть формат должен быть достаточно свободным). И все равно обучение замедлится dramatically, в сотни раз, думаю [вставлено позже: и тогда месяцы превратятся в десятки лет. Наверное, это однозначно указывает на необходимость использования БД, а не просто файлов]. Проблема в том, что существено невозможно придумать организацию БД, где более употребительные ходы хранились бы "ближе", а менее - "подальше". Большинство из этих проблем решаются, если использовать реальную БД (типа MySQL), но мне не хотелось бы - можно обойтись и без нее. Короче гря, ЭТА реализация совершенно не годится для ранга 6 (да и для ранга 5 тоже уже не совсем).

Я лелею надежду все переписать совсем, полностью переделав БД. Я еще не вполне определился со средствами.. Сама по себе игра будет иметь web-интерфейс (скорее всего без излишеств на JS). Идея простая: выкладывается необученная прога, обучение проходит а)при игре пользователей; б)случайным фоновым процессом. И вот там выбор будет такой:

1. писать проги для доступа к файлам на Паскале или Си, вызываемые из PHP (либо прямо cgi);
2. писать доступ к файлам непосредственно на PHP;
3. использовать стандартную БД.

Пока не могу выбрать. Приглашаю всех к дискуссии на эту тему. Также, если кто поможет (Cameron?)).. smile.gif


--------------------
я - ветер, я северный холодный ветер
я час расставанья, я год возвращенья домой
 Оффлайн  Профиль  PM 
 К началу страницы 
+ Ответить 
сообщение
Сообщение #6


Гуру
*****

Группа: Пользователи
Сообщений: 1 168
Пол: Мужской
Реальное имя: Сергей Андрианов

Репутация: -  28  +


Цитата(Lapp @ 22.12.2009 6:00) *
Большинство из этих проблем решаются, если использовать реальную БД (типа MySQL), но мне не хотелось бы - можно обойтись и без нее.
...
Пока не могу выбрать. Приглашаю всех к дискуссии на эту тему. Также, если кто поможет (Cameron?)).. smile.gif
Стандартная БД - это ОЧЕНЬ медленно. Впрочем, если для составления базы будут использованы переборные алгоритмы с большой глубиной, то это несущественно. А если живые игроки - тем более.
Кстати, нет ли возможности реализовать базу в виде дерева?
 Оффлайн  Профиль  PM 
 К началу страницы 
+ Ответить 
сообщение
Сообщение #7


Уникум
*******

Группа: Пользователи
Сообщений: 6 823
Пол: Мужской
Реальное имя: Лопáрь (Андрей)

Репутация: -  159  +


Цитата(cameron @ 22.12.2009 20:30) *
плохо поняла назначение функций HexDig, AddRec, FindRec (что-то добавить, найти... )
smile.gif учи латынь (и/или хотя бы английский))
Hex, hexadecimal - шестнадцатиричный
Dig, digit - цифра
HexDig - шестнадцатиричная цифра (1,2,...,9,A,B,..,F)
Rec, record - запись
AddRec - добавить запись
FindRec - найти запись

Цитата(andriano @ 22.12.2009 22:22) *
Стандартная БД - это ОЧЕНЬ медленно. Впрочем, если для составления базы будут использованы переборные алгоритмы с большой глубиной, то это несущественно. А если живые игроки - тем более.
Вряд ли медленнее, чем чтение/запись мегабайтного файла (дальше мельчить стремно).

Цитата
Кстати, нет ли возможности реализовать базу в виде дерева?
Так она и есть деревянная! smile.gif По начальным ходам в блоках. Беда в том, что частые и полезные ходы существенно перемешаны с редкими и бесполезными..


--------------------
я - ветер, я северный холодный ветер
я час расставанья, я год возвращенья домой
 Оффлайн  Профиль  PM 
 К началу страницы 
+ Ответить 
сообщение
Сообщение #8


Гуру
*****

Группа: Пользователи
Сообщений: 1 168
Пол: Мужской
Реальное имя: Сергей Андрианов

Репутация: -  28  +


Цитата(Lapp @ 23.12.2009 6:11) *
Вряд ли медленнее, чем чтение/запись мегабайтного файла (дальше мельчить стремно).
Давай сравнивать сравнимое.
1 вариант: файл с двоичным представлением наших данных собственной оптимизированной под задачу структуры.
2 вариант: стандартная база (SQL), содержащая тот же набор данных и связей, что и файл 1.
Соображения:
- если объем файла один считать за 1.0, то объем базы SQL будет существенно больше 1.0, причем, возможно, в разы.
- если объем файла один будет "на пределе" помещаться в ОЗУ, то, очевидно, SQL-база уже неизбежно будет, хотя бы частично, размещаться на диске. Откуда и разница во времени доступаю.
- если ни то ни другое в ОЗУ не помещается, то для файла 1 бОльший процент его может содержаться в ОЗУ, а, следовательно, % попаданий без обмена с диском будет выше.
- если мы сумели представить структуру файла 1 в виде дерева, то поиск по нему будет в худшем случае как O(log(N)), а вот насчет SQL-базы это совершенно неочевидно.
- если длина записи строго фиксирована, можно свести поиск к О(1), а для базы - сомнительно.
- если нам НЕ требуется обеспечить устойчивость собственного формата 1 к одновременному проведению транзакций с одним и тем же элементом, сама логика работы базы существенно упроцается по сревнению с любой стандартной реализацией, что само по себе приведет к экономии времени.
Цитата
Так она и есть деревянная! smile.gif По начальным ходам в блоках. Беда в том, что частые и полезные ходы существенно перемешаны с редкими и бесполезными..
Сначала отмечу, что при хранении данных на жестком диске, действительно, оптимальной с точки зрения скорости доступа величиной является 1-2 Мбайта.

Коль скоро у нас все равно древовидная структура, не целесообразно было бы предусмотреть точно такую же организацию блоков. Например, первый блок хранит полную информацию обо всех партиях, скажем, на глубину 5-6 полуходов и ссылается на блоки следующего уровня (скажем, полуходы с 7 по 13), а те, в свою очередь, на блоки полуходов следующего уровня.
По моим оценкам продолжительность партии где-то порядка 50 коротких ходов (т.е. однократных раскладываний камней. Полуход состоит из одного или нескольких коротких ходов, делаемых подряд одним игроком), т.е. за всю партию нам потребуется вряд ли более 8 блоков (для каждого из игроков, если они играют друг с другом).
 Оффлайн  Профиль  PM 
 К началу страницы 
+ Ответить 
сообщение
Сообщение #9


Уникум
*******

Группа: Пользователи
Сообщений: 6 823
Пол: Мужской
Реальное имя: Лопáрь (Андрей)

Репутация: -  159  +


Цитата(andriano @ 23.12.2009 11:30) *
- если объем файла один считать за 1.0, то объем базы SQL будет существенно больше 1.0, причем, возможно, в разы.
Думаю, это верно, даже если не считать за 1.0 smile.gif)))

Цитата
- если объем файла один будет "на пределе" помещаться в ОЗУ, то, очевидно, SQL-база уже неизбежно будет, хотя бы частично, размещаться на диске. Откуда и разница во времени доступаю.
Этот случай неинтересен. Калах-5 можно поместить в ОЗУ, если оно не менее 16 ГБ и код скомпилирован под 64 бит. Но калах-5 не заслуживает таких жертв..

Цитата
- если ни то ни другое в ОЗУ не помещается, то для файла 1 бОльший процент его может содержаться в ОЗУ, а, следовательно, % попаданий без обмена с диском будет выше.
Этим можно пренебречь. При размере БД около 500 ГБ и памяти под задачу порядка 1 ГБ вероятность попадания - доли процента.

Цитата
- если мы сумели представить структуру файла 1 в виде дерева, то поиск по нему будет в худшем случае как O(log(N)), а вот насчет SQL-базы это совершенно неочевидно.
Я где-то в глубине души надеюсь, что БД оптимизирована.. Конечно, универсальная оптимизация далека от специальной для задачи, но я повторяю: тут обычный двоичный поиск.

Цитата
- если длина записи строго фиксирована, можно свести поиск к О(1), а для базы - сомнительно.
Да, фиксирована (если не ужимать). Это должно сыграть.

Цитата
- если нам НЕ требуется обеспечить устойчивость собственного формата 1 к одновременному проведению транзакций с одним и тем же элементом, сама логика работы базы существенно упроцается по сревнению с любой стандартной реализацией, что само по себе приведет к экономии времени.
Вот тут не совсем ясно.. Хотя, если сделать "подбазу", которая будет обучаться, скажем, в течении дня/часа, и раз в день/час их синхронизировать - то можно оптимизировать и этот момент.

Цитата
Сначала отмечу, что при хранении данных на жестком диске, действительно, оптимальной с точки зрения скорости доступа величиной является 1-2 Мбайта.
Я не вполне согласен.. К сожалению, дисковый кэш тут бесполезен, скорее даже вреден. Думаю, что дробление вплоть до размера блока на диске должно ускорять процесс (хотя и несильно в конце).

Цитата
Коль скоро у нас все равно древовидная структура, не целесообразно было бы предусмотреть точно такую же организацию блоков. Например, первый блок хранит полную информацию обо всех партиях, скажем, на глубину 5-6 полуходов и ссылается на блоки следующего уровня (скажем, полуходы с 7 по 13), а те, в свою очередь, на блоки полуходов следующего уровня.
Сергей, ты что-то путаешь. В рассматриваемом методе нет понятия ни ходов, ни полуходов, ни глубины. Есть ситуация на доске, и она может возникнуть когда угодно. Все остальное (если оно возможно) следует рассматривать как усовершенствование метода и подробно анализировать не впопыхах.

Цитата
По моим оценкам продолжительность партии где-то порядка 50 коротких ходов (т.е. однократных раскладываний камней. Полуход состоит из одного или нескольких коротких ходов, делаемых подряд одним игроком), т.е. за всю партию нам потребуется вряд ли более 8 блоков (для каждого из игроков, если они играют друг с другом).
Перепроверь свои оценки. Ты не учитываешь сильнейшего ветвления (которое, совственно, и приводит к тому размеру ДБ, который рассматривался выше). Если бы все было так просто!.. smile.gif))


--------------------
я - ветер, я северный холодный ветер
я час расставанья, я год возвращенья домой
 Оффлайн  Профиль  PM 
 К началу страницы 
+ Ответить 

Сообщений в этой теме
lapp   Игра Калах   6.12.2006 19:27
Archon   Знаю эту игру! На нокиа 3310 она была среди ст…   11.12.2006 2:54
Творец   Хотелось бы посмотреть на комментарии кода проги …   13.05.2007 1:05
Lapp   посмотреть на комментарии кода проги Творец, обя…   13.05.2007 2:50
Творец   Творец, обязательно сделаю. На вскидку - в ближа…   13.05.2007 22:25
Творец   Lapp пока хотя бы примерно что к чему поясни пожал…   21.05.2007 0:37
Lapp   Lapp пока хотя бы примерно что к чему поясни пожа…   23.05.2007 14:59
Творец   Я посмотрел прогу :), и решил, что писать коммент…   28.05.2007 0:06
RathaR   Популярная это всётаки игрушка :) Описали и алгори…   11.10.2009 20:34
Lapp   Популярная это всётаки игрушка :) Описали и алгори…   12.10.2009 10:56
cameron   Lapp, огромное спасибо Вам за написание сей програ…   11.12.2009 2:02
Lapp   очень интересует общий принцип работы и назначение…   11.12.2009 15:07
Lapp   Выполняя обещание, я пересмотрел программу, и.. н…   14.12.2009 10:35
RathaR   Lapp, не так давно, я втечении примерно двух недел…   14.12.2009 23:52
cameron   Lapp, все верно, для курсовой работы! ну и сам…   15.12.2009 21:54
Lapp   Lapp, все верно, для курсовой работы! ну и сам…   21.12.2009 16:47
cameron   Lapp, спасибо, что ответил скоро! сейчас буду …   22.12.2009 1:13
Lapp   [b]Lapp, спасибо, что ответил скоро! сейчас бу…   22.12.2009 10:00
andriano   Большинство из этих проблем решаются, если использ…   23.12.2009 2:22
Lapp   плохо поняла назначение функций HexDig, AddRec, Fi…   23.12.2009 10:11
andriano   Вряд ли медленнее, чем чтение/запись мегабайтного …   23.12.2009 15:30
Lapp   - если объем файла один считать за 1.0, то объем б…   23.12.2009 17:01
andriano   Этим можно пренебречь. При размере БД около 500 Г…   23.12.2009 17:42
cameron   плохо поняла назначение функций HexDig, AddRec, Fi…   23.12.2009 0:30
Гость   Lapp, можешь, пожалуйста, обьяснить мне роль масси…   10.01.2010 17:02
cameron   Lapp Каково назначение у процедуры Teach? С ее пом…   10.01.2010 22:47
Lapp   Lapp, можешь, пожалуйста, обьяснить мне роль масси…   11.01.2010 4:49
cameron   Lapp благодарю, теперь понятно, учитывая и твой от…   11.01.2010 23:36
Гость   да, спасибо, очень доходчиво объяснил. У меня еще…   12.01.2010 1:56
Lapp   что за переменная р? а массивы tBoard (лунки и 2 …   12.01.2010 3:33
Lapp   Гм. Псмотрю.Посмотрел.. Что ж ни у кого язык не…   12.01.2010 4:51
Lapp   а массивы tBoard (лунки и 2 калаха?), tKalahНет. …   12.01.2010 13:37
Гость   пардон, tBoard ты объяснил.   12.01.2010 2:02
cameron   честно говоря, не знала что на форуме можно писат…   12.01.2010 23:19
cameron   переменная Num: boolean? ll: longint? о каких лин…   12.01.2010 23:56
Lapp   не знала что на форуме можно писать пост без входа…   13.01.2010 10:43
cameron   преподаватель еще не видел программы, вопросы мои…   13.01.2010 18:23
Lapp   преподаватель еще не видел программы, вопросы мои.…   13.01.2010 18:41
cameron   на счет записей в БД. Store[NStore]^.Len:=0 - тут…   13.01.2010 19:29
Lapp   Store^.Len:=0 - тут мы создаем пустой блокДа, имен…   14.01.2010 10:08
Lapp   Как хороши, как свежи были розы.. (С)   3.02.2010 5:50


 Ответить  Открыть новую тему 
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 





- Текстовая версия 29.03.2024 11:40
500Gb HDD, 6Gb RAM, 2 Cores, 7 EUR в месяц — такие хостинги правда бывают
Связь с администрацией: bu_gen в домене octagram.name