Порядочный евангелист не станет обливать грязью все, что было придумано до него, вместо этого спокойно укажет на преимущества и недостатки своего подхода.
Верно, так и должно быть. Всё остальное — профанация или шарлатанство.
Как будто меня какие-то 'евангелисты' заставляют использовать ооп? Ну бред же.
Не самообманывайтесь: никто не может изучить все технологии, узнать все практики и составить сравнительный анализ, какие объективно удобнее.
Скорее всего, вам показали ооп, вам понравилось то, что вы увидели, это показалось более удобным по сравнению с тем, что вы знали и использовали до этого, поэтому и используете сейчас.
Если бы вы жили в обществе, где повсеместно используется что-угодно, кроме ооп, а литературы по ооп было бы крайне мало, узнали бы вы о нём? Познакомившись с ним, научились бы вы «его готовить»? Сумели бы вы разглядеть в нём то удобство, не зная ни паттернов, ни хороших практик, не имея опыта (ведь коллеги не используют ооп в нашем мысленном эксперименте)? Искренне сомневаюсь. Всё-таки, человек коллективное (стадное) существо. А потому нужны евангелисты, задача которых рассказывать всем, какая штука была изобретена и как полезно обществу начать её использовать на практике. Общество слушает, кто-то использует, потом только вырабатывается оценка, которая, к слову, играет решающую роль, а не мнения евангелистов, потому что
Хуже всего, когда теоретики рассказывают практикам, как им делать их работу.
Это не относится к обсуждению алгоритмических паролей. Каждый опытный социолог скажет, что результаты соцопроса сильно зависят от постановки вопроса. Поэтому при составлении инструкций необходимо заменить такие формулировки на нейтральные.
Я бы тот камень в конкретный предложенный алгоритм кинул, что имена мужей и даты свадеб в женском коллективе обнародованы и всем известны, потому в качестве seed использоваться не могут.
В жизни бывает, что рогоносец — олень.
Если в ночь на день N он не сделает умозаключение, то остальные не смогут правильно сделать свои умозаключения.
Вот, скажем, N=1. Некий муж считает, что N=1, но в первый день не случается убийства. Он рогоносец или единственный рогоносец — олень, который не догнал, что его жена неверная?
Это, конечно, не относится к исходной логической задачи, но тема устойчивости распределённых систем тоже весьма интересна.
upd. lorc уже написал про возможный троллинга для N=1.
Разве это существенно? Скажем, иероглифы хираганы я могу запомнить вряд до 15, если при восстановлении будет под рукой таблица, и до 7-10, если не будет. Китайские иероглифы даже в количестве 5 штук я не восстановлю, даже если под рукой будет соответствующая таблица. Значение ни тех, ни иных я не знаю. Просто алфавит меньше.
А вот семь букв или семь слов (знакомых) для нас — это как раз всё равно. Потому что те и другие мы обрабатываем как целостные объекты, гештальты.
Опять же. Что проще, запомнить «оывхзку» («о! ы-ы-ы-ы… вот хз… ку» — уже запомнил) и «овации пароходом гештальту пенсне шизофазия велюром седло»? Букв-то всего 33 и многовероятно появление слогов и других знакомых групп. А слов больше и далеко не каждое вызывает устойчивый запоминаемый образ.
Или же под объектом в тексте понимается именно образ? Но тогда как сделать однозначное сопоставления объекта и формальных языковых конструкций (букв, слов, словосочетаний)? У каждого же по-разному.
Однажды мне потребовалось запомнить последовательность из 3 иероглифов, чтобы через время их воспроизвести. Две минуты старался, но не осилил. При этом иероглифы были не сложными, до 5 штрихов каждый. Оказалось, проще было сфотографировать на телефон.
Это я к тому, что число объяснять надо. Вы говорите, что рассматривается случайная последовательность букв, но в тексте этого нет. Да и код отнюдь не случаен. Да даже для случайной последовательности следует указать размер алфавита «объектов» (7 букв запомнить — не 7 слов, что в свою очередь не 7 иероглифов).
P.S. я знаю про один эксперимент
На линейной шкале (оттенки серого, размеров и т.п.) выбирается в определённом смысле равноудалённо n точек и затем предлагается случайная последовательность этих точек человеку, чтобы он идентифицировал каждую точку. Шкалу он видит только единожды, перед началом классификации, число n знает. Оказало, наиболее комфортно человек классифицирует при n<9, причём эта цифра почти не зависит от природы линейной шкалы, лишь бы границы ощущались как диаметрально противоположные (белый-черный, точка-метр).
В когнитивной психологии ту часть памяти, в которой непосредственно производятся вычисления «в уме», называют кратковременной и рабочей. Там всё сложно и неоднозначно, но как её ни назови, а объём этой памяти сильно ограничен. Разные исследователи называют «магические числа» семь и пять. Это средние значения. Объём «рабочей» памяти зависит от обстоятельств и коррелирует с интеллектуальными способностями.
— Петька, приборы?
— 42.
— Что «42»?!
— А что «приборы»?
В каких единицах числа приведены? В битах? Байтах? Вариках?
Эта статья мне сильно впечатлила. Не ожидал, что есть многие, кто способен в описаниях преимуществ занижать впечатление от показателей неявной сменой контекста.
Обычно как раз наоборот, стараются выбрать наиболее броские формулировки
Это уменьшает время перелёта с десяти часов всего до одного часа. Испытайте AirTrain-8000 и потратьте 900% (!) времени перелёта на полезные дела.
За формулировку, которая в статье, маркетологу по шапке прилетело бы тотчас.
Хотя лично я не люблю проценты. Постоянно приходится вчитываться в контекст, проценты чего относительно чего, а потому при беглом чтении их использование почти всегда вводит в заблуждение. Явные множители этого недостатка лишены.
На всякий случай скажу, что я не пишу и не поддерживаю ни один из вышеназванных визуализаторов, но идея представлять историю-как-граф как нарисованный граф мне кажется достойной внимания и рассмотрения.
Для двух веток вышеобозначенное решение Урю работает даже из-под консоли, если не заглядывать черезчур глубоко в прошлое, а ограничиться перечисленными вами коммитами.
Мне кажется возможным написать визуализатор, порождающий картинки в духе
этих
Ось времени: слева направо.
Цельная линия отмечает первого родителя, пунктирная — второго.
Сможете сказать, что произошло в этом репозитории?
главное: не требовать единомоментное отображение сообщений всех коммитов и прочей ёмкой информации на экране, иначе получим тот же gitk с ограничением 1 коммит на строку. Цель ведь обозреть происходящее в истории, что откуда куда попало. А метаинформацию можно показывать при наведении/нажатии или через переход в режим gitk-like сразу в окрестности выбранного на этом графе коммита.
Впрочем, соглашусь, что если бы была возможность сохранять в merge-коммите информацию о том, требовалось или не требовалось разрешение конфликтов, картинки принципиально можно было бы сделать проще.
rebase vs merge — понятная тема и аргументы понятные.
Но объясните, в чём проблемы с т.н. железнодорожными путями?
Разве это не проблема исключительно визуализатора?
Скажем, выше приведена картинка просто отвратительнейшей визуализации орграфа.
Сходу нашел GitVersionTree и BranchMaster — наработки, но отражающие ключевую идую: двумерная визуализация орграфа для изучения/просмотра топологии веток.
Как мне кажется, если есть интегрируемый в среду разработки инструмент просмотра истории репозитория, страх перед ветвистостью историей существенно снизится и разработчики начнут выбирать инструмент (rebase vs merge) исходя из их целевого назначения, а не из страха иметь историю, которую встроенный визуализатор отображает запутанно.
AFAIK, самая большая проблема — это время обработки:
1. Размер деревьев. Число токенов на порядок-два (зависит от ЯП) больше числа строк.
2. Деревья — двумерные структуры. СКВ работают преимущественно с классическими операциями Левенштейна (добавить, удалить, заменить строку). Много ли Вы знаете СКВ, которые бы отличали <удалить строку A №5 + вставить строку A перед строкой B №4> и <поменять местами строки B №4 и A №5> и корректно сливали эти патчи с другими? Для AST необходимо же исходно поддержить как горизонтальные операции (добавление/удаление дочернего поддерева), так и вертикальные (замена поддерева его дочерним поддеревом/замена поддерева T на C[T] для некоторого контекста C[] с одним подстановочным местом). Вроде бы это обстоятельство меняет асимптотическую сложность.
И ещё обращаю внимание, что получение диффа — более простая задача, чем построение модели (в т.ч. с конфликтным/бесконфликтным слиянием патчей) СКВ.
P.S. Я полностью согласен с последним: если когда-то СКВ научатся работать с AST и будет унифицированный формат деревьев, инструменты программирования шагнут на принципиально другой уровень удобства.
Для обосноснования ненаучности не обязательно использовать научный метод. Правда, в таком случае обоснование не будет научным, очевидно. Но разве это в конкретном обсуждении важно?
Кроме этого, научность, полезность и правильность — три разных понятия. Коррелирующих, но не эквивалентных.
Я не уверен, что Вы правильно меня поняли, поэтому опишу свой вопрос подробнее.
В первом примере с XOR написано:
У нас 2 входящих нейрона и один нейрон на выходе
Один нейрон «голосует» за результат XOR-а, т.е. за 0 или 1, и возвращаемое значение из интервала [0,1] мы интерпретируем как 0 или 1 в зависимости от того, к какому краю интервала ближе, а отклонение — как меру возможной ошибки. Скажем, чем ближе к 0.5, тем сложнее коррекно интерпретировать результат. Верно?
Во входном слое нам необходимо 28x28=784 нейрона, на выходе 10 нейронов
В задаче с цифрами есть 10 различных вариантов, то есть мы хотим получить чуть больше 3 битов информации.
Если делать по аналогии с тем, что написал выше, то должно быть 4 выхода по числу бит, которые мы хотим получить.
Если же мы говорим, что каждому варианту должен соответствовать свой выход и нейросеть голосует за каждый вариант отдельно, то в задаче с XOR должно быть 2 выхода.
Если мы говорим, что в задаче с XOR достаточно одного выхода, потому что «голос за 0» = 1 — «голос за 1» и нечего подавать на выход избыточную информацию, то в задаче с цифрами должно быть 9 выходов.
В общем, не получается у меня согласовать два примера, отсюда и вопрос.
Прошу прощения за дилетантский вопрос, снейросетями не работал до этого:
почему на выходе 10 нейронов по числу вариантов ответа, а не 4 по количеству фактической информации?
Исходно эта статья была частью цикла статей про свободные монады, одна из которых была недавно переведена на хабре, а другая упомянута в тексте. Предполагалось, что читатель уже знает, что такое свободная монада и какими свойствами она обладает.
Сейчас добавлю в предисловие это замечание.
С более-чем-годовой задержкой попробую ответит, в чём я вижу красоту этого решения поставленной задачи. Речь идёт о подходе, который естественен для Хаскелля и может быть воспроизведён односвязными списками на любом другом ЯП (не без сложностей).
Поставлена задача написать функцию (Nat -> Bool) -> Maybe Nat.
Если вообще никаких ограничений на функцию Nat -> Bool не накладываются, задача неразрешима, поскольку (неформально говоря) за конечное время возможно проверить только конечное число вариантов, а никаких других способов пощупать эту функцию у нас нет.
Допустим, на функцию накладываются какие-то ограничения. Допустим, как ramntry предложил, её можно декомпоновать на примитивные равенства f(x)==c. Для такого класса функций существует алгоритм, использующий эти параметры c, который позволяет за менее-чем-линейное время с постоянной памятью найти ответ. Однако какой тогда должна быть сигнатура функции?
Недостаток эффективного подхода заключается в том, что для каждого класса функций, которые представляются в определённом параметрическом виде, нужно писать свой собственный алгоритм, который зависит от всех параметров функции и от всех других особенностей, знания о которых нужны алгоритму для решения поставленной задачи. Не возможно написать решатель (Nat -> Bool) -> Maybe Nat, который бы использовал один из этих целевых алгоритмов, потому что такой решатель не будет иметь информации о «скрытых параметрах» функции.
Один из способов обойти этот недостаток заключается в передачи всех параметров вместе с функцией. В любом случае появление нового класса функций, для которых задача может быть решена, приводят к необходимости переписывать всё либо жертвовать универсальностью решателя и создавать новую функцию.
Как бы то ни было, предложенная в статье функция способна решить задачу на весьма широком диапазоне функций, будучи универсальной и сравнительно простой. Такие неэффективные, но простые и универсальные решатели всегда занимают свою нишу: когда нужно быстро написать надёжный простой код, который хотя бы когда-нибудь выдаст правильный ответ с использованием сколько-угодно дополнительных ресурсов, чтобы использовать его едино- или несколькоразово.
Не совсем понятно, почему колмогоровскую сложность нельзя считать программно.
С одной стороны понятно, что при наличии алгоритма, вычисляющего колмогоровскую энтропию всякой строки при фиксированном языке, получается противоречие.
С другой стороны, вручную для конкретного языка можно определить колмогоровскую сложность отдельных строк; стало быть, можно написать программу, которая для некоторых строк вычисляет их энтропию, а на остальных зависает или даёт сигнал, что не может их вычислить.
Можно ли сформировать максимальное перечислимое множество строк, для которой найдётся программа, считающая колмогоровскую сложность этих строк? Вопрос похож на заданный в видео: мы не можем определить энтропию всякой строки, но для некоторых же это сделать можно? Конечно, на такую программу хотелось бы накладывать ограничение, чтобы она сама знала, для каких строк она может посчитать, а для каких — нет.
Скорее всего, вам показали ооп, вам понравилось то, что вы увидели, это показалось более удобным по сравнению с тем, что вы знали и использовали до этого, поэтому и используете сейчас.
Если бы вы жили в обществе, где повсеместно используется что-угодно, кроме ооп, а литературы по ооп было бы крайне мало, узнали бы вы о нём? Познакомившись с ним, научились бы вы «его готовить»? Сумели бы вы разглядеть в нём то удобство, не зная ни паттернов, ни хороших практик, не имея опыта (ведь коллеги не используют ооп в нашем мысленном эксперименте)? Искренне сомневаюсь. Всё-таки, человек коллективное (стадное) существо. А потому нужны евангелисты, задача которых рассказывать всем, какая штука была изобретена и как полезно обществу начать её использовать на практике. Общество слушает, кто-то использует, потом только вырабатывается оценка, которая, к слову, играет решающую роль, а не мнения евангелистов, потому что
Я бы тот камень в конкретный предложенный алгоритм кинул, что имена мужей и даты свадеб в женском коллективе обнародованы и всем известны, потому в качестве seed использоваться не могут.
Подумал, что косяк переводчика, но нет, на хромиумовских браузерах таки пробела не видно.
Если в ночь на день N он не сделает умозаключение, то остальные не смогут правильно сделать свои умозаключения.
Вот, скажем, N=1. Некий муж считает, что N=1, но в первый день не случается убийства. Он рогоносец или единственный рогоносец — олень, который не догнал, что его жена неверная?
Это, конечно, не относится к исходной логической задачи, но тема устойчивости распределённых систем тоже весьма интересна.
upd. lorc уже написал про возможный троллинга для N=1.
Можно подробнее описать, как работают полифиллы? Ведь здесь идёт по сути расширение HTML как часть технологии (вторая часть — API для JS)
Опять же. Что проще, запомнить «оывхзку» («о! ы-ы-ы-ы… вот хз… ку» — уже запомнил) и «овации пароходом гештальту пенсне шизофазия велюром седло»? Букв-то всего 33 и многовероятно появление слогов и других знакомых групп. А слов больше и далеко не каждое вызывает устойчивый запоминаемый образ.
Или же под объектом в тексте понимается именно образ? Но тогда как сделать однозначное сопоставления объекта и формальных языковых конструкций (букв, слов, словосочетаний)? У каждого же по-разному.
Это я к тому, что число объяснять надо. Вы говорите, что рассматривается случайная последовательность букв, но в тексте этого нет. Да и код отнюдь не случаен. Да даже для случайной последовательности следует указать размер алфавита «объектов» (7 букв запомнить — не 7 слов, что в свою очередь не 7 иероглифов).
— Петька, приборы?
— 42.
— Что «42»?!
— А что «приборы»?
В каких единицах числа приведены? В битах? Байтах? Вариках?
Обычно как раз наоборот, стараются выбрать наиболее броские формулировки За формулировку, которая в статье, маркетологу по шапке прилетело бы тотчас.
Хотя лично я не люблю проценты. Постоянно приходится вчитываться в контекст, проценты чего относительно чего, а потому при беглом чтении их использование почти всегда вводит в заблуждение. Явные множители этого недостатка лишены.
Для двух веток вышеобозначенное решение Урю работает даже из-под консоли, если не заглядывать черезчур глубоко в прошлое, а ограничиться перечисленными вами коммитами.
Мне кажется возможным написать визуализатор, порождающий картинки в духе
Ось времени: слева направо.
Цельная линия отмечает первого родителя, пунктирная — второго.
Сможете сказать, что произошло в этом репозитории?
главное: не требовать единомоментное отображение сообщений всех коммитов и прочей ёмкой информации на экране, иначе получим тот же gitk с ограничением 1 коммит на строку. Цель ведь обозреть происходящее в истории, что откуда куда попало. А метаинформацию можно показывать при наведении/нажатии или через переход в режим gitk-like сразу в окрестности выбранного на этом графе коммита.
Впрочем, соглашусь, что если бы была возможность сохранять в merge-коммите информацию о том, требовалось или не требовалось разрешение конфликтов, картинки принципиально можно было бы сделать проще.
Но объясните, в чём проблемы с т.н. железнодорожными путями?
Разве это не проблема исключительно визуализатора?
Скажем, выше приведена картинка просто отвратительнейшей визуализации орграфа.
Сходу нашел GitVersionTree и BranchMaster — наработки, но отражающие ключевую идую: двумерная визуализация орграфа для изучения/просмотра топологии веток.
Как мне кажется, если есть интегрируемый в среду разработки инструмент просмотра истории репозитория, страх перед ветвистостью историей существенно снизится и разработчики начнут выбирать инструмент (rebase vs merge) исходя из их целевого назначения, а не из страха иметь историю, которую встроенный визуализатор отображает запутанно.
1. Размер деревьев. Число токенов на порядок-два (зависит от ЯП) больше числа строк.
2. Деревья — двумерные структуры. СКВ работают преимущественно с классическими операциями Левенштейна (добавить, удалить, заменить строку). Много ли Вы знаете СКВ, которые бы отличали <удалить строку A №5 + вставить строку A перед строкой B №4> и <поменять местами строки B №4 и A №5> и корректно сливали эти патчи с другими? Для AST необходимо же исходно поддержить как горизонтальные операции (добавление/удаление дочернего поддерева), так и вертикальные (замена поддерева его дочерним поддеревом/замена поддерева T на C[T] для некоторого контекста C[] с одним подстановочным местом). Вроде бы это обстоятельство меняет асимптотическую сложность.
И ещё обращаю внимание, что получение диффа — более простая задача, чем построение модели (в т.ч. с конфликтным/бесконфликтным слиянием патчей) СКВ.
P.S. Я полностью согласен с последним: если когда-то СКВ научатся работать с AST и будет унифицированный формат деревьев, инструменты программирования шагнут на принципиально другой уровень удобства.
Кроме этого, научность, полезность и правильность — три разных понятия. Коррелирующих, но не эквивалентных.
В первом примере с XOR написано:
Один нейрон «голосует» за результат XOR-а, т.е. за 0 или 1, и возвращаемое значение из интервала [0,1] мы интерпретируем как 0 или 1 в зависимости от того, к какому краю интервала ближе, а отклонение — как меру возможной ошибки. Скажем, чем ближе к 0.5, тем сложнее коррекно интерпретировать результат. Верно?
В задаче с цифрами есть 10 различных вариантов, то есть мы хотим получить чуть больше 3 битов информации.
Если делать по аналогии с тем, что написал выше, то должно быть 4 выхода по числу бит, которые мы хотим получить.
Если же мы говорим, что каждому варианту должен соответствовать свой выход и нейросеть голосует за каждый вариант отдельно, то в задаче с XOR должно быть 2 выхода.
Если мы говорим, что в задаче с XOR достаточно одного выхода, потому что «голос за 0» = 1 — «голос за 1» и нечего подавать на выход избыточную информацию, то в задаче с цифрами должно быть 9 выходов.
В общем, не получается у меня согласовать два примера, отсюда и вопрос.
почему на выходе 10 нейронов по числу вариантов ответа, а не 4 по количеству фактической информации?
Сейчас добавлю в предисловие это замечание.
Поставлена задача написать функцию
(Nat -> Bool) -> Maybe Nat.Если вообще никаких ограничений на функцию Nat -> Bool не накладываются, задача неразрешима, поскольку (неформально говоря) за конечное время возможно проверить только конечное число вариантов, а никаких других способов пощупать эту функцию у нас нет.
Допустим, на функцию накладываются какие-то ограничения. Допустим, как ramntry предложил, её можно декомпоновать на примитивные равенства
f(x)==c. Для такого класса функций существует алгоритм, использующий эти параметры c, который позволяет за менее-чем-линейное время с постоянной памятью найти ответ. Однако какой тогда должна быть сигнатура функции?Недостаток эффективного подхода заключается в том, что для каждого класса функций, которые представляются в определённом параметрическом виде, нужно писать свой собственный алгоритм, который зависит от всех параметров функции и от всех других особенностей, знания о которых нужны алгоритму для решения поставленной задачи. Не возможно написать решатель
(Nat -> Bool) -> Maybe Nat, который бы использовал один из этих целевых алгоритмов, потому что такой решатель не будет иметь информации о «скрытых параметрах» функции.Один из способов обойти этот недостаток заключается в передачи всех параметров вместе с функцией. В любом случае появление нового класса функций, для которых задача может быть решена, приводят к необходимости переписывать всё либо жертвовать универсальностью решателя и создавать новую функцию.
Как бы то ни было, предложенная в статье функция способна решить задачу на весьма широком диапазоне функций, будучи универсальной и сравнительно простой. Такие неэффективные, но простые и универсальные решатели всегда занимают свою нишу: когда нужно быстро написать надёжный простой код, который хотя бы когда-нибудь выдаст правильный ответ с использованием сколько-угодно дополнительных ресурсов, чтобы использовать его едино- или несколькоразово.
С одной стороны понятно, что при наличии алгоритма, вычисляющего колмогоровскую энтропию всякой строки при фиксированном языке, получается противоречие.
С другой стороны, вручную для конкретного языка можно определить колмогоровскую сложность отдельных строк; стало быть, можно написать программу, которая для некоторых строк вычисляет их энтропию, а на остальных зависает или даёт сигнал, что не может их вычислить.
Можно ли сформировать максимальное перечислимое множество строк, для которой найдётся программа, считающая колмогоровскую сложность этих строк? Вопрос похож на заданный в видео: мы не можем определить энтропию всякой строки, но для некоторых же это сделать можно? Конечно, на такую программу хотелось бы накладывать ограничение, чтобы она сама знала, для каких строк она может посчитать, а для каких — нет.