Мы находимся в контексте данной статьи и работы Ландауэра, где операция стирания четко определена.
Довольно элементарный гейт с одним входом и одним выходом и с таблицей истинности: 0 -> 0, 1 -> 0 (неважно чем стираем, 0 как здесь, или 1). Что может быть элементарней? Гейт NOT (вот он уже, как понимаете, обратимый), который тоже с одним входом и одним выходом и то, пожалуй, чуть-чуть посложнее. И этим, собственно исчерпываются все одно-входные гейты.
В чем тут можно быть неуверенным? Очевидно, операция необратима.
Говорить тут, что в этом «Суть», имхо, как-то слишком громко. То, что стирание необратимая операция, это скорее не суть, а условие задачи (то что в «Дано:», то что тривиально), на то оно и стирание, что необратимо.
Почему покинет? Для 2к бит (2048 бит) статистика «пляшет» на значениях от 0 до 2^2048 - 1. Для 2-х бит от 0 до 3. Для 1 бита от 0 до 1. Какая принципиальная разница? Статистика же не на количестве бит (оно фиксировано), а на их значениях и чтобы не усложнять себе и так нелегкую жизнь, логично рассмотреть самый простой случай.
По условию задачи ничего не пляшет. Было одно значение бита. После стирания осталось старое или стало другое.
Когда берете конкретное значение бита (или 2к бит — неважно), то если посмотрите формулу Шеннона для энтропии (собственно определение энтропии), то получите S = 0, ибо для него вероятность 1, на то оно и конкретное значение. Энтропия на минимальном значении (0) и ее уже некуда понижать.
Термодинамика и температура же (о чем говорим) не о конкретных значениях. А там, где рассматриваем систему обобщенно-вероятностно, в свете общей статистики ее микросостояний (подобные расчеты и были выше).
Говорю, согласен, во всем этот есть некий мутный момент. Свою точку зрения как это понимаю изложил. Принцип Ландауэра от 1961 года — уже классика в которой никто не сомневается, так что нам остаться только попытаться его понять, вас тоже призываю искать понимание (vs непонимание), и если найдете понимание лучше приведенного, то, пожалуйста, прошу привести и объяснить (ну а если таки опровергните, так понимаю, получив возможность вечного двигателя 2-го рода, то получите нобелку).
Согласен, это действительно несколько мутный момент.
Прежде всего, для простоты, лучше взять не 2к бит, а 1 бит, суть от этого не изменится, а нам проще. Также важно не то, что стираем именно нулями (пусть те же 2к), можем стирать и единицами..., важно что стираем Конкретным выбранным числом (как вы предлагаете — предварительно выбрать такое число).
Для себя так понимаю этот момент: Согласно термодинамическому подходу мы абстрагируемся от микросостояний (термодинамика будучи феноменологической о них ничего не знает, а стат. физика согласно своему названию рассматривает микросостояния статистически), т.е. рассматриваем бит как черный ящик, но при этом держа в голове и нижележащую стат. физику, а именно, что бит имеет микросостояния {0, 1}.
Как писал под спойлером выше, эта тема подпадает под описания в терминах разных «языков» — с одной стороны термодинамики, с другой стат. физики (по сути теории вероятности). Эти неразрывно связанные области описывают системы обобщенно, с точки зрения статистики, средних значений (та же температура в стат. физике это мера Средней кинетической энергии хаотического движения микрочастиц)... Поэтому, если хотим говорить о температуре, нужно говорить в терминах средних, статистически. Для системы бита статистика пляшет на значениях {0, 1}. В среднем с вероятностью 1/2 для каждого.
И далее, как писал в комменте выше, считаем соответствующую исходную энтропию: S = -p0⋅log(p0) - p1⋅log(p1) = 1/2 + 1/2 = 1
После стирания же, неважно, что выбрали 0 или 1, система бита будет с вероятностью 1 находится в конкретном состоянии. log(1) = 0 и => энтропия станет: S = 0
Там есть мой коммент (@vadimn6393) и автор почему-то даже закрепил его в топе, ответив на него. На что в тот же день написал свой ответ (проведя некоторые изыскания), однако, автор, непонятно почему, запретил любые комментарии к своему видео (что было несколько разочаровывающе — писал ответ, потратил время и облом).
Приведу хотя бы здесь этот ответ. Это в тему статьи. Возможно, будет кому-то интересно, кому-то дискуссионно (ну а кому-то не интересно — дополнительный «выход гейта», чтобы температура не повышалась, ЕВПОЧЯ ) ) :
Скрытый текст
Что такое фазовое пространство в курсе. И, кстати, по отношению к биту говорить, что его фазовое пространство это {0, 1} не совсем корректно, скорее следует говорить о конфигурационном пространстве или пространстве состояний.
Конфигурационное пространство — это пространство всех возможных состояний, в которых может находится система. Фазовое пространство — это пространство состояний + структура, которая позволяет эволюции быть детерминированной из любой точки этого пространства. Зная точку в этом пространстве, можно предсказать следующий шаг. В классической механике это координата + импульс.
И если с поршнем все понятно, хотя тут скорее следует применить уравнение Клапейрона-Менделеева P⋅ V / T = N⋅ k_B (= const). Однако же, аналогии мало что доказывают. Бит это своя система, обычно там нет поршней (хотя наверное и можно предложить реализацию на поршнях), сейчас это кремневая электроника, где ничего не деформируется.
Что мне не хватило? Привели формулу, так сказать, «с неба». Вроде наукообразно, но по сути ничего не объясняет — логическая лакуна. Хочется не формулу «с потолка», а принципы, понимание сути. Апелляция ко 2-му началу термодинамики на 4:28, уже лучше. Похоже здесь зарыта суть. И вот здесь бы, не парой слов, а более углубится.
2-е начала термодинамики, по сути очевидно: в замкнутой системе энтропия (логарифм стат.веса) может только расти, т.е. эволюция системы происходит в сторону более вероятного состояния. Очевидное следствие теории вероятности.
Стирание информации это логический вентиль с таблицей истинности: 0 -> 0, 1 -> 0. Очень простая система и эволюция. Для таких систем, где уже проще некуда, по идее должно быть особое упрощенное понимание и вывод результата, чем для общего случая. Вот его бы и разжевать до самой сути.
Попробую без формулы Ландауэра (но строго): Пусть исходно бит находится в равновесии, т.е. в состоянии с равной (1/2) вероятностью 0 или 1. Энтропия по Шеннону (она же эквивалентна информации) для бита с вероятностями (простая математика, не Ландауэр, а база, определение понятия): S = -p0⋅log(p0) - p1⋅log(p1) = 1/2 + 1/2 = 1 здесь log двоичный)
После стирания состояние всегда 0 (вероятность 1 и log(1) = 0) => энтропия: S = 0
Но энтропия системы не может просто исчезнуть. Согласно 2-му началу, энтропия замкнутой системы не убывает. Наш бит — Не Замкнутая система (!) и общая энтропия "бит" + "окружение" не должна уменьшаться. Если энтропия бита упала на 1, то энтропия окружения должна вырасти как минимум на 1.
Определение энтропии в стат. физике: S = k_B ⋅ ln(2)
W - статистический вес, т.е. число различных микросостояний, т.е. в нашем случае:
S = k_B ⋅ ln(2)
Как растет энтропия окружения? Только через тепло (Q). В термодинамике, 2-е начало можно так записать: dS >= δQ / T (но выводится из стат. физики, т.е. по сути упомянутое следствие теории вероятности, просто переформулированное в терминах термодинамики)
Вот тут и возникает формула Ландауэра (ибо dQ это и есть E что у вас в видео). Удивительно — вывелась, даже не ожидал, начиная рассуждать. Не так уж и страшен этот Ландауэр — на школьном уровне :) Но, наверное, можно еще проще (все таки бит).
В общем суть/база в том, что система (бит + окружение) эволюционирует в статистически более вероятное состояние (2-е начало) — очевидно. Остальное разговор о терминах, где лишь Переформулируем (!) из статистических терминов в термины термодинамики. Термодинамика феноменологическая теория, ее термины условны. Суть же — теория вероятности, остальное манипуляция терминами.
Правильно понимаю, что «Цзючжан 4.0» не является универсальным квантовым компьютером? А устройством заточенным под решения более узкого круга «квантовых задач» (может быть как раз только задачи «гауссовой бозонной выборки»)?
Ибо пытался понять сколько логических кубитов у этой машинки (не путать с физическими, которых может быть в сотни раз больше и которые служат для коррекции ошибок). В статье об этом нет инфы. Гугл же выдал: «Цзючжан 4.0 не имеет логических кубитов в традиционном понимании. Он использует принципиально другую архитектуру — бозонное семплирование на основе фотонов».
У вас практически все ссылки на github не рабочие (по крайней мере на момент написания этого поста). Проверьте пожалуйста (возможно, забыли сделать репозиторий публичным).
• Добавлена возможность задавать типы через их имена. Может быть полезна, если «аттрактор» и «друг» находятся в разных сборках. Обычно решается через DI (как известно, DIP часть рекомендуемых SOLID принципов) с определением правил уже на интерфейсах. Но если не хотим или не можем через DI, то тут и поможет эта новая фича. Спасибо gBear за обсуждение, которое и «спровоцировало» эту фичу. См. новый раздел: Если «аттрактор» и «друг» в разных сборках.
• Добавлена возможность задавать любые имена не только простыми строками, но и регулярными выражениями. См. новый раздел: Используем регулярные выражения.
Если аттрактор и друг это типы из разных сборок, то возникает циклическая зависимость между сборками.
Понял вас. В принципе вы правы. А чтобы не было циклической зависимостей (но не только), такие зависимости обычно принято выносить в отдельную сборку (какую-нибудь «Contracts») в виде интерфейсов, даже рекомендуется как часть SOLID принципов — DIP. Тогда можно будет без проблем определять правила на интерфейсах.
Но спасибо вам, что подсказали вариант доработки аналайзера, для случаев если не хотим это делать. Решается просто: например, добавить для OnlyYou атрибута еще один конструктор с таким использованием: [OnlyYou("T:MyFriend",...)] Ибо аналайзеру, в принципе, достаточно лишь имени типа.
Как я понимаю, мы о разных "трех не" говорим.
Пожалуй, оставим это правило в плюсах, чтобы не уводить дискуссию в сторону. Это своя тема.
И ассоциация с плюсовыми френдами только путает. Обсуждаемый псевдо-модификатор это не френды (плюсовые френды критикую в статье), а это коротко говоря: public с правилами.
И следующая ваша цитата, мне кажется, продиктована этой путаницей с плюсами:
Опять же... если кто-то, что-то "видит" - он имеет полное право за это "дергать". И - скажем так - "прикладная задача проектирования" сводится к "надо сделать так, чтобы каждый видел только то, что ему можно дергать". А вы - буквально - говорите "а давайте на это всё забьем" :-)
По примерам с nested классами и вообще о nested решениях: Во первых попадаем под то проклятие — «эксбиционизм» плюсовых френдов (если используем именно inner класс как есть). Не можем сделать один и тот же класс как nested сразу 2-х классов Менее селективно. Не всегда правильно загонять класс в nested (по моему опыту необходимости в элвис-модификаторе возникала в таких классах, которые ну совсем не годились чтобы из них делать nested пары).
Приведу такой сравнительный пример:
Скрытый текст
namespace NestedTest
{
class Me
{
private string _veryConfidentialValue = "top secret";
private void Method1() { }
public void Method2()
{
var friend = new Friend(); // ok
friend.SomeMethod(); // ok
}
public class Friend
{
public Friend() { }
public void UseMe1(Me me)
{
me.Method1();
var getAnySecret = me._veryConfidentialValue; // ok
me._veryConfidentialValue = "hack any secret"; // ok
}
public void UseMe2(Me2 me2)
{
me2.Method1(); // err
}
public void SomeMethod()
{
var me = new Me();
}
}
}
class Me2
{
private void Method1() { }
}
class Other
{
public void UseMe1(Me me)
{
var friend = new Me.Friend(); // ok
friend.SomeMethod(); // ok
}
}
}
namespace EATest
{
class Me
{
private string _verySecureValue = "top secret";
public Me() { }
[OnlyYou<Friend>(nameof(Friend.UseMe1))]
public void Method1() { }
public void Method2()
{
var friend = new Friend(); // ok
friend.SomeMethod(); // err
}
}
class Me2
{
public void Method1() { }
}
class Friend
{
[OnlyYou<Me>]
public Friend() { }
public void UseMe1(Me me)
{
me.Method1(); // ok
var getAnySecret = me._veryConfidentialValue; // err
me._veryConfidentialValue = "hack any secret"; // err
}
public void UseMe2(Me2 me2)
{
me2.Method1(); // ok
}
[OnlyYou<Me>(nameof(Me.Method2))]
public void SomeMethod() { }
}
class Other
{
public void UseMe1(Me me)
{
var friend = new Friend(); // err
friend.SomeMethod(); // err
}
}
}
Ну вы чего?! Через neasted объявляются агрегаты (сильно упрощая - интерфейсы), которые потом используются для "сборки" того, что вам нужно где-то "во вне".
Насколько вас понял, под агрегатами (интерфейсы) имеете ввиду определять интерфейсы (или (абстрактные) классы) как nested с реализацией доступа с приватному функционалу внешнего, а потом где нужно наследоваться от этих интерфейсов. Т.е. ровно то, что я описывал в разделе статьи «Через интерфейс» (очевидно, интерфейсов может быть сколько угодно). Ну а далее предложил и другой подход в виде псевдо-модификатора.
Спасибо! Прежде всего отмечу, что, имхо, польза может быть особенно в проектах с большим, сложным внутреннем API, где важно строгое соблюдения контрактов/бизнес-логики.
Сборок может быть сколько надо, нет ограничений, главное чтобы аналайзер был ко всем ним подключен, или подключен хотя бы пакет с атрибутам, если в какой-то сборке функции аналайзера не нужны, но атрибуты используются (если все в одном сольюшене, то предлагался Directory.Build.props).
Например, достаточно "представить", что "аттрактор" и "друг" это типы из разных сборок. "Лишняя" связь тут же станет очевидной. Нет?
В разных они сборках или нет, в любом случае, они знают друг о друге (иначе как декларацию декларировать?). Знают и используют (уже имеем связь), если же не используют, то писал о варининге и TODO (или, наоборот, можно сказать, UNDO индикаторе, если оказался просчет в начальном проектировании).
Вот как раз "через интерфейс" исходная задача решается "с точностью до наоборот". В том смысле, что исходная "сущность" - мутабельная, а через реализацию интерфейса предоставляется readonly проекция. Нет? При таком подходе, "грануляция" доступа - пока отбросив её ценность - органично "схлопывается" до агрегатов. Оно может быть и выглядит громоздко на синтетике, но смотрится вполне себе нормально и логично (отбросив, опять же, всё остальное, что можно "предъявить" такому агрегату).
Исходная сущность (класс Me) внешне как раз не мутабельная (readonly), а "через интерфейс" предоставляется строго избирательная "проекция" с доступом к внешне скрытым или/и readonly мемберам. Простите, про агрегацию, плохо вас понял. Имеете ввиду inner/nested классы (когда inner класс может получать доступ к закрытым мемберам outer класса)?
Про френды в C++ уже который раз пожалел, что вообще упомянул, они лишь начальная ассоциация, и, смотрю, каждый раз, «вызывают на себя огонь». Вот их можем отбросить, они лишь путают в понимании. (а правило "три не" в плюсах, хорошее правило, если бы еще все его знали и использовали, это ведь только благое пожелание, а не запреты на уровне синтаксиса языка).
Помимо основного тела статьи, в «Приложении» сделал много примеров задач с возможным применением, обоснованием зачем. Думал достаточно (можно попробовать их решать другими методами, не спорю, и тогда уж сравнить что будет проще/лаконичнее...).
Когда вы говорите про "торчащие нитки", вы вообще о чём?
Про «торчащие нитки» (образное выражение), за которые могут дергать (т.е. использовать эти нитки-мемберы/классы: вызывать методы, сеттить свойства...) все (ну почти все с учетом более глобальных модификаторов) в том числе и те кому не желательно согласно контракту (это иллюстрировал в примерах).
Складывается ощущение что вам кто-то строго запретил пользоваться internal (и его производными) уровнем доступа и использовать neasted иерархии.
internal и nested не дает той гибкости и селективности, как данный модификатор. internal работает «по площадям». nested не всегда возможен (а если нужен как nested сразу в нескольких классах? а если нужен «взаимный» nested?) и удобен, и он получает доступ сразу ко всем приватным мемберам outer класса (фактически как в плюсах в варианте не function friend), что не есть хорошо.
Про оценку ценности тут, конечно, пусть каждый сам приценяется, насколько ему интересен данный функционал (сугубо лично мне интересен).
Withkittens Спасибо за профессиональный пост! Вы правы, есть разные решения, которые не умоляю. Да, и в Rust есть, что хотелось бы иметь и в C#. Предлагаемый вариант, имхо, все же гибче, селективнее описанных вами подходов. В примерах в «Приложении» попытался показать применения. Возможно дело привычки (всегда кажется лучше и проще то к чему привык). Наверное пристрастен, только, имхо, просто поставить на мембере или классе/интерфейсе атрибут с вполне очевидным смыслом (Только Ты <T>), не так уж напряженно. Вот вы, как понял, профи и в Rust, вот там, имхо, действительно сложные вещи (как минимум за себя скажу — ломал мозги когда изучал).
Ну почему "прибиты гвоздями", вот новые появляются как тот же file модификатор. И, конечно, в CLR не лезу, кто же мне позволит? Ну назвал модификатором инструмент, который фактически выполняет функцию модификатора. Вы не согласны с названием, понял вас, уважаю ваше мнение (говорю, даже ни одного минуса не поставил вам в отличии от вас, после моих ответов). Смысл дальше спорить? (и не я его начинал, лишь вежливо отвечаю вам)
Потому как этот атрибут фактически и выполняет функцию модификатора доступа, конечно, нового модификатора не входящего в стандарт. Поэтому счел возможным назвать как модификатор. У нас с вами дискуссии по названиям. Имхо, названия не столь важны как суть, предлагаю не продолжать их.
Увы, авторитетных доказательств что именно в C# тернарный оператор называется еще и Элвис оператором вы не привели. Уважаю ваше мнение и право называть что-либо как вы хотите, но пока тот же гугл не разделяет его. Даже не минусую ваши посты (в отличии от вас).
В статье же речь не об операторе, а о модификаторе, так что какая путаница?
И, поверьте, не «лезу в бутылку», готов признавать свои ошибки (буду только благодарен если укажите на них, ставлю за них лайки, как тут ниже для chegeras и вам готов поставить), готов узнавать что-то новое. Просто пока не понимаю вас.
И опять замечу, что речь в статье о C#, не о Kotlin. В C# именно вот так ?: одной строкой вообще нет такого оператора.
На счет "?:" не встречал чтобы называли его "Elvis operator". Классический Элвис-олератор, как верно далее пишете, это "??" (также как и "?.", тоже относится к Элвис семейству операторов).
В каком-то смысле модификатор и защищает, только не от NullReferenceException, а от нарушения бизнес-логики/контракта. Если бы не было «Elvis оператора», то наверное и не подумал так назвать модификатор, а так дорога уже проложена, считайте традиция, да и для «маркетинга», имхо, хорошее название (в кавычках, потому как какой маркетинг при MIT лицензии).
Не совсем понимаю, что имеете ввиду?
Мы находимся в контексте данной статьи и работы Ландауэра, где операция стирания четко определена.
Довольно элементарный гейт с одним входом и одним выходом и с таблицей истинности: 0 -> 0, 1 -> 0 (неважно чем стираем, 0 как здесь, или 1). Что может быть элементарней? Гейт NOT (вот он уже, как понимаете, обратимый), который тоже с одним входом и одним выходом и то, пожалуй, чуть-чуть посложнее. И этим, собственно исчерпываются все одно-входные гейты.
В чем тут можно быть неуверенным? Очевидно, операция необратима.
Говорить тут, что в этом «Суть», имхо, как-то слишком громко. То, что стирание необратимая операция, это скорее не суть, а условие задачи (то что в «Дано:», то что тривиально), на то оно и стирание, что необратимо.
Почему покинет? Для 2к бит (2048 бит) статистика «пляшет» на значениях от 0 до 2^2048 - 1. Для 2-х бит от 0 до 3. Для 1 бита от 0 до 1. Какая принципиальная разница? Статистика же не на количестве бит (оно фиксировано), а на их значениях и чтобы не усложнять себе и так нелегкую жизнь, логично рассмотреть самый простой случай.
Когда берете конкретное значение бита (или 2к бит — неважно), то если посмотрите формулу Шеннона для энтропии (собственно определение энтропии), то получите S = 0, ибо для него вероятность 1, на то оно и конкретное значение. Энтропия на минимальном значении (0) и ее уже некуда понижать.
Термодинамика и температура же (о чем говорим) не о конкретных значениях. А там, где рассматриваем систему обобщенно-вероятностно, в свете общей статистики ее микросостояний (подобные расчеты и были выше).
Говорю, согласен, во всем этот есть некий мутный момент. Свою точку зрения как это понимаю изложил.
Принцип Ландауэра от 1961 года — уже классика в которой никто не сомневается, так что нам остаться только попытаться его понять, вас тоже призываю искать понимание (vs непонимание), и если найдете понимание лучше приведенного, то, пожалуйста, прошу привести и объяснить (ну а если таки опровергните, так понимаю, получив возможность вечного двигателя 2-го рода, то получите нобелку).
Согласен, это действительно несколько мутный момент.
Прежде всего, для простоты, лучше взять не 2к бит, а 1 бит, суть от этого не изменится, а нам проще.
Также важно не то, что стираем именно нулями (пусть те же 2к), можем стирать и единицами..., важно что стираем Конкретным выбранным числом (как вы предлагаете — предварительно выбрать такое число).
Для себя так понимаю этот момент:
Согласно термодинамическому подходу мы абстрагируемся от микросостояний (термодинамика будучи феноменологической о них ничего не знает, а стат. физика согласно своему названию рассматривает микросостояния статистически), т.е. рассматриваем бит как черный ящик, но при этом держа в голове и нижележащую стат. физику, а именно, что бит имеет микросостояния {0, 1}.
Как писал под спойлером выше, эта тема подпадает под описания в терминах разных «языков» — с одной стороны термодинамики, с другой стат. физики (по сути теории вероятности). Эти неразрывно связанные области описывают системы обобщенно, с точки зрения статистики, средних значений (та же температура в стат. физике это мера Средней кинетической энергии хаотического движения микрочастиц)...
Поэтому, если хотим говорить о температуре, нужно говорить в терминах средних, статистически. Для системы бита статистика пляшет на значениях {0, 1}. В среднем с вероятностью 1/2 для каждого.
И далее, как писал в комменте выше, считаем соответствующую исходную энтропию:
S = -p0⋅log(p0) - p1⋅log(p1) = 1/2 + 1/2 = 1
После стирания же, неважно, что выбрали 0 или 1, система бита будет с вероятностью 1 находится в конкретном состоянии. log(1) = 0 и => энтропия станет:
S = 0
и т.д., не буду повторяться.
Автору Спасибо (и лайк) за статью!
Кстати, пару недель назад на ютубе вышло видео с подобной тематикой: «Принцип Ландауэра и предел развития искусственного интеллекта. Объяснение» (про ИИ видимо для кликабельности добавлено, мол кто будет читать, если не упомянута эта хайповая тема).
Там есть мой коммент (
@vadimn6393) и автор почему-то даже закрепил его в топе, ответив на него. На что в тот же день написал свой ответ (проведя некоторые изыскания), однако, автор, непонятно почему, запретил любые комментарии к своему видео (что было несколько разочаровывающе — писал ответ, потратил время и облом).Приведу хотя бы здесь этот ответ. Это в тему статьи. Возможно, будет кому-то интересно, кому-то дискуссионно (ну а кому-то не интересно — дополнительный «выход гейта», чтобы температура не повышалась, ЕВПОЧЯ ) ) :
Скрытый текст
Что такое фазовое пространство в курсе. И, кстати, по отношению к биту говорить, что его фазовое пространство это {0, 1} не совсем корректно, скорее следует говорить о конфигурационном пространстве или пространстве состояний.
Конфигурационное пространство — это пространство всех возможных состояний, в которых может находится система.
Фазовое пространство — это пространство состояний + структура, которая позволяет эволюции быть детерминированной из любой точки этого пространства. Зная точку в этом пространстве, можно предсказать следующий шаг. В классической механике это координата + импульс.
И если с поршнем все понятно, хотя тут скорее следует применить уравнение Клапейрона-Менделеева P⋅ V / T = N⋅ k_B (= const). Однако же, аналогии мало что доказывают. Бит это своя система, обычно там нет поршней (хотя наверное и можно предложить реализацию на поршнях), сейчас это кремневая электроника, где ничего не деформируется.
Что мне не хватило?
Привели формулу, так сказать, «с неба». Вроде наукообразно, но по сути ничего не объясняет — логическая лакуна. Хочется не формулу «с потолка», а принципы, понимание сути.
Апелляция ко 2-му началу термодинамики на 4:28, уже лучше. Похоже здесь зарыта суть. И вот здесь бы, не парой слов, а более углубится.
2-е начала термодинамики, по сути очевидно: в замкнутой системе энтропия (логарифм стат.веса) может только расти, т.е. эволюция системы происходит в сторону более вероятного состояния. Очевидное следствие теории вероятности.
Стирание информации это логический вентиль с таблицей истинности: 0 -> 0, 1 -> 0.
Очень простая система и эволюция. Для таких систем, где уже проще некуда, по идее должно быть особое упрощенное понимание и вывод результата, чем для общего случая. Вот его бы и разжевать до самой сути.
Попробую без формулы Ландауэра (но строго):
Пусть исходно бит находится в равновесии, т.е. в состоянии с равной (1/2) вероятностью 0 или 1.
Энтропия по Шеннону (она же эквивалентна информации) для бита с вероятностями (простая математика, не Ландауэр, а база, определение понятия):
S = -p0⋅log(p0) - p1⋅log(p1) = 1/2 + 1/2 = 1 здесь log двоичный)
После стирания состояние всегда 0 (вероятность 1 и log(1) = 0) => энтропия:
S = 0
Но энтропия системы не может просто исчезнуть. Согласно 2-му началу, энтропия замкнутой системы не убывает. Наш бит — Не Замкнутая система (!) и общая энтропия "бит" + "окружение" не должна уменьшаться. Если энтропия бита упала на 1, то энтропия окружения должна вырасти как минимум на 1.
Определение энтропии в стат. физике:
S = k_B ⋅ ln(2)
W - статистический вес, т.е. число различных микросостояний, т.е. в нашем случае:
S = k_B ⋅ ln(2)
Как растет энтропия окружения? Только через тепло (Q). В термодинамике, 2-е начало можно так записать:
dS >= δQ / T
(но выводится из стат. физики, т.е. по сути упомянутое следствие теории вероятности, просто переформулированное в терминах термодинамики)
Вот тут и возникает формула Ландауэра (ибо dQ это и есть E что у вас в видео).
Удивительно — вывелась, даже не ожидал, начиная рассуждать. Не так уж и страшен этот Ландауэр — на школьном уровне :) Но, наверное, можно еще проще (все таки бит).
В общем суть/база в том, что система (бит + окружение) эволюционирует в статистически более вероятное состояние (2-е начало) — очевидно. Остальное разговор о терминах, где лишь Переформулируем (!) из статистических терминов в термины термодинамики. Термодинамика феноменологическая теория, ее термины условны. Суть же — теория вероятности, остальное манипуляция терминами.
Правильно понимаю, что «Цзючжан 4.0» не является универсальным квантовым компьютером? А устройством заточенным под решения более узкого круга «квантовых задач» (может быть как раз только задачи «гауссовой бозонной выборки»)?
Ибо пытался понять сколько логических кубитов у этой машинки (не путать с физическими, которых может быть в сотни раз больше и которые служат для коррекции ошибок). В статье об этом нет инфы. Гугл же выдал: «Цзючжан 4.0 не имеет логических кубитов в традиционном понимании. Он использует принципиально другую архитектуру — бозонное семплирование на основе фотонов».
У вас практически все ссылки на github не рабочие (по крайней мере на момент написания этого поста). Проверьте пожалуйста (возможно, забыли сделать репозиторий публичным).
UPD статьи от 2026-04-04
• Добавлены
[Exclude*]атрибуты.См. новый раздел: Exclude* атрибуты.
• Добавлены
[OnlyNs*]атрибуты.См. новый раздел: Подключаем неймспейсы.
UPD статьи от 2026-03-18
• Добавлена возможность задавать типы через их имена. Может быть полезна, если «аттрактор» и «друг» находятся в разных сборках. Обычно решается через DI (как известно, DIP часть рекомендуемых SOLID принципов) с определением правил уже на интерфейсах. Но если не хотим или не можем через DI, то тут и поможет эта новая фича. Спасибо gBear за обсуждение, которое и «спровоцировало» эту фичу.
См. новый раздел: Если «аттрактор» и «друг» в разных сборках.
• Добавлена возможность задавать любые имена не только простыми строками, но и регулярными выражениями.
См. новый раздел: Используем регулярные выражения.
Понял вас. В принципе вы правы.
А чтобы не было циклической зависимостей (но не только), такие зависимости обычно принято выносить в отдельную сборку (какую-нибудь «Contracts») в виде интерфейсов, даже рекомендуется как часть SOLID принципов — DIP. Тогда можно будет без проблем определять правила на интерфейсах.
Но спасибо вам, что подсказали вариант доработки аналайзера, для случаев если не хотим это делать.
Решается просто: например, добавить для
OnlyYouатрибута еще один конструктор с таким использованием:[OnlyYou("T:MyFriend",...)]Ибо аналайзеру, в принципе, достаточно лишь имени типа.
Пожалуй, оставим это правило в плюсах, чтобы не уводить дискуссию в сторону. Это своя тема.
И ассоциация с плюсовыми френдами только путает.
Обсуждаемый псевдо-модификатор это не френды (плюсовые френды критикую в статье), а это коротко говоря:
publicс правилами.И следующая ваша цитата, мне кажется, продиктована этой путаницей с плюсами:
По примерам с nested классами и вообще о nested решениях:
Во первых попадаем под то проклятие — «эксбиционизм» плюсовых френдов (если используем именно inner класс как есть).
Не можем сделать один и тот же класс как nested сразу 2-х классов
Менее селективно.
Не всегда правильно загонять класс в nested (по моему опыту необходимости в элвис-модификаторе возникала в таких классах, которые ну совсем не годились чтобы из них делать nested пары).
Приведу такой сравнительный пример:
Скрытый текст
Насколько вас понял, под агрегатами (интерфейсы) имеете ввиду определять интерфейсы (или (абстрактные) классы) как nested с реализацией доступа с приватному функционалу внешнего, а потом где нужно наследоваться от этих интерфейсов.
Т.е. ровно то, что я описывал в разделе статьи «Через интерфейс» (очевидно, интерфейсов может быть сколько угодно). Ну а далее предложил и другой подход в виде псевдо-модификатора.
Спасибо!
Прежде всего отмечу, что, имхо, польза может быть особенно в проектах с большим, сложным внутреннем API, где важно строгое соблюдения контрактов/бизнес-логики.
Сборок может быть сколько надо, нет ограничений, главное чтобы аналайзер был ко всем ним подключен, или подключен хотя бы пакет с атрибутам, если в какой-то сборке функции аналайзера не нужны, но атрибуты используются (если все в одном сольюшене, то предлагался
Directory.Build.props).В разных они сборках или нет, в любом случае, они знают друг о друге (иначе как декларацию декларировать?). Знают и используют (уже имеем связь), если же не используют, то писал о варининге и TODO (или, наоборот, можно сказать, UNDO индикаторе, если оказался просчет в начальном проектировании).
Исходная сущность (класс
Me) внешне как раз не мутабельная (readonly), а"через интерфейс" предоставляется строго избирательная "проекция" с доступом к внешне скрытым или/и readonly мемберам.
Простите, про агрегацию, плохо вас понял. Имеете ввиду inner/nested классы (когда inner класс может получать доступ к закрытым мемберам outer класса)?
Про френды в C++ уже который раз пожалел, что вообще упомянул, они лишь начальная ассоциация, и, смотрю, каждый раз, «вызывают на себя огонь». Вот их можем отбросить, они лишь путают в понимании.
(а правило "три не" в плюсах, хорошее правило, если бы еще все его знали и использовали, это ведь только благое пожелание, а не запреты на уровне синтаксиса языка).
Помимо основного тела статьи, в «Приложении» сделал много примеров задач с возможным применением, обоснованием зачем. Думал достаточно (можно попробовать их решать другими методами, не спорю, и тогда уж сравнить что будет проще/лаконичнее...).
Про «торчащие нитки» (образное выражение), за которые могут дергать (т.е. использовать эти нитки-мемберы/классы: вызывать методы, сеттить свойства...) все (ну почти все с учетом более глобальных модификаторов) в том числе и те кому не желательно согласно контракту (это иллюстрировал в примерах).
internal и nested не дает той гибкости и селективности, как данный модификатор.
internal работает «по площадям».
nested не всегда возможен (а если нужен как nested сразу в нескольких классах? а если нужен «взаимный» nested?) и удобен, и он получает доступ сразу ко всем приватным мемберам outer класса (фактически как в плюсах в варианте не function friend), что не есть хорошо.
Про оценку ценности тут, конечно, пусть каждый сам приценяется, насколько ему интересен данный функционал (сугубо лично мне интересен).
Withkittens Спасибо за профессиональный пост!
Вы правы, есть разные решения, которые не умоляю. Да, и в Rust есть, что хотелось бы иметь и в C#.
Предлагаемый вариант, имхо, все же гибче, селективнее описанных вами подходов. В примерах в «Приложении» попытался показать применения. Возможно дело привычки (всегда кажется лучше и проще то к чему привык). Наверное пристрастен, только, имхо, просто поставить на мембере или классе/интерфейсе атрибут с вполне очевидным смыслом (Только Ты
<T>), не так уж напряженно. Вот вы, как понял, профи и в Rust, вот там, имхо, действительно сложные вещи (как минимум за себя скажу — ломал мозги когда изучал).Ну почему "прибиты гвоздями", вот новые появляются как тот же file модификатор. И, конечно, в CLR не лезу, кто же мне позволит? Ну назвал модификатором инструмент, который фактически выполняет функцию модификатора. Вы не согласны с названием, понял вас, уважаю ваше мнение (говорю, даже ни одного минуса не поставил вам в отличии от вас, после моих ответов). Смысл дальше спорить? (и не я его начинал, лишь вежливо отвечаю вам)
Потому как этот атрибут фактически и выполняет функцию модификатора доступа, конечно, нового модификатора не входящего в стандарт. Поэтому счел возможным назвать как модификатор.
У нас с вами дискуссии по названиям. Имхо, названия не столь важны как суть, предлагаю не продолжать их.
Увы, авторитетных доказательств что именно в C# тернарный оператор называется еще и Элвис оператором вы не привели. Уважаю ваше мнение и право называть что-либо как вы хотите, но пока тот же гугл не разделяет его. Даже не минусую ваши посты (в отличии от вас).
В статье же речь не об операторе, а о модификаторе, так что какая путаница?
Пожалуйста, приведите мне к-л авторитетное руководство по C#, где тернарный оператор называли бы элвис оператором. может плохо ищу:
https://www.google.com/search?q=Тернарный+оператор+и+Элвис+оператор+это+одно+и+тоже+в+C%23%3F&newwindow=1&client=opera&hs=Xco&sca_esv=2da575c93e33c7c8&sxsrf=ANbL-n7Jsk_eBKYYWIR76J2l42pvuAoU1Q%3A1773574077816&ei=vZe2aZrGMd39wPAP0tuvuQI&biw=912&bih=501&ved=0ahUKEwjamJCn5qGTAxXdPhAIHdLtKycQ4dUDCBE&uact=5&oq=Тернарный+оператор+и+Элвис+оператор+это+одно+и+тоже+в+C%23%3F
И, поверьте, не «лезу в бутылку», готов признавать свои ошибки (буду только благодарен если укажите на них, ставлю за них лайки, как тут ниже для chegeras и вам готов поставить), готов узнавать что-то новое. Просто пока не понимаю вас.
И опять замечу, что речь в статье о C#, не о Kotlin. В C# именно вот так
?:одной строкой вообще нет такого оператора.Это в Kotlin. В C# же (наш контекст) "?:" все же принято называть тернарным оператором (очень старый оператор еще до Элвис оператора):
https://www.google.com/search?client=opera&q=what+is+"%3F%3A"+operator+in+c%23%3F&sourceid=opera&ie=UTF-8&oe=UTF-8
и, как минимум, гугл не согласен называть его Элвис оператором в C#:
https://www.google.com/search?client=opera&q="%3F%3A"+operator+in+c%23+is+Elvis+operator%3F&sourceid=opera&ie=UTF-8&oe=UTF-8
Спасибо большое! Верно, в первой строчке опечатка, вы правы, конечно, должно быть:
me: 100; friend: -40Поправил.
На счет "?:" не встречал чтобы называли его "Elvis operator". Классический Элвис-олератор, как верно далее пишете, это "??" (также как и "?.", тоже относится к Элвис семейству операторов).
В каком-то смысле модификатор и защищает, только не от NullReferenceException, а от нарушения бизнес-логики/контракта.
Если бы не было «Elvis оператора», то наверное и не подумал так назвать модификатор, а так дорога уже проложена, считайте традиция, да и для «маркетинга», имхо, хорошее название (в кавычках, потому как какой маркетинг при MIT лицензии).