Эффективное изложение информации

[Mihaylo]

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

Интересует следующая тема: как излагать информацию наиболее эффективно. Или еще правильнее задать вопрос так: как научиться определять, какая часть информации более полезна, а какая менее.

Итак, есть какая-то информация, надо из нее выкинуть часть информации с минимальной потерей смыслового содержания. Сразу представляется, что это сжатие информации с потерями. Да, это так. Кто-то сразу задаст вопрос: "а какие данные надо сжать?". Ответ: меня интересует сжатие исходного кода программы. Опять же посоветуют почитать про сжатие текстов. Я сразу опять же и отвечу: я уже в курсе работы алгоритмов сжатия, но это не то!

Меня интересует сжатие смысловой информации, а не синтаксической. Опа! А это как? В чем разница?

Объясняю: сжатие смысловой информации - это отбрасывание менее важных подробностей, при этом синтаксическая информация неким образом изменяется либо в сторону увеличения (в битах), либо в сторону уменьшения, без разницы. Главное, что в преобразованных данных отсутствуют некоторые подробности/детали, без которых описание становится абстрактным, но по-прежнему остается достаточно информативным.

Например, возьмем и скроем в исходном коде С++ указания типов данных (bool, int, float, double, string)... Заменим на абстрактное auto. Или просто сотрем.

Много ли смысла потерял такой код? Ну вроде нет. Правда компилятор откажется компилировать, но это неважно.

Я подобные преобразования выполняю до такой степени сжатия, что от кода остается пустое множество. С этим проблем нет, тут все понятно.

Но мне непонятно, как проранжировать эти преобразования по степени эффективности. Что лучше скрыть? Типы данных или атрибуты функций private/public/virtual/static и проч?

[arseniiv]

Mihaylo в сообщении #1507883 писал(а):

Много ли смысла потерял такой код? Ну вроде нет.

Смотря для кого. Типы многое говорят человеку, который привык полагаться на статическую типизацию. А если дело в громадных типовыражениях из C++, то там вроде была возможность объявлять синонимы и опускать некоторые аргументы. Это не всегда поможет, но всё же превратит типы из неприятности в пользу.

А auto стоит ставить с осторожностью. Во-первых в важных местах кода стоит иметь явные указания типов, чтобы компилятор не вздумал вдруг вывести что-то слишком общее или (например по нашей ошибке) не то. Во-вторых в местах, где всякие инты, чары и булы, может часто оказаться удобнее писать всё же их (а может и нет). В-третьих в местах, где читатель кода может споткнуться, стоит помочь ему (см. выше), плюс это объединяется с «во-первых» в смотрящих вовне частях кода — обычно компиляторы будут настаивать, чтобы там типы были все явно указаны, но я не знаю про позволения и требования конкретно C++. Это нужно делать, чтобы труднее было не заметив поломать клиентский код, и даже если у вас там не библиотека, всё равно как правило каждый подмодуль программы — как библиотека для каких-то других клиентских подмодулей.

Mihaylo в сообщении #1507883 писал(а):

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

Надеюсь, ваш код приходится читать лишь единицам, потому что это печально.

Mihaylo в сообщении #1507883 писал(а):

Но мне непонятно, как проранжировать эти преобразования по степени эффективности.

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

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

-- Пт мар 05, 2021 03:12:05 --

А, ну если код например подготавливается в виде примеров имплементации к каким-нибудь алгоритмам, то там и правда есть место соблазну поубирать лишнее, но это плохо по нескольким причинам:

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

• Как я выше писал, «минифицировать» сложность восприятия и манипуляций с кодом в реальном коде придётся другим образом, так что делать иначе в примерах кода — дешёвый приём с точки зрения умудрённых опытом читателей, плохой совет для неумудрённых и упущеные возможности реального упрощения для авторов. Тут всё ровно так же как в оптимизации сверху вниз, от архитектуры к деталям, и оптимизации на глазок снизу вверх без профилирования.

• Наконец может быть даже и так, что язык или версия языка (слишком старая) выбраны неудачно. Да.

-- Пт мар 05, 2021 03:14:14 --

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

[Mihaylo]

