Вышел первый том книги А. В. Столярова «Программирование: введение в профессию»

Извините, а как вы определяете информацию с точки зрения комбинаторики? Это определение чем-то отличается от стандартного определения из теории информации, описание которого я привёл?

Есть прекрасная утилита tree, например.

Немного приятнее ls -R но проблемы те-же. Неужели вам самим приятно мотать выдачу этих команд? Если файлов много это же безнадёга какая-то.

Кстати emacs или vim это Unix-way или нет? Или ed - это наше всё? Спрошу иначе, почему свой любимый редактор не зазорно кастомизировать под свои нужды, обвешивая его всевозможными плагинами, а бродить по файловой системе или компелять проекты мне следует исключительно в «голой консоле»? Нет я понимаю, что это полезно знать и можно пару раз самому проделать, только зачем застревать здесь навсегда?

Так нажатие на [Tab] в Линуксе это же полный аналог клика по [+] в десктопе. Кроме того, глубокие файловые деревья и создаются теми, кто привык работать в десктопе, в Линуксе они более плоские, как правило.

Неужели вам самим приятно мотать выдачу этих команд?

А чем это отличается от блуждания по директориям в десктопе? В консоли можно хотя бы быстро отфильтровать то, что не нужно.

Кстати emacs или vim это Unix-way или нет?

Emacs это, в принципе, Unix-way с ужасной реализацией на ужасном языке. Там внутри все вполне себе интегрируется между собой. Он чем-то напоминает LaTeX с его пакетами.

Про vi ничего ценного сказать не могу, но он значительно улучшился с тех пор, как стал подсказывать, как из него выходить в ответ на Ctrl-C. :)

Ну, начнем с того, что у вас там перед суммой минуса нет, и l'Hôpital'я вы зачем-то обозвали Лапиталем. :)

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

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

А гайки винтить когда нет подходящего ключа? Острыми не получится Просто ваш преподаватель не смог объяснить вопрос до конца.

Так нажатие на [Tab] в Линуксе это же полный аналог клика по [+] в десктопе.

Спасибо, не подумал на эту тему.

А что думаете на тему vimdiff? Ведь в графике простой diff, да и merge делать значительно приятнее, не? Хотя сам пользую vimdiff по привычке...

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

Голословное утверждение, да и мне вот кажется, что если ФС состоит из 3 фалов и 100 каталогов с большой вложенностью, то проще будет понять структуру именно набрав find | less, т.е. прочитав 100 строк текста, чем тыкать в худьшем случае 100 раз по [+].

И как я на 512 мегабайтах компилировал ядро линукса, чудом, не иначе.

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

А что думаете на тему vimdiff?

У меня как-то не возникало реальной необходимости пользоваться такими утилитами, текстовыми или графическими (всякие Beyond Compare и пр.). Обычного diff всегда хватало, разве что пользовался colordiff.

А портянки make-файлов конечно же удобнее проектов IDE

Да, удобнее. В разы. Я работал и с тем, и с другим, причём успел и то и другое не просто «попробовать», а лоб расшибить и об тот станок, и об этот: под винду (старую ещё) я писал на Borland Pascal, на Borland C++ 4.0 и 4.5, даже успел понюхать какую-то древнюю MSVC, но подробностей уже не помню, ибо 1997 год. Под *nix'ы я, по правде, использовал только gcc et al., но мне хватило.

Не так давно припёрло портировать кое-что на Win*, попробовал «современную» MSVC, ничего от неё добиться не смог, разумеется. Поставил MinGW, всё завелось с полоборота. Да, на тех самых «портянках make-файлов».

Для меня этот вопрос решён и обсуждению не подлежит. Чтобы работать с IDE, нужно быть или идиотом, или мазохистом.

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

Я много чего собирал, включая иксы, кде и фаерфокс.

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

Это как раз довольно трудно объяснить. Начать с того, что количество информации здесь фигурирует не то, которое описывает «состояние объекта», а то, которое сообщает о наступлении события.

Дальше, информация измеряется тем, во сколько раз снижена исходная неопределённость. См. пример про двор замка и двух археологов.

Событие — это подмножество всего пространства возможных исходов («элементарных» в терминах теории вероятностей). На пространстве элементарных исходов должна быть введена какая-то мера, подобно площади двора пресловутого замка, иначе мы не сможем измерять вероятность событий. Если пространство дискретное — в качестве меры выступает суммарная вероятность изолированных исходов, составляющих событие; если пространство непрерывное — ну там начинаются страшные слова про интеграл функции распределения :) но тут эти страшные слова не особенно нужны.

