Попробую объяснить в двух словах. У отображения двумерного пространства на себя, сохраняющего площади окрестностей любой точки могут быть неподвижные точки, то есть, не изменяющиеся под действием отображения. У гладких отображений неподвижные точки бывают принципиально двух видов: эллиптические и гиперболические (вырожденные случаи тоже могут быть, но они нетипичны).
Вокруг эллиптических точек происходит локальное вращение пространства, а вокруг гиперболических — растяжение в одном направлении и сжатие в другом. При многократном повторении отображений в окрестностях эллиптических точек будут формироваться упорядоченные овальные орбиты. Гиперболические неподвижные точки порождают хаотические орбиты (через разрушение инвариантных гетероклинических многообразий), заполняющие целые площади пространства.
Переход от упорядоченных орбит к хаотическим может быть постепенным (через каскад удвоения периода) либо резким в случае развитого хаоса. Более или менее подробно я описывал это в статьях про прыгающий шарик (https://habr.com/ru/articles/750380/). В вашей схеме некоторые гиперболические точки выдают себя на картинках высокого разрешения крестообразными сгущениями орбит.
Анализируя вашу схему я бы тоже сначала рассмотрел первые члены рядов для синуса и косинуса.
Поворот не обязателен. В вашем случае роль складывания после искажения играет вычисление дробной части, то есть отображение всей плоскости на квадрат со стороной 1. Именно сочетание искажения и складывания обеспечивает перемешивание. А будут при этом неподвижные точки простых типов или странные аттракторы, конечно, зависит от конкретного преобразования.
Совершенно верно, на C++ надо делать тот или иной вид субпиксельного сглаживания. Именно такое смешивание, как вы описали, я и сделал для картинки выше: подсчитывал число попаданий точек в ячейку массива и отображал таким образом плотность.
Фрактальные объекты бывают самоподобны, но могут такими и не быть. Их главная особенность -- дробная размерность Хаусдорфа. Приведённый в статье объект фрактален, но не самоподобен.
Прикольная абстракция! Здесь цвет отображает плотность аттрактора при 100 млн итерациях. Интересно, что от начальной точки итерации изображение не зависит -- оно является инвариантом указанного преобразования.
Боюсь, что я создал нетленку -- то есть единственный на русском языке материал, посвящённый именно этой схеме. Если поискать в англоязычном сегменте (hopalong attractor, Martin's hopalong), то будет много этюдов по программированию на разных языках, демок или записей в блогах, а также несколько статей (https://jolinton.co.uk/Mathematics/Hopalong_Fractals/Text.pdf), посвящённых генеративному искусству, но не разбору динамики.
Я точно не скажу, это не моя программа, но думаю, что один или даже два параметра образуют пространство в котором "движется" наблюдатель, и на него уже проецируются фрагменты соответствующего этим параметрам аттрактора.
Pijul была создана именно для того, чтобы делать merge, причём корректно и минимизируя конфликты автоматически.
Стандартный способ pijul pull сливает два репозитория, эквивалентен git merge + rebase.
Если нужны отдельные ветки (channels) то для их слияния используется команда pijul apply, позволяющая соединить два канала.
В системах Darcs и Pijul мерджинг не отдельная функция, а неотъемлемая и принципиальная часть базового функционирования. По существу, в них нет ничего, кроме merge, поэтому она не выносится в отдельную команду.
Вы правы, эта заметка, действительно требует продолжения и развития темы. Другое дело, что я математик, и не спец по системам контроля версий, а только пользователь, но с чем разберусь, поделюсь, благо литературы много.
Дочерние репы не совсем независимы, они "знают" друг о друге и синхронизируются. Просто выведены в отдельные файлы, видные пользователю. К тому же в Pijul есть channels — виртуальные ветки, как в git.
Подправлю, спасибо!
Ага, ещё один! ;)
Я как-то уже отвечал на этот вопрос: https://habr.com/ru/articles/746706/#comment_25731380
Теория динамических систем и теория хаоса.
Попробую объяснить в двух словах. У отображения двумерного пространства на себя, сохраняющего площади окрестностей любой точки могут быть неподвижные точки, то есть, не изменяющиеся под действием отображения. У гладких отображений неподвижные точки бывают принципиально двух видов: эллиптические и гиперболические (вырожденные случаи тоже могут быть, но они нетипичны).
Вокруг эллиптических точек происходит локальное вращение пространства, а вокруг гиперболических — растяжение в одном направлении и сжатие в другом. При многократном повторении отображений в окрестностях эллиптических точек будут формироваться упорядоченные овальные орбиты. Гиперболические неподвижные точки порождают хаотические орбиты (через разрушение инвариантных гетероклинических многообразий), заполняющие целые площади пространства.
Переход от упорядоченных орбит к хаотическим может быть постепенным (через каскад удвоения периода) либо резким в случае развитого хаоса. Более или менее подробно я описывал это в статьях про прыгающий шарик (https://habr.com/ru/articles/750380/). В вашей схеме некоторые гиперболические точки выдают себя на картинках высокого разрешения крестообразными сгущениями орбит.
Анализируя вашу схему я бы тоже сначала рассмотрел первые члены рядов для синуса и косинуса.
Поворот не обязателен. В вашем случае роль складывания после искажения играет вычисление дробной части, то есть отображение всей плоскости на квадрат со стороной 1. Именно сочетание искажения и складывания обеспечивает перемешивание. А будут при этом неподвижные точки простых типов или странные аттракторы, конечно, зависит от конкретного преобразования.
Про происхождение этих кругов я когда-то упоминал в небольшой статье о таблице умножения: https://dzen.ru/a/Y6KF_eLgZkAebaW9
Смешение цветов предпочтительнее, оно позволяет получить эффект "высокого разрешения", плавных переходов и тонких деталей.
Совершенно верно, на C++ надо делать тот или иной вид субпиксельного сглаживания. Именно такое смешивание, как вы описали, я и сделал для картинки выше: подсчитывал число попаданий точек в ячейку массива и отображал таким образом плотность.
Фрактальные объекты бывают самоподобны, но могут такими и не быть. Их главная особенность -- дробная размерность Хаусдорфа. Приведённый в статье объект фрактален, но не самоподобен.
У нас разница в том, что в моём случае новые значения
xиyвычисляются одновременно, а в вашем — последовательно. Мой алгоритм будет выглядеть так:При этом старое значение
xсохраняется после вычисления строки 2.А если просто вычислять
То после выполнения строки 1 значение
xуже изменится и это изменение пойдёт в строку 2У меня так получилось.
Прикольная абстракция! Здесь цвет отображает плотность аттрактора при 100 млн итерациях. Интересно, что от начальной точки итерации изображение не зависит -- оно является инвариантом указанного преобразования.
Боюсь, что я создал нетленку -- то есть единственный на русском языке материал, посвящённый именно этой схеме. Если поискать в англоязычном сегменте (hopalong attractor, Martin's hopalong), то будет много этюдов по программированию на разных языках, демок или записей в блогах, а также несколько статей (https://jolinton.co.uk/Mathematics/Hopalong_Fractals/Text.pdf), посвящённых генеративному искусству, но не разбору динамики.
Множество интересных схем есть здесь: https://paulbourke.net/fractals/
Я точно не скажу, это не моя программа, но думаю, что один или даже два параметра образуют пространство в котором "движется" наблюдатель, и на него уже проецируются фрагменты соответствующего этим параметрам аттрактора.
А я помню статьи про бои в памяти! Целый цикл был, но для меня он оказался сложноват.
У меня на всех машинах Linux (Nix-OS), в репозитории TortoiseGit нет.
Pijul была создана именно для того, чтобы делать merge, причём корректно и минимизируя конфликты автоматически.
Стандартный способ pijul pull сливает два репозитория, эквивалентен git merge + rebase.
Если нужны отдельные ветки (channels) то для их слияния используется команда pijul apply, позволяющая соединить два канала.
В системах Darcs и Pijul мерджинг не отдельная функция, а неотъемлемая и принципиальная часть базового функционирования. По существу, в них нет ничего, кроме merge, поэтому она не выносится в отдельную команду.
<Del>
Вы правы, эта заметка, действительно требует продолжения и развития темы. Другое дело, что я математик, и не спец по системам контроля версий, а только пользователь, но с чем разберусь, поделюсь, благо литературы много.
Дочерние репы не совсем независимы, они "знают" друг о друге и синхронизируются. Просто выведены в отдельные файлы, видные пользователю. К тому же в Pijul есть channels — виртуальные ветки, как в git.