Сайт stolyarov.info переехал на новый сервер (см. stolyarov.info). Версия, которую вы видите, оставлена работать на неопределённое (но вряд ли продолжительное) время на случай выявления ошибок при переносе контента.
Если вы видите ЭТО по адресу stolyarov.info или www.stolyarov.info — это значит, что ваш DNS-сервер всё ещё отдаёт старую информацию по этим адресам.
Между делом, из рукописи задачника буднично и незаметно исчезла последняя пометка «к доработке». Обложки ещё нет, но до конца всероссийского запоя всё равно ничего не произойдёт, а вот дальше надеюсь всё сделать настолько быстро, насколько получится.
Задачник
Работая с книгой, я обнаружил, что довольно быстро забываю материал. И, например, над такой задачей, как построение алмаза из звёздочек в консоли по заданной высоте, приходилось думать снова, вспоминая алгоритм. Поэтому тексты всех программ стал выписывать в отдельный файл с кратким описанием типа "добавить в программу mult контроль ввода символов и вывод ошибок". Теперь после каждой главы могу снова воспроизвести все задачи, и материал усваивается гораздо лучше.
На мой взгляд, отсутствие в конце главы контрольных вопросов и задач именно из текста (предполагаю, что в задачнике будут совсем другие), является минусом книги. Потому что адекватно оценить качество запоминания не выходит, и процесс превращается в чтение художественной литературы. Даже с учётом написания кода по ходу чтения.
построение
построение алмаза из звёздочек [...] вспоминая алгоритм.
С одной стороны, никакого алгоритма там и близко нет, вас кто-то обманул. Точнее, с формальной точки зрения вообще любая программа есть запись алгоритма, но в практическом смысле вести речь об "алгоритмах" в применении к таким простым задачам где-то даже смешно.
С другой стороны, если такая задача заставляет "снова думать", то это же хорошо :-) Обычно задачи — штука одноразовая, решил — и нет её; а тут вы одну задачу заставили послужить вам дважды.
А с третьей... э... что-то простовата задачка-то. Если вы совсем недавно программирование изучаете, то в принципе ладно, но если, скажем, через два-три месяца такие задачи всё ещё заставляют задумываться, то, возможно, это просто не ваше. Сама ведь эта задача вообще ни о чём, в книжке я её привёл просто чтобы показать, зачем нужны процедуры. А предшествующие задачи на "рисование звёздочками" — чтобы показать циклы, в том числе вложенные. То есть это даже не задачи, это просто иллюстрации.
могу снова воспроизвести все задачи
но зачем?
предполагаю, что в задачнике будут совсем другие
В задачнике будут именно что задачи под каждую часть учебника, и если говорить про звёздочки, то там имеется целая пачка задач на это дело — я прекрасно знаю, как некоторым из обучаемых тяжко закрепить первичные понятия, те самые циклы и процедуры (вот только те, кому это тяжко, программистами потом обычно не становятся, но это ладно).
Проблема тут несколько в другом. "Большие" (на самом деле маленькие, большие они только в сравнении с теми же "ромбиками") этюды в задачнике тоже есть, и если всё, что предложено к очередной части учебника, успешно прорешать, можно считать, что "материал" вы "освоили". Просто между "освоить материал" и "стать программистом" имеет место, я бы сказал, изрядный разрыв.
отсутствие в конце главы контрольных вопросов и задач
Книга и так получилась огромная. Но основная причина даже не в этом; я изначально был уверен, что те, кому нужны задачи и контрольные вопросы (их я отождествлял с теми, кто программирование вымучивает, надеясь непонятно на что), не окажутся в числе читателей моей книги. Что я ошибался, стало понятно где-то через год после выхода первых томов, но перелопачивать всю книгу, добавляя к ней инфраструктуру для задач, указаний и ответов, мне показалось всё-таки чересчур. Издание задачника отдельной книжкой — это своего рода компромисс, я тем самым иду навстречу тем, кто пытается из моей книги извлечь для себя пользу совершенно не тем способом, который предполагал я сам как автор.
С нетерпением ждём
Ждем, надеемся :)
И большое спасибо, за книги и вообще.
Поздравляю!
Замечательная новость. =)
Ну вот тебе-то
Ну вот тебе-то он нафига? :-) Или ты кого-то учить по нему собираешься?
Как же, очень даже нужен =)
Задачки же бывают красивые и весёлые сами по себе -- что на них смотришь и радуешься просто от воображения возможных решений.
Плюс таки да -- посмотрю как устроен, может вынесу какие-то уроки о том, как строить уроки, а может даже и поучу кого-то по нему. =)
Популяризирова
Популяризировать будет :D
Лично мне не
Лично мне не нужен задачник, но как же хочется увидеть задачки оттуда, меня просто уносит куда-то :)
Вот например мой сборник задач по асму (как бы вы его оценили? что бы подошло для задачника?):
- сделать подпрограмму для печати десятичного целого [сделано]
- сделать подпрограмму для получения десятичного целого из stdin [сделано]
- создать игру змейка [сделано наполовину]
- создать игру жизнь, создать интерфейс командной строки, добавить возможность создания рандомной игры и создания начального состояния "жизни" игроком
- сделать подпрограмму для печати чисел с плавающей точкой [уже нетривиально, но возможно]
- создать калькулятор ПОЛИЗа
- создать менеджер памяти
- повторить функцию printf() из Си
- создать порядка 10 библиотек для облегчения работы на асме [сделано 3]
это ещё только половина
И ЭТО лучше чем, то что может предложить добрый дядя?
> - создать игру
> - создать игру жизнь, создать интерфейс командной строки, добавить возможность создания рандомной игры и создания начального состояния "жизни" игроком
Крайне, крайне хочу высокопроизводительную версию этой игры. Мне не хватает мощностей для моих задумок с нынешними реализациями
Не хватает
Не хватает реализаций на GPU?! Что ж это за задумки у вас...
На всякий случай: в поисковике "
life game gpu", вроде для всего хватает.Высокопроизводительную?
Боюсь, что существующие реализации обогнать по скорости будет сложно, всё же игра невероятно популярна среди программистов (символ хакеров намекает).
Кроме того, ассемблер -- это не про скорость, во всяком случае по большей части. Ассемблер необходим просто по факту того, что мы работаем с компьютерами -- суть ассемблера в контроле за низким уровнем -- и хотя таким контролем можно достичь ускорения программы, но это сложно в той же степени, что и современные компьютеры (будьте готовы оптимизировать код программы под кэш, конвейер, предсказания и прочее веселье).
Наконец -- а каковы ваши задумки, что существующих мощностей не хватает? Мне просто сложно представить, насколько сложное действо вы задумали, учитывая что проекты компьютера в жизни и жизни в жизни работают (по крайней мере у меня) с вполне впечатляющей скоростью.
Ема вы тут понаписали...
Ну, во-первых, мне надо поле прям огромное, 100K x 100K как минимум.
Во-вторых мне надо кучу различных примочек, как минимум копипаст конструкций и сохранение состояний каждого шага, как в машине Тьюринга, чтобы можно было возвратиться.
Ну и в третьих хорош был бы редактор расширений, где можно менять правила игры
> 100K x 100K>
> 100K x 100K
> сохранение состояний каждого шага
У вас цель AAA-игры или того гляди "современные" браузеры по уровню прожорливости перегнать?!
Нормально понаписал =)
Я вроде спрашивал про то зачем вам нужна такая реализация, а не что вам от неё надо...
Ну да ладно, про первое требование: поле в сто тысяч на сто тысяч -- это очень много. Положим каждая клетка хранится битом (очень оптимистично), тогда всё равно получится чуть больше гигабайта. Обрабатывать этот гигабайт нужно на каждом шаге, и чисто исходя из скоростей памяти работать быстро это не может. А как же хитрые оптимизации? Они могут помочь, в особых случаях и в среднем, но худший случай всё равно будет именно таким. И вновь встаёт вопрос -- зачем вам настолько много?..
Что касается примочек -- ну вот есть Golly, у которого всё перечисленное имеется (подозреваю что он и оптимизирован весьма серьёзно).
P.S. В машине Тьюринга никакого сохранения шагов, что бы к ним можно было возвращаться, вообще говоря, нет.
>Нормально
>Нормально понаписал =)
Да я не только про вас, я про все комментарии под моим постом.
>Я вроде спрашивал про то зачем вам нужна такая реализация, а не что вам от неё надо...
Эээ, а это не одно и то же?)
>зачем вам настолько много
Ну блин, делать игру-песочницу хоть со сколько-то замкнутым миром -- это убивать весь запал.
>В машине Тьюринга никакого сохранения шагов
Насколько я помню, эти вот промежуточные состояния q1, q2, ... qn сохраняются и к ним можно перейти. Но похоже ошибаюсь, пардон.
Эээ, а это не
Эээ, а это не одно и то же?)
Нет. Поясню: зачем -- это про то что вы собираетесь с этой системой сделать, а что вы хотите от системы -- это требования к ней, которые вытекают из "зачем". Например -- вы хотите создать сумматор в жизни, и примерно можете оценить размер, отсюда вытекает то, насколько большое поле вам потребуется. А требовать огромное поле просто что бы было... Можно, но ведь это не важно, если вы никогда его не заиспользуете в полной мере (а сто тысяч на сто тысяч -- это правда очень много -- что бы забить такое поле какими-то осмысленными данным потребуется очень много усилий и времени).
Ну блин, делать игру-песочницу хоть со сколько-то замкнутым миром -- это убивать весь запал.
Компьютеры конечны сами по себе, всегда есть ограничение того, что на них в принципе можно сделать -- как в известном вопросе с подковыркой -- является ли ваш компьютер Тьюринг-полным? -- правильный ответ нет, ведь машина Тьюринга обладает бесконечной лентой, а у компьютеров память конечна. Но если что, у Golly именно что неограниченное поле по умолчанию -- то есть он будет выделять новую память по ходу дела (пока она не кончится).
игра
игра невероятно популярна среди программистов
Плюсую!
Кроме того, ассемблер -- это не про скорость
Согласен, обогнать их будет сложно, по сути самой задачи. Это как пытаться увеличить скорость решения NP-полной задачи, решая её на асме, фигушки увеличите скорость.
существующих мощностей не хватает
Думаю автору комментария, стоит просто прикупить компьютер помощнее и подороже.
будьте готовы оптимизировать код программы под кэш, конвейер, предсказания и прочее веселье
можно попробовать, почему бы и нет
стоит просто
стоит просто прикупить компьютер помощнее и подороже
Да не думаю, вообще компы слишком дорогие и стоит беречь то что уже есть. Мне просто правда неясно, какая задача в игре жизнь, пусть даже на старом компьютере, может требовать радикального ускорения в сравнении с существующими реализациями.
можно попробовать, почему бы и нет
Можно, но и желание прогать на ассемблере после такого может пропасть.
В любом случае, удачного и приятного программирования, fluorine. =)
Можно, но и
Можно, но и желание прогать на ассемблере после такого может пропасть.
Меня всё это (как я сам считаю, прирожденного программиста), только забавляет и доставляет невероятное удовольствие от процесса
В любом случае, удачного и приятного программирования, fluorine. =)
Спасибо! И вам тоже.
Будет, будет
Будет, будет обязательно. Только не спрашивайте когда, обязательно выложу здесь ссылки на свой сайт (скорее всего в гостевой, если Андрей Викторович разрешит) на игрушки, статью про создание игр на ассемблере, и статьи про создание отдельных игрушек, тоже возможно.
Кстати, можете ссылки на реализации скинуть?
UPD: одна из реализаций, которую я нашел: https://github.com/PyvesB/asm-game-of-life . Поделка какая-то кривая, я бы переделал её по другому, не буду рассказывать как, увидите в будущем.
И зачем вам высокопроизводительная? Какой вы её хотели бы видеть?
Скажем,должна ли игра вызывать sleep в цикле или должна выжимать из процессора все соки?UPD: походу значение sleep должно регулироваться по желанию пользователя, или вычисляться от количества объектов, "чем больше, тем меньше задержка"Как тогда представлять процесс игры, зачем выжимать из процессора все соки, если результат будет нельзя нормально увидеть?Хотя я догадываюсь, почему вам нужна высокопроизводительная версия: они [эти реализации] тормозят при большом количестве объектов. Верно?
Вопрос и совет =)
Если делать игру жизнь в качестве учебного проекта, кажется не стоит думать о таких вещах как производительность, но если уж -- то у меня есть вопрос: а что такое объекты? Самый простой способ создания игры жизнь на асме, который мне первым в голову приходит -- завести два двумерных массива и обновлять один от другого, меняя указатели на них местами в каждой итерации. Вывод при этом устроен так же просто -- пройтись по массиву; как и ввод -- просто ввести из входа размер поля, а затем соответствующие значения клеток. При этом итерация будет проходить за примерно равное время (линейно зависит от размера массива). Может быть вы ведёте речь об объектах в рамках какого-то более сложного представления поля (в духе выделять прямоугольники, в рамках которых все клетки "мёртвые" или организовать список из живых клеток с указанием их координат -- хотя мне не очевидно, ускорит ли это программу) -- но из написанного коммента это не ясно, почему и спрашиваю.
По поводу засыпания я бы предложил не мучать пользователя вопросами о дополнительной задержке, а сказать ему ввести минимальное время итерации. Реализуется это очень просто -- в начале итерации засекаем время, в конце считаем сколько прошло, остаток до минимума добиваем засыпанием, а иначе сразу идём дальше. Просто и удобно, никакого вычисления задержки от числа объектов (которое бы было ещё и машинно-зависимо).
Ну и код Бигурдана мне показался простым и понятным -- почему это кривая поделка?
Ну и код
Ну и код Бигурдана мне показался простым и понятным -- почему это кривая поделка?
Вы оформление смотрели? Там в конце строк незначащие пробелы, вакханалия с отступами, и отступы то табуляциями, то пробелами, человек явно не следит за оформлением своих программ. Ему откровенно пофиг на него, и я отказываюсь говорить о свойствах программ, в которых ужаснейшим образом нарушено оформление. Впринципе, если исключить оформление и немного поднапрячься, то код понятный, да, к тому же он ещё и маленький, что несомненно радует.
UPD: так он ещё и контрибьютор eclipse (пофиг, что это IDE, главное, что это огромный проект), меня удивляет как таких людей вообще допускают к промышленному программированию
как производительность
Да ладно, прекрасно подходит как учебный проект. Низкоуровневые оптимизации на асме мне кажутся нормальными. Если пытаться это делать на Си или на Паскале то... эм.., мягко говоря, если скрестить ужа и ежа, получится 1,5 метра колючей проволоки
а что такое объекты
я хотел сказать живые клетки, впрочем я не силен в терминологии этой игры, она меня просто забавляет.
по поводу засыпания я бы предложил не мучать пользователя вопросами о дополнительной задержке
я предлагаю ещё более простую версию, пользователь просто нажимает на клавиши 1, 2, 3, ..., 9. 1 - это самый медленный режим, 9-ка самый быстрый.
Реализуется это очень просто -- в начале итерации засекаем время, в конце считаем сколько прошло, остаток до минимума добиваем засыпанием, а иначе сразу идём дальше.
так выравнивают FPS в играх
> если
> если исключить оформление и немного поднапрячься
Если нужно разобраться с чужим коряво оформленным кодом, можете программу astyle использовать. Сам использую ключ -A3 (стиль K&R). Весь маразм не вычищает, но помогает сильно :)
> Низкоуровневые оптимизации на асме мне кажутся нормальными
А насколько низкоуровневые? И оптимизации чего? Учтите, компиляторы тех же Си и Паскаля в плане скорости генерируемого кода даже близко не подберётесь. А вот попытаться сделать бинарник как можно меньшего размера уже интереснее.
Вы оформление
Вы оформление смотрели?
Я считаю оформление несколько вторичным по отношению к сути программы -- трейлинг спэйсы и смешивание пробелов с табами иногда проскальзывают в коде у разных людей, в том числе и тех программистов, которых я уважаю -- и хотя это плохой знак, но о самом коде это мало что говорит. Я, например, не привык в ассемблерных программах делать отступы у циклов и условных конструкций, но это приемлимо. А вот сам этот код вполне понятный, комменты есть, читается хорошо -- короче говоря, не думаю что что-то можно назвать кривой поделкой только из-за оформления.
так он ещё и контрибьютор eclipse (пофиг, что это IDE, главное, что это огромный проект), меня удивляет как таких людей вообще допускают к промышленному программированию
Это как раз не удивительно, Эклипс (и остальные IDE) -- не лучшее творение человечества уж точно. =) Ну и это не их допускают, а сами такие люди и делают такие проекты.
Да ладно, прекрасно подходит как учебный проект. Низкоуровневые оптимизации на асме мне кажутся нормальными.
Игра жизнь прекрасно подходит как учебный проект, а низкоуровневые оптимизации если где место и имеют, то только в ассемблере. Только они бывают разными, и некоторые лучше не трогать, тем более в учебном проекте. Ну и про производительность я писал не на уровне машинных оптимизаций, а на уровне самого кода -- я же пытался так объяснить появление загадочных объектов.
я хотел сказать живые клетки
Тогда у меня вновь возникает вопрос -- почему вы думаете, что производительность будет существенно зависеть именно от числа живых клеток? Это было бы так только в довольно нетривиальных реализациях игры, про которые я уже писал, и про которые не уверен, будут ли они быстрей (а иначе зачем делать сложней?..).
я предлагаю ещё более простую версию
Да, хороший способ ввода, только я писал про подход к задержкам, а не про ввод. И я бы всё же не делал 9 самым быстрым, а сформулировал то же самое в терминах минимального такта (ведь по факту о них речь и идёт) -- тогда 0 означает без задержек, а 9 -- самую большую. Тут важно наличие режима без задержек -- тогда перенаправлением вывода можно будет получать файл с последовательностью состояний наиболее быстро -- что может быть полезно или просто забавно. =)
Я считаю
Я считаю оформление несколько вторичным по отношению к сути программы
Зря :-P
Да ладно
Да ладно, вон Дейкстра, Хоар, Вирт и прочие такой гавнокод в плане оформления в своё время писали. =) По сути-то он хороший.
Хотя в целом согласен -- оформление позволяет быстрей понимать программу, а значит быстрей находить в ней ошибки и улучшать её -- и это качество нельзя переоценить. Но всё же переоформить программу под свой стиль намного проще (часто можно автоматически), чем переписать в сути отвратительную программу. Но может проживу ещё двадцать лет, и тогда построже стану. =)
Во времена
Во времена Дейкстры, Хоара и Вирта (хотя относительно последнего несколько сомневаюсь) совокупный мировой программистский разум ещё не успел изобрести общие правила оформления программ. Да и Фортран с автокодами, как мы понимаем, структурным отступам не способствуют совсем.
А так тут даже дело не в том, что программу проще понимать (это очевидно). Дело в том, что если программа оформлена безалаберно, то её писал соответствующий персонаж с соответствующим же отношением и к самой программе, и к её возможным читателям. Таких персонажей следует удерживать на расстоянии, и, естественно, держаться подальше от их кода. Чисто так, из сугубо прагматических соображений.
Я считаю
Я считаю оформление несколько вторичным по отношению к сути программы
Может быть, может быть...
в коде у разных людей, в том числе и тех программистов, которых я уважаю
Как и сишность головного мозга скажем. Не лишать же из-за этого человека права профессиональной деятельности в IT.
почему вы думаете, что производительность будет существенно зависеть именно от числа живых клеток
я ошибся, пожалуй
нетривиальных реализациях игры
нетривиальной реализацией была бы версия, где подкрашивались бы разными цветами glider'ы, пушки, пули и тому подобное, но я не стану этого делать на асме и о скорости тогда я бы и не стал думать.
Игра жизнь прекрасно подходит как учебный проект, а низкоуровневые оптимизации если где место и имеют, то только в ассемблере. Только они бывают разными, и некоторые лучше не трогать, тем более в учебном проекте.
Я всерьёз хочу стать системным программистом, и чувствую, что через годик-полтора смогу "уверенно пнуть дверь" на собеседовании какого-нибудь мейнтейнера коммерческого дистрибутива (благо их хватает, всякие Red Hat'ы и CloudLinux'ы никто не отменял) и потом перекваллифицироваться в какого-нибудь kernel developer. Тогда-то может все эти кэши, конвейеры и предсказания могут мне понадобится, нужно бы Танненбаума достать с полки...
можно будет получать файл с последовательностью состояний наиболее быстро -- что может быть полезно или просто забавно
Плохой подход, лучше определять, что stdout это не терминал через isatty, который реализован через ioctl и отключить задержки, или дать просто скинуть всё в файл через ключь -o, так можно будет скинуть состояния без escape-последовательностей и это будет подходить для текстового анализа.
Интересно сколько нас будет терпеть Андрей Викторович =)
Конечно, лучше.
Конечно, лучше.
Поздравляю!
Большое спасибо вам за ваши книги, Андрей Викторович!
Рановато
Рановато спасибо говорить, вот издам, выложу — тогда скажете.