Пространство элементарных исходов можно наглядно представлять себе как некое пятно на плоскости (неважно, какой формы), причём мы площадь этого пятна рассматриваем как эталон площади, равной единице. А событие — это какая-то часть этого пятна. Опять же, форма такой «части» может быть любая, но ясно, что площадь её будет меньше единицы, как и вероятность всегда меньше (либо равна) единице.

Если нам говорят, что НАСТУПИЛО событие, априорная вероятность которого была p, то, стало быть, неопределённость снизилась в 1/p раз. Ну, раньше было всё пятно возможностей (т.е. 1), осталась только его часть, соответствующая наступившему событию (площадью p), вот вам и 1/p. Чтобы полученную информацию измерить в битах, надо взять двоичный логарифм от 1/p (ибо 1 бит — это информация, уменьшающая неопределённость вдвое)

Я много чего собирал, включая иксы, кде и фаерфокс.

А,ну тогда без проблем, чуток напрягись и вспомни как собиралось в свопе foo-yc20-1.3.0

При компилянии небольшой программы на плюсах и 4 гигов оперативы может очень сильно не хватить.

Всю дорогу на плюсах пишу, памяти до недавнего времени было 3*256= 768 Mb, пока там кулер не сдох.

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

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

А портянки make-файлов конечно же удобнее проектов IDE

Конечно удобнее. Они хотя бы редактированию и версионированию поддаются. Не говоря уж о том, что нормальный make-файл - это обычная программа, и поэтому не должен быть никакой «портянкой».

Забавно ещё, что для представления любого исхода матчей из задачи на стр.165 достаточно двух бит.

Ну и чо? Напрашивается пример с динозавром, которого блондинка собиралась встретить на улице с вероятностью 50% (или встречу, или не встречу), ну да ладно. Вот, например, проводится лотерея, в которой нет мелких выигрышей, только джек-пот. Продано, скажем, сто тысяч билетов. Мойша купил билет. Информацию о том, выиграл ли он в лотерею, тоже можно закодировать одним битом: 1 - выиграл, 0 - не выиграл. Вот только информационная ценность полученного нуля будет почти нулевая (если быть точным, log_2(100000/99999) ), тогда как информационная ценность единички, ежели вдруг таки Мойша сподобился выиграть, составит log_2(100000), где-то там между 16 и 17 битами. Хотя, таки да, кодируется одним битом.

Более того makefile является свободной кроссплатформенной утилитой, т.е. если вы берёте чужой код, то больше чем наверняка вы сможете собрать исходник и под win и под lnx и под mac, и под dos

Ну это ты чушь сморозил.

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

Тут возможна одна засада. Я как-то раз в ЖЖ наблюдал, как небезызвестный Arvi The Hacker громил и последними словами обзывал продажную и капиталистическую теорию информации Колмогорова, которая-де вводит какие-то там «количества информации», тогда как на самом деле один килобайт информации содержит ровно один килобайт информации, и точка.

Вот чтобы такого хлама в мозгу не было, желательно всё-таки рассказать, как измеряется информация. А вот чего я не понял, так это почему вы противопоставляете объяснение через неопределённость объяснению через комбинаторику. Я, честно говоря, об этом даже особенно не задумывался, потому что теорию вероятностей я в книжке не излагаю, да и теорию информации тоже; теперь вот задумался и никак не могу понять, в чём я не прав :-)

Про vi ничего ценного сказать не могу, но он значительно улучшился с тех пор, как стал подсказывать, как из него выходить в ответ на Ctrl-C. :)

Просто в порядке казуса: все мои книжки набраны в vim :-) А студентам я обычно говорю, что, мол, vim рассказывать не буду, ибо это долго, кто хочет быть продвинутым — читайте методичку и проходите vimtutor, для всех прочих — сейчас расскажу, как из него выйти, если вы в него как-то всё-таки угодили (обычно в аудитории при этом слышится нервный смех): «<Esc>:qa!» поможет практически из любого положения.

попробовал «современную» MSVC, ничего от неё добиться не смог, разумеется. ... Для меня этот вопрос решён и обсуждению не подлежит. Чтобы работать с IDE, нужно быть или идиотом, или мазохистом.

... неа, похоже я ошибся, безнадёжен

Для меня этот вопрос решён и обсуждению не подлежит. Чтобы работать с IDE, нужно быть или идиотом, или мазохистом.

Очень спорное утверждение, особенно когда тот-же cmake умеет генерировать проекты для IDE, той-же Visual Studio или Xcode... Народ тоже наткнулся на эту проблему и решил её. В итоге кто чем хочет, тем и пользуется, никто из-за этого не страдает и флеймы на разжигает.