Объясню, зачем может быть нужен тот код "дистиллированный" (или "рафинированный"), из которого выкинули часть информации, большую долю информации или вообще весь текст кода. Этот текст будет читать разработчик, при этом надо сжать информацию для более лёгкого восприятия.
Например, имеется какой-нибудь достаточно сложный библиотечный объект с кучей полей, методов. По большому счету, если попросить подсказки у опытного разработчика, разбирающегося в этой библиотеке, то он скажет что-то вроде: "Тут два очень важных свойства x и y, в основном к ним обращаются через 5 вот этих методов a(), b(), c(), d(), e(), остальное используется крайне редко. В конце не забудь запускать метод f(), чтобы созданный объект исчез с экрана."

Если посмотреть на библиотеки и реальный код, то в нем довольно много мишуры, надо научиться управлять этим и компьютер должен помогать в этом деле. Я серьезно подошёл к этому вопросу, у меня уже достаточно глубокая проработка вопроса. Осталось автоматизировать дистилляцию (рафинирование).

Что бы вы сказали про некоторую реальную программу X? (Говорить следует на языке переменных, функций и прочих языковых конструкций в коде.) Я бы в первую очередь перечислил выходы, но возможно не все. Указал бы типы данных. Затем перечислил бы входы, но возможно не все. То есть обрисовал бы сигнатуру программы как функции. Затем я бы начал разбивать супер-функцию на части (декомпозиция).

Почему такой порядок изложения наиболее эффективный? Почему информационная энтропия падает быстро? А самый ли лучший подход обозначенный мною?

[mathpath]

Прежде всего - интересно ли это вам

[Mihaylo]

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

[upgrade]

Mihaylo в сообщении #1507883 писал(а):

Например, возьмем и скроем в исходном коде С++ указания типов данных (bool, int, float, double, string)... Заменим на абстрактное auto. Или просто сотрем.

Это не сжатие, это перенос части обработки информации с "сервера" на "клиент", Клиент в данном случае обладает пониманием что есть типы данных, на это понимание у него отводится память и работа его процессора и когда он встречает код без указания типов, он как минимум понимает, что это код без типов.

[realeugene]

upgrade в сообщении #1507980 писал(а):

Это не сжатие, это перенос части обработки информации с "сервера" на "клиент",

В плюсах не переносит.

[arseniiv]

Mihaylo в сообщении #1507934 писал(а):

Например, имеется какой-нибудь достаточно сложный библиотечный объект с кучей полей, методов. По большому счету, если попросить подсказки у опытного разработчика, разбирающегося в этой библиотеке, то он скажет что-то вроде: "Тут два очень важных свойства x и y, в основном к ним обращаются через 5 вот этих методов a(), b(), c(), d(), e(), остальное используется крайне редко. В конце не забудь запускать метод f(), чтобы созданный объект исчез с экрана."

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

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

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

Mihaylo в сообщении #1507934 писал(а):

Почему такой порядок изложения наиболее эффективный? Почему информационная энтропия падает быстро? А самый ли лучший подход обозначенный мною?

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

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

-- Пт мар 05, 2021 20:28:14 --

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

И никогда не повредит делать код таким, что его нужно как можно меньше объяснять. Пока код не нуждается в изощрённых оптимизациях, его стоит держать как можно более модульным, обобщённым и маленьким по размеру. Ссылки на алгоритмы и статьи в документации всегда полезны тоже, и комментарии с небольшими объяснениями в сложных местах. Когда код доходит до состояния, при котором нужны нетривиальные усилия, чтобы его объяснить или понять самому, это уже одна проигранная партия. Этого нельзя избежать всегда, но стоило бы стараться.

-- Пт мар 05, 2021 20:30:00 --

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

[Mihaylo]

arseniiv в сообщении #1508002 писал(а):

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

Что эффективнее: рассказать о том, как работает некоторая подфункция (подробно), или как работает программа в целом (абстрактно)? Сверху вниз или снизу вверх? В обоих случаях информация порционная.

arseniiv в сообщении #1508002 писал(а):

И никогда не повредит делать код таким, что его нужно как можно меньше объяснять.

Давайте не будем улучшать код, а будем объяснять то, что и без улучшений работает.

[arseniiv]

Mihaylo в сообщении #1508016 писал(а):

Что эффективнее: рассказать о том, как работает некоторая подфункция (подробно), или как работает программа в целом (абстрактно)?

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

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

Mihaylo в сообщении #1508016 писал(а):

