Как стать автором
Обновить
140.5
Карма
0.1
Рейтинг
Сергей Самойленко @samsergey

Руководитель, научный сотрудник, преподаватель

  • Подписчики 180
  • Подписки 1

Комплексные числа и геометрические узоры

Прекрасно и неожиданно даже для прикладного математика со стажем! За наглядные анимации -- отдельное спасибо!

Математика сторон света

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

По существу, автор поставил задачу разбиения элемента очень примитивной алгебраической структуры (множество направлений, замкнутое относительно неассоциативной, некоммутативной бинарной операции "сложения", дополненное нейтральным элементом для, этой операции, не являющимся направлением ( например, N+S=0), и позволяющее решить уравнение видаa+x=b. Такие структуры относятся к квазигруппам или, точнее, к лупам). Приведенная таблица может быть преобразована в диаграмму Юнга для разбиений. В принципе, можно попробовать построить изоморфизм с корнями из единицы (комплексными точками на окружности) и развить эту тему.

Чисто математически всë это не лишено смысла. А как занимательная алгебра -- даже интересно. Но на счёт практики -- не знаю...

Прошло тридцать лет, а QBasic по-прежнему лучший

А что, Haskell? Если продолжать аналогию с осями, то Haskell даëт понимание того, что оси могут быть какими угодно, хоть криволинейными, но это просто базис в линейном пространстве :)

Начинать с этого обучение точно не стоит, но это не что-то принципиально инопланетное. Оси и оси...

Функциональное ядро в виде конвейера на Python

Это не совсем так. Можно написать полностью функциональный код, превратив итеративный процесс в цикл. При этом он сохранит чистоту, прозрачность по ссылкам и даже денотационную и аксиоматическую семантику. Собственно, это и делают трансляторы PureScript, Elm, и даже GHC. Рекурсия необходима, если в языке нет иных способов организации цикла, или если задача не является примитивно-рекурсивной. Во всех остальных случаях функциональность и рекурсия помогают друг другу, но не являются необходимыми.

Функциональное ядро в виде конвейера на Python

Вы меня смутили тем, что в Python нет оптимизиции хвостовой рекурсии. Оказалось, что, действительно, нет, но с помощью декораторов можно написать рекурсивную функцию, а она будет переписана в цикл. Непонятно только зачем писать рекурсию там, где есть циклы… а если задача принципиально рекурсивна (использует рекурсивные типы), то хвостовая рекурсия не сделает жизнь проще.
Мне кажется, вам стоит рассказывать именно о непростых примерах, даже не обязательно полезных, но существенно более сложных чем факториал и числа Фибоначчи. Если в вашем арсенале они есть, делитесь!

Функциональное ядро в виде конвейера на Python

Автор просил конструктивной критики, и я постараюсь быть конструктивным. Будучи апологетом и популяризатором функционального подхода, я вижу, что статьи в которых ФП подаëтся, как "ещё один способ решить задачу" вызывают у читателей раздражение. Для того, чтобы убедить в эффективности функционального мышления и нужны примеры, в которых сложное остаётся сложным, но становится управляемым, доказуемым, гибким, расширяемым, универсальным, теоретически согласованным и так далее. Простые примеры, которые становятся сложнее от использования функциональной парадигмы не работают. Ту же композицию функций (базовое свойство, делающее функции моноидом, позволяющее делать то, что называется fusion, имеющее мощную теоретическую основу) лучше демонстрировать не на примере арифметических вычислений, а на примере бизнес-логики хитрой игры, транслятора DSL или принимающего решения искусственного интеллекта, где выделение функционального ядра, действительно позволяет увидеть что использование чистых функций даëт какие-то преимущества перед иными способами организации кода. На простых примерах использование композиции в не предназначенном для этого языке (без макросов и метапрограммирования, без легковесного каррирования, статической типизации, data-driven подхода и тому подобных инструментов) превращается во вкусовщину и аскезу и вызывает у новичков, а тем более, у профи, недоумение. Функциональное программирование в Python — это функции высших порядков, замыкания, оптимизация хвостовой рекурсии и комбинаторы обработки коллекций. Всë это позволяет написать и лямбда исчисление, и функторы и комонады и линзы… Но они не нужны в Python, они не облегчат жизнь программиста и не окупят потраченное на изучение этих концепций время, при том, что это классные штуки, открывающие массу возможностей, но в своей экосистеме.

Змейка на Haskell с циклом Гамильтона

Отличная работа! Возможно, вам будет интересно посмотреть на немного иную реализацию змейки, которую я писал для RosettaCode (https://rosettacode.org/wiki/Snake#Haskell). Она не консольная, на Gloss и автоматический поиск не гарантирует прохождения, но показывает некоторые приёмы создания DSL и использования линз.

Доказательное программирование

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

Подпольная тригонометрия различных метрик

Это, кстати, не так сложно.
Перепишем ОДУ второго порядка
f′′ = –f
в систему:
f′ = –g, g′ = f
и  рассмотрим свойство выражения:
f² + g². Мы знаем только как меняется скорость наших функций f и g, так что давайте посмотрим на скорость изменения этой суммы:
(f² + g²)′ = 2ff′ – 2gg′ = –2fg + 2gf = 0.
Нулевая скорость изменения этих выражений говорит о том, что эта сумма является константой. Выбрав такие начальные условия, чтобы f(0) = 1, а g(0)=0 получаем, что эта константа равна единице.
Кроме того, можно показать, что что если какое-либо из решений системы имеет хотя бы один максимум, то обе эти функции должны иметь бесконечное множество минимумов и максимумов, причём экстремальное значение одной функции обязательно соответствует нулю другой.

Подпольная тригонометрия различных метрик

Неплохая статья, правда! Но, как любитель математики не могу не прокомментировать этот пассаж:


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

Проблемы с решением этой задачи кроются не столько в математике, сколько в формулировке самой задачи. Что такое "конечная форма" и "аналитическое решение"? В какой именно конечной форме ищется решение, в каком поле? И тут открывается классный путь в теорию полей и трансцедентных чисел, на мой взгляд, не менее увлекательный, чем экскурс по миру метрик!


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

Философия нуля

Обожаю эту могучую "реальность", в которой всё всегда не так, как на самом деле :) Если бы реальность сопротивлялась моделированию с помощью математики, мы бы строили иную математику. Пока всё, имеющее смысл, сходится. Споры с привлечением "реальности", чаще всего, возникают вокруг утверждений смысла не имеющих.