... неа, похоже я ошибся, безнадёжен

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

Ну да, вам в двухбитном сообщении принесли 3 бита информации. Более того, чтобы оценить «информационную ценность» сообщения вы должны обладать априорной информацией о распределении вероятностей возможных вариантов. Я понимаю, что статус универа подразумевает произнесение подобных заклинаний, только, как правильно отметил liberte, комбинаторное определение количества информации для программиста куда более полезно.

Если у вас есть некоторое случайное событие X, имеющее n исходов с вероятностями p_i, то вы имеете неопределённость H(X) = sum_{i=1}^n p_i log(p_i) (по Шенону)

Между прочим, эту формулу много кто много кого зачем-то заставляет зазубрить, она, например, фигурировала в программе абитуриентской олимпиады по информатике во ВШЭ, etc. И не понимают люди, что, ежели эту формулу просто запомнить, не будет совершенно никакого понимания, как её применять. А применить её по делу может только тот, кто знает, как её вывести, в смысле откуда она получилась и почему она именно такая.

У меня в книге, замечу, так далеко дело не заходит, поскольку книга слегка не об этом.

Ну в рамках данного ответа мне тяжеловато дать подробное объяснение на n-надцать страниц. Но всё же я пирвёл два примера-крайних случая. И да, я не настаиваю на её применении на 1-ом курсе, хотя в курсе обработки сигналов знание её обязательно, иначе становится не ясно, как они считают взаимную информацию, например.

У меня как-то не возникало реальной необходимости пользоваться такими утилитами, текстовыми или графическими (всякие Beyond Compare и пр.). Обычного diff всегда хватало, разве что пользовался colordiff.

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

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

Я понимаю, что статус универа подразумевает произнесение подобных заклинаний,

Заклинание — это когда без объяснений. Мне почему-то казалось, что я как раз привожу объяснение. Измерению количества информации у меня посвящён параграф на четыре странички, наполовину состоящий из примеров, так что вроде бы я не сильно злоупотребляю вниманием читателя; зато у него не будет шока, когда (если) он таки столкнётся с понятием количества информации и обнаружит, что таковое не равно размеру файла. Параграф написан ровно с этой целью.

комбинаторное определение количества информации

Это как, простите? (если что, про комбинаторику у меня там целая глава, но при чём тут информация?)

Ну это ты чушь сморозил.

Где? Мужики поняли, что стали не в состоянии компилять то, что понаписали. Сделали make для этих целей, шансов собрать стало больше, но неоднозначности оставались, по этому понаписали automake, autoconf... Я просто поставил точку на этапе make, не более того, до остального обучаемый дойдёт сам...

комбинаторное определение количества информации для программиста куда более полезно.

Определять количество информации надо через колмогоровскую сложность, и никак иначе

Где?

Я для кого цитировал?

Ну да, вам в двухбитном сообщении принесли 3 бита информации.

Возможно, что в этом и есть суть нестыковки двух определений: двухбитовое сообщение описывает состояние системы (исход чемпионата), а пресловутые 3 бита, степень уменьшения неопределенности (энтропии) при наступлении события вероятность которого равна 1/8.

И тут ошибочно смешивать две модели — комбинаторную (2^N) и модель информационной энтропии.

Хотя второе, чисто на пальцах, больше применимо к теории цифровой обработки сигналов, да ;-)

Просто вопрос в том какая модель будет более адекватно моделировать ситуацию.

суммарная вероятность изолированных исходов

Похоже это можно выразить проще — математическое ожидание, не?! ;-)

Спасибо. В общем и целом понятно. Хотя связи и фундаментальные категории в мозгу еще не сформировались, ну ничего будем качать.

Знаете, как и в любом процессе познания это очень похоже на то, как впервые человек знакомится с пределами переменных величин в матане.

Можно сколько угодно штудировать формулы, насиловать мозг Демидовичем (как тут некоторые плачут), НО пока человек не поймет фундаментальных основ, а именно:

• интегральное и дифференциальное исчисление изучает переменные величины;
• множество вещественных чисел не имеет «дырок», отсюда все волшебство и теоремы;

он будет бояться предмета и видеть перед собой непонятный «черный ящик».

Так и здесь. По крайней мере я сужу по себе.

ОК, пойду почитаю что-нибудь про информационную энтропию, до просветления :-)

Это как, простите?