Давайте не будем улучшать код, а будем объяснять то, что и без улучшений работает.

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

-- Пт мар 05, 2021 21:49:02 --

arseniiv в сообщении #1508017 писал(а):

Если мы притом не имеем обратной связи с изучающими, и они могут задаваться разными вопросами

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

[Mihaylo]

В общем у меня наклевался абстрактный язык [программирования]. То, что он абстрактный - это точно, но вот язык программирования ли - не факт. Не компилируется потому что.

Язык придумать нетрудно, но вот эффективно использовать его - такая прикладная задача еще не решена.

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

1. Абстрактное множество - это неполное перечисление чего-либо. Например, "1, 2, 3 и так далее". Или такое: "белый, синий, красный и проч".

2. Абстрактный список - это упорядоченное абстрактное множество. В отличие от абстрактного множества перечисление элементов производится строго в определенном порядке. При этом элементы неопределенности (абстрактности) вроде "и так далее", "и т.п. и т.д.", "..." могут повторяться.

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

Set1 := abstract(Set2)

На этих трёх китах я строю все остальное.

4. Абстрактное перечисление (enumeration) - фактически это то же множество, только элементами выступают значения (values).

5. Абстрактный тип данных - это тип данных, построенный на базе абстрактного перечисления.

6. Абстрактный код - это [упорядоченный] абстрактный список инструкций.

Func1(a);
Func2(b);
бла-бла-бла
for (int = 0, i<n, i++) {}
бла-бла-бла

7. Абстрактное условие в операторах if, for, while - это абстрактная функция. Вообще условие/предикат - это функция, на входе которой список переменных и логических операций над ними, а на выходе переменная типа bool. У условия-функции нет имени, это фактически анонимная функция, привязанная к ключевым словам if, for, while. Поэтому нет необходимости использовать ключевое слово abstract.

if ((a>1) && etc) {}

8. Абстрактный объект - это абстрактный список или абстрактное множество полей и методов.

9. И так далее. (Дальше нет смысла перечислять языковые конструкции.)

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

Например,

[a, b, c, ...] = abstract(a, b, c, d, e, f)

Вместо "и так далее", "бла-бла-бла", "etc" я применяю многоточие (...).

-- 05.03.2021, 23:07 --

Ещё сегодня открыл 3D-модель станка моего коллеги... Станок вживую не видел, он на модели весь кожухами закрыт, а мне нужно было найти все двигатели и редукторы... И тут я понял, что и в конструировании нужно эффективное изложение информации.

Нажал бы кнопочку "скрыть всякую МИШУРУ" и готово!

Да, как говорит arseniiv, надо грамотно строить архитектуру. Всякие там Автокады и Компасы умеют группировать детали в макроэлементы или блоки. Но у этих всех программ также как и у языков программирования - они группируют код лишь по одному признаку. В таких условиях правильнее всего группировать по функциональным связям: так в языках программирования все группируется в объекты, а в программах 3D-моделирования группируется по сборочным единицам.
Однако взять и скрыть все метизы я не могу. Хотя, конечно, вру, так как просто не знаю, как это можно сделать. Ну ладно, но вот скрыть из модели все кожуха я не могу однозначно, так как Автокад ко всем деталям относится одинаково. В итоге я сидел и скрывал каждую деталь и никакой помощи от Автокада в этом нет.

[Mihaylo]

Mihaylo в сообщении #1507975 писал(а):

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

Для этого я придумываю метод так называемого object tracking или в более общем смысле task tracking. С помощью этой штуки разработчик может обозначать область интересов, образовавшуюся в данный момент времени. В самом простом случае область интересов представляет собой некоторый объект (объект, функция, переменная, etc).
Многие IDE позволяют по имени объекта отслеживать его декларацию, присвоения и использования. Однако этого недостаточно. Я хочу отслеживать:
1. Несколько объектов одновременно (множество объектов).
2. Абстрактное множество объектов. Я могу знать, какие объекты я хочу отслеживать, а также могу не ограничиваться списком. Также я могу отслеживать целиком абстрактное множество объектов ([...] - я не знаю, что ищу).
3. Абстрактную функцию. Я хочу понять зависимость между двумя объектами (например, переменными).

