Палитесь. Написали бы честно - "Кризис лишил нас работы — и мы купили Мой Склад, который зарабатывает миллиарды" - и то лучше было бы. Ну или Славе Рюмину занесите денюжку - у него такие истории лучше получаются.
Обычно "что-то не так" значит отсутствие знания. Потому что в теме старой как мир перепробовано уже всё всеми. Знакомство с методом Ньютона поможет вам не только квадратные корни находить, но вообще практически любые обратные функции. Ну а ваш метод отличается от него лишь запутанным ходом рассуждения и отсутствием формализации.
Чужих ошибок слишком много. Я один, а их 8 миллиардов. В чужих ошибках неизвестна предыстория и прочие детали. Чужие ошибки вообще не факт, что ошибки - кто я такой чтобы решать, кто прав, а кто нет.
Спасибо за статью! Тоже слышал эту новость, но в оригинальную статью вникать даже и не пытался, ибо не настоящий математик. А вот в вашу повникаю с большим интересом. Через пару месяцев вникания оставлю повторный комментарий, получилось обрести понимание или нет.
Давайте переформулирую: выигрыш от уменьшения количества шагов может быть нивелирован временными затратами на выполнение самого алгоритма, и по факту результат может оказаться не лучше, а хуже. Именно поэтому при оценке сложности алгоритмов множители отсутствуют.
Не, не решает. Ускорение в несколько раз достигается просто обычной программной оптимизацией. Мой личный рекорд - ускорение в 40 раз, используя ассемблер. И в целом ради ускорения в 2-3 раза я за оптимизацию не берусь.
Ну и практическую значимость имеет разложение не на два множителя, а на их произвольное количество. И сравнивать результат надо не с самым простым алгоритмом по количеству итераций, а с его реализаций в популярных мат.пакетах. Если ваш алгоритм разложит число на множители в 10 раз быстрее (по секундомеру), чем например Mathematica - вот тогда да, атмосфера в комментариях будет совсем другой.
Хорошая статья. Но вы здесь (наряду с классиками) рассматриваете идеи лишь применительно к материальному, в то время как есть же ещё социум. В котором обитают такие идеи как "релокация", "замутить стартап", "сколотить рок-группу", "доказать теорему Ферма без смс и регистрации", "выйти замуж за миллионера" и всё такое. Идеи, которым некоторые не могут противостоять и которые непосредственно управляют нашей жизнью.
Ну назовите это как "асинхронный конечный автомат", суть от этого не меняется. Состояния явно прописаны, их количество конечно, в один момент времени существует только одно детерминированное состояние.
Маленький не получится, для этого придётся какой-то игрушечный пример придумывать.
Ну вот например у меня есть объект для вывода звука одновременно на несколько устройств, и у него есть такие состояния, которые должны проходить последовательно:
Запросы на изменение состояния обрабатывается в начале каждого. И если запрос на остановку приходит при переходе с 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 сам это сделает.
Может, в этом и суть, что кому-то важнее индекс цитирования, а не качество публикации? Даже если это цитирование носит негативный оттенок, типа "вопреки статье А мы получили результаты Б, которые полностью нивелируют выводы из статьи Ц".
Палитесь. Написали бы честно - "Кризис лишил нас работы — и мы купили Мой Склад, который зарабатывает миллиарды" - и то лучше было бы. Ну или Славе Рюмину занесите денюжку - у него такие истории лучше получаются.
А начальное значение удобно находить через рациональную аппроксимацию, например
Которая получена например аппроксимацией Паде (здесь в точке 100).
Обычно "что-то не так" значит отсутствие знания. Потому что в теме старой как мир перепробовано уже всё всеми. Знакомство с методом Ньютона поможет вам не только квадратные корни находить, но вообще практически любые обратные функции. Ну а ваш метод отличается от него лишь запутанным ходом рассуждения и отсутствием формализации.
Чужих ошибок слишком много. Я один, а их 8 миллиардов. В чужих ошибках неизвестна предыстория и прочие детали. Чужие ошибки вообще не факт, что ошибки - кто я такой чтобы решать, кто прав, а кто нет.
Спасибо за статью! Тоже слышал эту новость, но в оригинальную статью вникать даже и не пытался, ибо не настоящий математик. А вот в вашу повникаю с большим интересом. Через пару месяцев вникания оставлю повторный комментарий, получилось обрести понимание или нет.
Давайте переформулирую: выигрыш от уменьшения количества шагов может быть нивелирован временными затратами на выполнение самого алгоритма, и по факту результат может оказаться не лучше, а хуже. Именно поэтому при оценке сложности алгоритмов множители отсутствуют.
Не, не решает. Ускорение в несколько раз достигается просто обычной программной оптимизацией. Мой личный рекорд - ускорение в 40 раз, используя ассемблер. И в целом ради ускорения в 2-3 раза я за оптимизацию не берусь.
Ну и практическую значимость имеет разложение не на два множителя, а на их произвольное количество. И сравнивать результат надо не с самым простым алгоритмом по количеству итераций, а с его реализаций в популярных мат.пакетах. Если ваш алгоритм разложит число на множители в 10 раз быстрее (по секундомеру), чем например Mathematica - вот тогда да, атмосфера в комментариях будет совсем другой.
Хорошая статья. Но вы здесь (наряду с классиками) рассматриваете идеи лишь применительно к материальному, в то время как есть же ещё социум. В котором обитают такие идеи как "релокация", "замутить стартап", "сколотить рок-группу", "доказать теорему Ферма без смс и регистрации", "выйти замуж за миллионера" и всё такое. Идеи, которым некоторые не могут противостоять и которые непосредственно управляют нашей жизнью.
Этак и вы любую программу назовёте не конечным автоматом.
Ну назовите это как "асинхронный конечный автомат", суть от этого не меняется. Состояния явно прописаны, их количество конечно, в один момент времени существует только одно детерминированное состояние.
Маленький не получится, для этого придётся какой-то игрушечный пример придумывать.
Ну вот например у меня есть объект для вывода звука одновременно на несколько устройств, и у него есть такие состояния, которые должны проходить последовательно:
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 сам это сделает.
Может, в этом и суть, что кому-то важнее индекс цитирования, а не качество публикации? Даже если это цитирование носит негативный оттенок, типа "вопреки статье А мы получили результаты Б, которые полностью нивелируют выводы из статьи Ц".