Если у вас есть алфавит из m букв, то каждое слово длиной n несёт Log2(n^m) = m*Log2(n) бит информации (грубо говоря столько разрядов вам потребуется для представления этого слова в двоичной системе). Это именно то, что нужно программисту. Все варианты равновероятны. Учитывание хитровы_бнутых распредеейний вероятности к программированию никакого отношения не имеет, если только вы не программируете какой-нибудь статистический тулкит, т.к. это относится к предметной области конкретной задачи.

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

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

Энтропия — это количество информации, приходящейся на одно элементарное сообщение источника, вырабатывающего статистически независимые сообщения.

https://ru.wikipedia.org/wiki/Информационная_энтропия

Да, интересное дело...

Что да, то да.

Иногда нужно решать конкретные задачи, а не энтропию считать.

:)

Всю дорогу на плюсах пишу, памяти до недавнего времени было 3*256= 768 Mb, пока там кулер не сдох.

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

безнадёжен

безнадёжны все кто написал вам, что makefile это нормальная часть исходного текста программы, с которой как минимум можно, а возможно и стоит без всяких тяжеловесных IDE? Один вы шагаете в ногу?

Это именно то, что нужно программисту. Все варианты равновероятны.

Ага, и, например, коды Хаффмана как самый простой пример оптимизированного кодирования, а заодно все архиваторы и всё прочее отправляется в категорию «магия и гномики с палочками».

Похоже это можно выразить проще — математическое ожидание, не?! ;-)

Матожидание — это вообще не о том, то есть совсем не о том, то есть никак не о том. Ну вот вам пример. Перед нами три коробочки. В одной 1000 рублей, во второй 200 рублей, в третьей пусто. Выбор коробочек равновероятен. Матожидание тут применяется к тому, какую сумму следует ожидать в нашем кармане, когда мы одну из коробочек выберем и содержимое заберём себе. Вычисляется как (1/3)*1000 + (1/3)*200 + (1/3)*0 = 400р. Это такое «средневзвешенное», что-ли, с учётом вероятностей.

Ну вот другой пример. Перед нами сто коробок, в одной 1000р., в десяти — по 100р, остальные пустые. Мы берём одну наугад. Вероятность найти 1000 у нас 1%, вероятность найти 100 у нас 10%, матожидание = 1000*(1/100) + 100*(1/10) = 20.

множество вещественных чисел не имеет «дырок», отсюда все волшебство и теоремы;

Множестно рациональных тоже не имеет «дырок» (ибо всюду плотное), и чо?

тогда поведайте нам о своих мучениях в вендовой консоли

можно я не буду, тем более, что «мучение» несколько неверное определение.

Давайте я просто приведу одну аналогию. Представим, что PHP «застрял» на версии 4 или, в лучшем случае 5.0 (с современным PHP аналогия тоже в принципе работать будет, но похуже, вместо аналогии получим holywar, так что лучше представим). PHP-программист начинает рассказываать, какой замечательный это язык программирования, как легко найти хостинг с Apache + PHP, какая классная IDE PHPShtorm… Когда ему намекают, что есть более другие языки программирования, по сравнению с которыми его устаревший PHP смотриться бледно, он отвечает, что его оппоненты не знают PHP, потому как они сейчас не на php.ru общаются. Когда выясняется, что это не так, требует рассказать о мучениях в PHP…

Вот примерно такая аналогия. На PHP 5.0 (и даже 4.сколько-то там) вполне можно программировать, и если вы не законченный эстет, это не вызовет у вас каких-то мучений. Просто будет несколько неудобно. С командным языком DOS/Windows примерно таже песня.

Множестно рациональных тоже не имеет «дырок» (ибо всюду плотное), и чо?

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

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

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

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

У понятия «вещественных» есть одна проблема: с ними заведомо невозможна никакая конструктивная работа. Ежели вдруг возникнет вопрос «почему», ответ имеется в обсуждаемой книжке, параграф 1.5.4 :)

Множестно рациональных тоже не имеет «дырок» (ибо всюду плотное), и чо?

Или как там у Куранта с Роббинсом, еще проще: и квадрат и отрезок состоят из одинакового количества точек в смысле равномощности двух этих множеств.

В контексте вычислительной техники, да.

В контексте мозгов математиков, то ли еще будет ;-)

Парадокс Банаха-Тарского, например. Любимый многими.

безнадёжны все кто написал вам, что makefile это нормальная часть исходного текста программы, с которой как минимум можно, а возможно и стоит без всяких тяжеловесных IDE? Один вы шагаете в ногу?

Очень косноязычно написано, не понятно ничего, переформулируйте.

Кстати, хороший пример энтропия некоторого текста, ага?

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

Как-то так.