Хорошая статья. Но вы здесь (наряду с классиками) рассматриваете идеи лишь применительно к материальному, в то время как есть же ещё социум. В котором обитают такие идеи как "релокация", "замутить стартап", "сколотить рок-группу", "доказать теорему Ферма без смс и регистрации", "выйти замуж за миллионера" и всё такое. Идеи, которым некоторые не могут противостоять и которые непосредственно управляют нашей жизнью.
Ну назовите это как "асинхронный конечный автомат", суть от этого не меняется. Состояния явно прописаны, их количество конечно, в один момент времени существует только одно детерминированное состояние.
Маленький не получится, для этого придётся какой-то игрушечный пример придумывать.
Ну вот например у меня есть объект для вывода звука одновременно на несколько устройств, и у него есть такие состояния, которые должны проходить последовательно:
Запросы на изменение состояния обрабатывается в начале каждого. И если запрос на остановку приходит при переходе с INIT_DEVICES на START_DEVICES - то состояния WAIT_FOR_BUFFERS и STOP_DEVICES можно пропустить и переходить сразу на FREE_DEVICES. А в состояниях STOPPED, STOP_DEVICES и FREE_DEVICES его отслеживать не имеет смысла.
Соответственно запрос на старт имеет смысл обрабатывать только в состоянии STOPPED, а объект в состоянии STOPPED висит на блокирующем событии, чтобы не расходовать зря процессорное время, поэтому об этом нужно дополнительно просигнализировать объекту межпоточной синхронизации, прямой доступ к которому давать снаружи тоже не самая лучшая идея.
Тут разница в том, что в одном случае нерадивый коллега дёргает стоп-кран, а в другом случае - вежливо просит машиниста поезда остановиться. А машинист поезда может его так же вежливо послать ждать следующей остановки.
А вы говорите, зачем нужно ООП. Чтобы State снаружи нельзя было изменять, вот зачем. Я конечные автоматы тоже предпочитаю делать в отдельном потоке, а управление через методы типа bool Stop() {must_stop=true;}, где must_stop - это приватный флаг и будет обработан там, где надо.
Поясняю: то был тонкий намёк на то, что вам не известно про понятие лапласиана, иначе вы не выбрали бы этот символ (так как он уже занят и общепринят). То есть автоматически классифицирует вас в группу дилетантов, ищущих решения сложных задач простыми, но "хитрыми" способами.
Это же и главный критерий, по которой я пропускаю подобные статьи не читая (не в обиду автору). Настоящие математики называют свои работы по сути, а остальное делает уже история и признание других математиков. Например, оригинальная работа Чебышева про его знаменитые многочлены называется не "Многочлены Чебышева", а "О функциях, наименее уклоняющихся от нуля".
Спасибо, но я про это вот всё не просто читал - у меня был курс по СУБД в университете, по которому я курсовую работу писал, защищал и защитил на "отлично". И обёртку эту писал тоже сам. А там, где нужна более сложная логика в SQL - предпочитаю хранимые процедуры. Чтобы на уровне бизнес-логики всё по-прежнему помещалось в одну строчку.
Ещё более по-хорошему - овладеть исскуству бэндов, чтобы каждую ноту дотягивать до нужной частоты. Это же всё-таки гитара, а не пианино, где подобные фокусы невозможны. Ну а каждый скрипач знает, что вибрато - надёжный способ замаскировать фальшивую ноту.
Могу поспорить, в вашем коде-баттле примут участие ровно ноль человек. Потому что тема с графическим редактором банальная, избитая, прекрасно реализуется без ООП и ничего не доказывает.
Фишка ООП же не в мантре "наследование/инкапсуляция/полиморфизм". Фишка ООП в возможности разделять низкоуровневый код от высокоуровнего и структурировать его по логике бизнес-процессов. Например, когда мне надо работать с базой данных, я пишу
var db = new Database(connectionstring);
int count = db.Execute("select count(*) from users");
Я не выбираю драйвер ODBC, OleDb, OpenClient или ещё что-то. Мне это вообще не интересно. Объект db сам определит драйвер по строке подключения.
Я не вызывает Connect(). Объект db имеет внутреннее состояние и сам вызывает Connect() при необходимости.
Я не делаю явных преобразований типов и не уточняю их при запросе. Метод Execute() возвращает тип QueryResult, который умеет в неявное преобразование типов.
Я не отлавливаю исключения, потому что прерывать бизнес-логику в произвольном месте выполнения плохая идея. Вместо этого используются значения по умолчанию - пустая таблица например.
Если надо обрабатывать ошибку на месте - то у QueryResult есть поле Error, а у Database есть LastQuery.
Если ошибки надо логгировать - у то Database есть событие OnError, на которое можно подписаться и делать это в отдельном месте или в отдельном потоке.
А если забыл вызвать Disconnect() - ничего страшного, при финализации db сам это сделает.
Может, в этом и суть, что кому-то важнее индекс цитирования, а не качество публикации? Даже если это цитирование носит негативный оттенок, типа "вопреки статье А мы получили результаты Б, которые полностью нивелируют выводы из статьи Ц".
Тем более вижу причину выделения для договора отдельной сущности. Которая хранит внутреннее состояние, которое можно отслеживать. Который нельзя два раза подписать. И который после завершения всех транзакций сам инициирует событие "договор подписан". Или "подписание отклонено".
В википедии да, написано странное. Но я могу разъяснить: автоматическое дифференцирование - это когда при вычислениях вы вместо обычных чисел вы берёте дуальные. И тогда коэффициент при мнимой единице будет иметь значение производной. Причём точной (в пределах погрешности вычислений, если с плавающей точкой считать), а не конечно-разностной.
Быстрый ответ - ничего. Всё вами перечисленное - это разделы аналитической математики. Если вас интересуют погрешности вычислений - то они будут разные в разных случаях, а для их контроля и обхода существуют отдельная матчасть. Ещё в математике нет основных функций, есть элементарные, а IEEE 754 не является полем, потому что там два нуля.
Я слышал, что ArXiv - не единственный проект подобного рода. А когда сам заглянул туда из любопытства, после новости о Перельмане - то не смог найти ничего, хоть как-то значимого по интересующим меня темам. А вот откровенного бреда (в частности, математического) - там прям навалом.
Хорошая статья. Но вы здесь (наряду с классиками) рассматриваете идеи лишь применительно к материальному, в то время как есть же ещё социум. В котором обитают такие идеи как "релокация", "замутить стартап", "сколотить рок-группу", "доказать теорему Ферма без смс и регистрации", "выйти замуж за миллионера" и всё такое. Идеи, которым некоторые не могут противостоять и которые непосредственно управляют нашей жизнью.
Этак и вы любую программу назовёте не конечным автоматом.
Ну назовите это как "асинхронный конечный автомат", суть от этого не меняется. Состояния явно прописаны, их количество конечно, в один момент времени существует только одно детерминированное состояние.
Маленький не получится, для этого придётся какой-то игрушечный пример придумывать.
Ну вот например у меня есть объект для вывода звука одновременно на несколько устройств, и у него есть такие состояния, которые должны проходить последовательно:
STOPPED,
ENUMERATE_RUNTIME_MODULES,
INIT_DEVICES,
START_DEVICES,
WAIT_FOR_BUFFERS,
STOP_DEVICES,
FREE_DEVICES
Запросы на изменение состояния обрабатывается в начале каждого. И если запрос на остановку приходит при переходе с INIT_DEVICES на START_DEVICES - то состояния WAIT_FOR_BUFFERS и STOP_DEVICES можно пропустить и переходить сразу на FREE_DEVICES. А в состояниях STOPPED, STOP_DEVICES и FREE_DEVICES его отслеживать не имеет смысла.
Соответственно запрос на старт имеет смысл обрабатывать только в состоянии STOPPED, а объект в состоянии STOPPED висит на блокирующем событии, чтобы не расходовать зря процессорное время, поэтому об этом нужно дополнительно просигнализировать объекту межпоточной синхронизации, прямой доступ к которому давать снаружи тоже не самая лучшая идея.
Тут разница в том, что в одном случае нерадивый коллега дёргает стоп-кран, а в другом случае - вежливо просит машиниста поезда остановиться. А машинист поезда может его так же вежливо послать ждать следующей остановки.
А вы говорите, зачем нужно ООП. Чтобы State снаружи нельзя было изменять, вот зачем. Я конечные автоматы тоже предпочитаю делать в отдельном потоке, а управление через методы типа
bool Stop() {must_stop=true;}, где must_stop - это приватный флаг и будет обработан там, где надо.Поясняю: то был тонкий намёк на то, что вам не известно про понятие лапласиана, иначе вы не выбрали бы этот символ (так как он уже занят и общепринят). То есть автоматически классифицирует вас в группу дилетантов, ищущих решения сложных задач простыми, но "хитрыми" способами.
Или так: "Умные учатся на своих ошибках, а дураки не учатся вообще".
Это же и главный критерий, по которой я пропускаю подобные статьи не читая (не в обиду автору). Настоящие математики называют свои работы по сути, а остальное делает уже история и признание других математиков. Например, оригинальная работа Чебышева про его знаменитые многочлены называется не "Многочлены Чебышева", а "О функциях, наименее уклоняющихся от нуля".
Спасибо, но я про это вот всё не просто читал - у меня был курс по СУБД в университете, по которому я курсовую работу писал, защищал и защитил на "отлично". И обёртку эту писал тоже сам. А там, где нужна более сложная логика в SQL - предпочитаю хранимые процедуры. Чтобы на уровне бизнес-логики всё по-прежнему помещалось в одну строчку.
Ещё более по-хорошему - овладеть исскуству бэндов, чтобы каждую ноту дотягивать до нужной частоты. Это же всё-таки гитара, а не пианино, где подобные фокусы невозможны. Ну а каждый скрипач знает, что вибрато - надёжный способ замаскировать фальшивую ноту.
Могу поспорить, в вашем коде-баттле примут участие ровно ноль человек. Потому что тема с графическим редактором банальная, избитая, прекрасно реализуется без ООП и ничего не доказывает.
Фишка ООП же не в мантре "наследование/инкапсуляция/полиморфизм". Фишка ООП в возможности разделять низкоуровневый код от высокоуровнего и структурировать его по логике бизнес-процессов. Например, когда мне надо работать с базой данных, я пишу
Я не выбираю драйвер ODBC, OleDb, OpenClient или ещё что-то. Мне это вообще не интересно. Объект db сам определит драйвер по строке подключения.
Я не вызывает Connect(). Объект db имеет внутреннее состояние и сам вызывает Connect() при необходимости.
Я не делаю явных преобразований типов и не уточняю их при запросе. Метод Execute() возвращает тип QueryResult, который умеет в неявное преобразование типов.
Я не отлавливаю исключения, потому что прерывать бизнес-логику в произвольном месте выполнения плохая идея. Вместо этого используются значения по умолчанию - пустая таблица например.
Если надо обрабатывать ошибку на месте - то у QueryResult есть поле Error, а у Database есть LastQuery.
Если ошибки надо логгировать - у то Database есть событие OnError, на которое можно подписаться и делать это в отдельном месте или в отдельном потоке.
А если забыл вызвать Disconnect() - ничего страшного, при финализации db сам это сделает.
Может, в этом и суть, что кому-то важнее индекс цитирования, а не качество публикации? Даже если это цитирование носит негативный оттенок, типа "вопреки статье А мы получили результаты Б, которые полностью нивелируют выводы из статьи Ц".
Тем более вижу причину выделения для договора отдельной сущности. Которая хранит внутреннее состояние, которое можно отслеживать. Который нельзя два раза подписать. И который после завершения всех транзакций сам инициирует событие "договор подписан". Или "подписание отклонено".
Повороты на 2D-плоскости притягиваются через умножение комплексных чисел.
Не нашёл ничего про то, а как (и когда) герой статьи играет на гитаре.
В википедии да, написано странное. Но я могу разъяснить: автоматическое дифференцирование - это когда при вычислениях вы вместо обычных чисел вы берёте дуальные. И тогда коэффициент при мнимой единице будет иметь значение производной. Причём точной (в пределах погрешности вычислений, если с плавающей точкой считать), а не конечно-разностной.
Я бы вам подсказал, но из статьи совершенно непонятно - а какую собственно задачу вы решаете?
Быстрый ответ - ничего. Всё вами перечисленное - это разделы аналитической математики. Если вас интересуют погрешности вычислений - то они будут разные в разных случаях, а для их контроля и обхода существуют отдельная матчасть. Ещё в математике нет основных функций, есть элементарные, а IEEE 754 не является полем, потому что там два нуля.
Я слышал, что ArXiv - не единственный проект подобного рода. А когда сам заглянул туда из любопытства, после новости о Перельмане - то не смог найти ничего, хоть как-то значимого по интересующим меня темам. А вот откровенного бреда (в частности, математического) - там прям навалом.