Так, допустим, пришел новый программист в организацию, ему говорят: "Когда нажимаешь на кнопку, выскакивают каракули. Найди ошибку и исправь исходный код." Программист открывает незнакомую программу. Он вводит в качестве task for tracking абстрактную функцию, на входе которой пустой абстрактный список, а на выходе - объекты вывода на экран.
Что интересно: в процессе работы задача конкретизируется и вместе с тем конкретизируется код, выводимый на экран.
Если разработчик не укажет задачу для отслеживания, то и соответственно код будет высокоабстрактным - сигнатура программы (как я описывал выше).
Иными словами, разработчику следует предоставить абстрактный интерфейс, в котором он может обозначить свою текущую задачу. За этими умными словами может скрываться что-то достаточно простое в плане реализации.

-- 06.03.2021, 00:29 --

Я вот все думаю, может и не нужно измерять энтропию информации, сравнивать между собой подходы изложения информации. Достаточно изложить всю информацию в соответствии с задачей и максимально скрыть информацию, не связанную с задачей.
Мои предположения о том, что сигнатура программы наиболее эффективна как информация, основана на когнитивном искажении. Обычно мы не знаем, что хотим (задача неопределена), поэтому лучше все излагать с самого верху, "по полочкам". Но это не всегда так.

[Mihaylo]

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

Сейчас я думаю над следующей задачей из списка: как оценить важность переменной или функции? Как это сделать вручную? Можно ли автоматизировать оценивание?

Например, функция транспортировки в автомобиле важнее, чем функция проигрывания музыки. Пример 2: функция вычисления корня квадратного важнее функции вычисления арккотангенса. Пример 3: функция main() важнее вложенного в нее вызова функции func1()?
Как это определено? В чем измеряется важность?

-- 09.03.2021, 23:05 --

Умея измерять важность, я бы мог перечислить четыре основных функции смартфона, а остальные бы заменил многоточием и потери информации было бы минимум. Было бы минимум увеличения энтропии.
Следовательно, вроде как информационная энтропия подходит в качестве оценки важности.
Но как ее измерить для некоторого абстрактного списка?

Допустим, у нас есть список из 8 деклараций переменных типа int. Как оценить, какие переменные более важные?

Тут же мысленный эксперимент: если наблюдателя интересует аудиосистема автомобиля, то функция проигрывания музыки становится важнее функции транспортировки из точки А в точку Б.

[arseniiv]

Mihaylo в сообщении #1508515 писал(а):

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

Не обязательно — например я вот почитал и решил что пока добавлять больше нечего.

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

-- Вт мар 09, 2021 23:31:28 --

То есть одной конкретной версии кода скорее всего совершенно недостаточно для дидактических целей. Если потребовать от инструмента автоматизированного упрощения, то это по-моему должно значить, что инструмент должен угадывать, из какого более простого кода мог возникнуть текущий более сложный. Это опять же требует вычислений с возможными целями тех, кто пишет/меняет код.

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

[Mihaylo]

Именно это нечто умное и общее мне и нужно. Рассмотрим автомобиль: как объяснить, что тебя интересуют:
1. Общие функции автомобиля
2. Аудиосистема автомобиля
3. Безопасность автомобиля
4. Экстерьер автомобиля

По идее, следует идти сверху вниз: от общих функций к частным... И вдруг ты останавливаешься на каком-то уровне, который тебе нужен. Я вроде говорю о навигации по функциям, а подразумеваю навигацию по переменным, которые являются выходом этих функций. И вот ты нашел эти переменные, которые интересуют. Ты можешь интересоваться не просто переменными, а связью между переменными. Фактически задается не одна, а две области интересов X и Y. Если область X не задана, то интересует область Y "в общем" (например, все про аудиосистему). А если не задать и Y, то интересует автомобиль в целом.
"Не задать X и Y" - это значит проставить многоточие (...) в смысле абстрактного языка, который я описывал выше.

Система навигации с одной областью интересов - это когда нажимаешь "+", чтобы развернуть интересную информацию, и нажимаешь "-", чтобы свернуть неинтересную информацию. Я называю это фолдингом (обратите внимание на элементы управления "+" и "-"):



-- 10.03.2021, 00:11 --

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

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

То есть мы достаточно уделили внимания области интересов юзера. Надо взять извне оценку важности и пересчитать с учетом произвольного интереса юзера. Может это какой-то индекс цитирования должен быть?