RESHI.RU — робот решает и объясняет школьные текстовые задачи по математике

Таких конструктивных вопросов было два. Из 42 комментов про "пользу" и "несовершенство" :)

RESHI.RU — робот решает и объясняет школьные текстовые задачи по математике

Комментарии напомнили знаменитый анекдот про японскую лесопилку и суровых сибирских мужиков.
Интереснейшая задача, человек вплотную подошел к её реальному решению, рассказал как он это сделал и полностью открыт для общения со спецами, но! Самым интересным для уважаемых спецов оказалось тыкать в робота палкой, до тех пор, пока он не сломается, а потом гордо сказать: "ага!!" :)
Поздравляю автора с отличной задачей и классной реализацией! Уверен, что вы с сыном получили то, что искали: и пользу и удовольствие. А сын ещё и получил возможность восхититься тем, на что способны математика и папа!
В то время, как тыкатели палками могут гордиться тем, что они могут сломать что угодно, доказывая тем самым превосходство человека "над системой" :)

Философия деления на… или исповедь сумасшедшего

К сожалению, автор попадает в ловушку "убийства дракона": пытаясь победить формализм исходя из соображений "реальности" и "практической полезности", он теперь вынужден создать новый формализм, причем по всем правилам. Без четкой аксиоматики, без доказательства того, что новая система является полем, использовать её наряду с числами нельзя. Кроме того, похоже, что в этой системе есть нетривиальные делители нуля, а значит, она полем не является, значит неизбежны проблемы с единственностью разложения на множители и сокращениями при делении. Самое же главное, дракон, с которым сражается автор, столь же нереален и далёк от практики, как и указанная в самом начале "проблема формальной математики". Даже сугубо реалистичной инженерной физике никогда не мешали ограничения, накладываемые на операции с числами теорией полей, а, напротив, помогали познавать и моделировать сущности. Анализ размерности — прекрасный инструмент инженера, теория групп — инструмент теорфизика, теория конечных полей, типов и категорий — инструмент программиста. Возможно, предлагаемый здесь формализм может стать одним из таких инструментов, но пока я вижу в нём больше противоречий (указанных уже комментаторами выше), чем может позволить себе теория.
К слову, если статья на математическую тему начинается с упоминания теоремы Гёделя о полноте, это сильный признак её нематематичности. А если она, к тому же, переключается на вопросы "практичности" математики, то материал, скорее всего, не интересен и не полезен.
Лучше оставить в покое Гёделя, и построить стройную непротиворечивую аксиоматику, с выводом основных положений, типа теоремы Безу, основной теоремы арифметики и т.п. А если уж так хочется "полезности", показать пример приложения новой системы за пределами возможностей уже известных.

Мифы и реальность ООП

Конечность, строго говоря, не обязательна: \ dev\null тому пример. И вы правильно определили основные структуры, присущие файлу, как математическому объекту.

Мифы и реальность ООП

Это называется проблема поиска денотационной семантики. Работа в этом направлении идёт и далека от завершения. Для многих это жуть жуткая и муть мутная, каждый день не нужная. Но для тех кто пишет компиляторы и верификаторы это крутой инструмент.
А файл (POSIX) можно отождествить с анаморфизмом, порождающим свободный моноид, его обработчики — с гиломорфизмами. Файловая система — дерево, или более общий граф, если она реляционная и т.п. Мы используем эти понятия, не зная, что "говорим прозой".


И хотел бы добавить, современная математика огромна. Не торопитесь судить о ней в терминах "никакая математика не определит"… Например, о трех табуретках: теория устойчивости, даже линейная удовлетворительно отличит одно применение от другого.

Про ООП

Ну, скучно же, ребята!!! Один пишет про ошибки, допущенные другим в статье про ошибки третьих… спор о том, кто больше неправ продолжился в комментариях. Ну неправ, и что? Лучше бы написали о каком-нибудь крутом и красивом решении, которое показывает как XXX парадигма расширяет наш инструментарий, да с примерами, да так чтобы захотелось попробовать! А то "тут ООП, тут не ООП..." Как говорил Жванецкий: "Воруйте с прибылей!"

Хватит спорить про функциональное программирование и ООП

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

Хватит спорить про функциональное программирование и ООП

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

Хватит спорить про функциональное программирование и ООП

Это да. Мне хотелось продемонстрировать не столько чистое ФП, сколько его выразительность и гибкость. Если требуют решето именно Эратосфена и именно двойным циклом и именно с вычёркиваем, то… и это можно.
А так, есть классные функциональные решения тут и тут. Но они уже не совсем то решето, о котором обычно рассуждают.
Для своих нехитрых нужд я бы взял ваш однострочник и не заморачивался. Для криптографии какой-нибудь — быстрый императивный код через FFI, но я в ней мало смыслю, если честно.

Информация

В рейтинге
1,844-й
Откуда
Петропавловск-Камчатский, Камчатский край, Россия
Дата рождения
Зарегистрирован
Активность