Крутая статья, как и всегда. AY так и не смог вытеснить биперную музыку из моего сердца, у неё своё неповторимое, математически единственное очарование.
Не знаю, геодезией не интересуюсь. Но знаю, что кватернионы в том числе и для подобного рода задач были придуманы, и для множества достаточно простых моделей готовых формул в сети не найти. В 2D, например, я самостоятельно выводил формулы в комплексных числах для механизма Чебышева и промежуточных фигур между окружностью и правильными многоугольниками. Тоже вроде всем давно хорошо известные модели, а готовых формул не нашлось.
Конечно, основная масса алгоритмов не использут рекурсию, там два вложенных цикла с переменным шагом. Самому алгоритму динамическое выделение памяти тоже не нужно, если вы используюте фиксированный размер массива для преобразования. Рекомендую на эту тему почитать FXT Book, и в ней же про преобразование Хартли.
В Вольфраме я часто использую постфиксную запись. Это удобно на самом деле, когда можно сочетать с обычной. Особенно в случае с вложенными функциями более чем из одного оператора.
Если прям совсем без скобок - то используя постфиксную запись, типа как в Вольфраме: sin x + cos x >> print (а конкретно в Вольфраме это будет как Sin[x]+Cos[x] // Print). В порядке эксперимента и проверки концепции бесскобочный парсер (а заодно и неявное умножение) я уже делал, поэтому это точно возможно. Насколько такой подход интересен кому-то другому - вопрос уже другой, но математики в своей массе скобочки после функций без необходимости не ставят.
Потому что ключевое слово func стоит в начале всей конструкции.
Почему бы и определение типа не делать тоже слева, как в с++? Я не вижу удобство в том, когда какие-то определения/типы/ключевые слева, а какие-то справа. Лично мне нравится когда всё справа, но до логического конца этого ещё никто не довёл. В том же карбоне пока ещё не догадались, что вариант x=5:int более читабелен, чем x:int=5.
В остальных же языках - зоопарк кто во что горазд. Какие-то вертикальные палки и прочий ужас.
Ну так если всё будет по-одинаковому - то и языки друг от друга не будут отличаться.
И вообще в ASCII операторных символов мало (а в языках программирования используется именно ASCII потому что эти символы гарантированно есть на всех клавиатурах мира)
Так вроде давно уже все на юникод перешли. Повесить дополнительные символы на клавиатуру не проблема как глобально, так и локально (через автозамену в IDE, типа "?*" на "×", "?/" на "÷" и тд).
Отсутствие двоеточия не создаёт проблем, если пробел не перегружен. Лично я бы предпочёл избавиться от обязательных скобочек для передачи параметров в функцию, а также от fn/def/var/auto в принципе. Хочу например вместо print(sin(x)) писать просто print sin x . А для объявления функции использовать какой-нибудь символ, а не ключевое слово, например
#AddSub (a,b):int -> (c,d):int
c=a+b
d=a-b
Почему стрелочка вам код засоряет, а ключевое слово func - нет?
Можно было бы и без сарказма, если бы существовали препараты, у которых в графе "побочные эффекты" было бы пусто. Ну а задним числом легко сказать "пришли бы ко мне вовремя, не заболели бы". Врачи очень любят эту фразу - проверить же никак нельзя.
Ну а меня уже коснулось, в том числе и в обратном виде - самочувствие плохое, анализы в норме. Здоровый значит пациент, просто обманывает - на тебе пустышку вместо нормального лекарства.
"Здоровых людей не бывает"(с) Если пациент хорошо себя чувствует, но результаты анализов выходят за реф. интервал - значит он болен, просто об этом ещё не знает. </sarcasm>
Carbon — это абсолютно новый (он появился в 2022 году) компилируемый язык общего назначения от компании Google, который позиционируется как более синтаксически элегантный преемник C++.
Любой язык, который позиционируется как "убийца с++" обречён на провал. Потому что народу не нужен убийца чего-либо. Народу нужен удобный инструмент для работы. Это когда например увидел первый раз C# - и дельфи с джавой тут же стали пережитком прошлом.
А на Carbon я посмотрел ещё 2 года назад - ну не увидел никаких инноваций, чтобы с++ тут же стал пережитком прошлого (как случилось в своё время с дельфями). Увидел солянку из кучи всего от других языков. Более того, авторы не стеснялись говорить «присылайте нам свои идеи» - ну то есть взялись за разработку нового революционного языка не имея достаточного количества идей о том, а чем же он будем качественно превосходить все прочие уже существующие языки.
Я когда-то заморачивался тем, чтобы математически вывести формулу периодического сигнала с заданным количеством гармоник (только чётных, только нечётных, и тех и других, а также с детюнингом), и с заданной степенью подавления в зависимости от их номера. Например, такая формула
при эквивалентна этой
Но до практического применения её в собственном синтезаторе дело так и дошло.
Я за этой темой тоже давно не слежу, поскольку вопросы по устойчивой интерполяции/аппроксимации/сглаживанию давно закрыты, соответствующие алгоритмы написаны и отлажены. Современные изыскания по этой теме ищутся по ключевым словам на английском языке через гугл в научных работах, а сами работы часто можно прочитать бесплатно через сайт sci-hub (один из зеркалов) по DOI.
Иными словами, цифры являются коэффициентами многочлена
Тут можно добавить, что выражение как конечного, так и бесконечного набора чисел как коэффициентов многочлена - это очень мощный инструмент, а котором в школе даже не упоминают. Здесь важно понимать, что в не надо ничего подставлять, он имеет тот же смысл, что и мнимая единица.
Интересной особенностью этого преобразования является то, что f=0 строго говоря не является частотой...
... и обычно называется "постоянная смещения", "dc offset".
У этих двух значений не бывает мнимой части
Верно только по отношению к действительным данным, потому что в общем преобразование Фурье определено над комплексными числами.
что можно использовать для оптимизации хранения
От такой оптимизации будет больше неудобств, чем пользы. А вот что действительно можно оптимизировать - так это использовать преобразование Хартли вместо Фурье, которое даёт тот же результат (только слегка в другом виде), считается через действительные числа (для тех кто не хочет связываться с комплексными числами), и занимает в два раза меньше места. Для БПФ конечно тоже есть варианты для преобразования только половины спектра, но алгоритмически они значительно сложнее. Также через один БПФ можно обработать сразу два чисто действительных массива.
По логике-то прямо наоборот - чем меньше пропусков, тем достовернее аппроксимация. Если под нулями вы подразумеваете пропущенные значения - так они и не учитываются, в этом и смысл "неравноотстоящих" точек.
Синусоиды, кстати, можно поменять за многочлены Чебышева и наоборот, тут кому как удобнее считать.
Крутая статья, как и всегда. AY так и не смог вытеснить биперную музыку из моего сердца, у неё своё неповторимое, математически единственное очарование.
Не знаю, геодезией не интересуюсь. Но знаю, что кватернионы в том числе и для подобного рода задач были придуманы, и для множества достаточно простых моделей готовых формул в сети не найти. В 2D, например, я самостоятельно выводил формулы в комплексных числах для механизма Чебышева и промежуточных фигур между окружностью и правильными многоугольниками. Тоже вроде всем давно хорошо известные модели, а готовых формул не нашлось.
Почему это не описать? Если вы не знаете такой формулы - это не значит невозможно, нет никаких причин для этого.
Конечно, основная масса алгоритмов не использут рекурсию, там два вложенных цикла с переменным шагом. Самому алгоритму динамическое выделение памяти тоже не нужно, если вы используюте фиксированный размер массива для преобразования. Рекомендую на эту тему почитать FXT Book, и в ней же про преобразование Хартли.
В плагинах для вс постоянное сворачивание предусмотрено, я делал такое для ассемблера, дополнительно к подсветке синтаксиса.
В Вольфраме я часто использую постфиксную запись. Это удобно на самом деле, когда можно сочетать с обычной. Особенно в случае с вложенными функциями более чем из одного оператора.
Если прям совсем без скобок - то используя постфиксную запись, типа как в Вольфраме:
sin x + cos x >> print(а конкретно в Вольфраме это будет какSin[x]+Cos[x] // Print). В порядке эксперимента и проверки концепции бесскобочный парсер (а заодно и неявное умножение) я уже делал, поэтому это точно возможно. Насколько такой подход интересен кому-то другому - вопрос уже другой, но математики в своей массе скобочки после функций без необходимости не ставят.Почему бы и определение типа не делать тоже слева, как в с++? Я не вижу удобство в том, когда какие-то определения/типы/ключевые слева, а какие-то справа. Лично мне нравится когда всё справа, но до логического конца этого ещё никто не довёл. В том же карбоне пока ещё не догадались, что вариант
x=5:intболее читабелен, чемx:int=5.Ну так если всё будет по-одинаковому - то и языки друг от друга не будут отличаться.
Так вроде давно уже все на юникод перешли. Повесить дополнительные символы на клавиатуру не проблема как глобально, так и локально (через автозамену в IDE, типа "?*" на "×", "?/" на "÷" и тд).
Отсутствие двоеточия не создаёт проблем, если пробел не перегружен. Лично я бы предпочёл избавиться от обязательных скобочек для передачи параметров в функцию, а также от fn/def/var/auto в принципе. Хочу например вместо
print(sin(x))писать простоprint sin x. А для объявления функции использовать какой-нибудь символ, а не ключевое слово, напримерПочему стрелочка вам код засоряет, а ключевое слово func - нет?
Можно было бы и без сарказма, если бы существовали препараты, у которых в графе "побочные эффекты" было бы пусто. Ну а задним числом легко сказать "пришли бы ко мне вовремя, не заболели бы". Врачи очень любят эту фразу - проверить же никак нельзя.
Ну а меня уже коснулось, в том числе и в обратном виде - самочувствие плохое, анализы в норме. Здоровый значит пациент, просто обманывает - на тебе пустышку вместо нормального лекарства.
"Здоровых людей не бывает"(с) Если пациент хорошо себя чувствует, но результаты анализов выходят за реф. интервал - значит он болен, просто об этом ещё не знает. </sarcasm>
Любой язык, который позиционируется как "убийца с++" обречён на провал. Потому что народу не нужен убийца чего-либо. Народу нужен удобный инструмент для работы. Это когда например увидел первый раз C# - и дельфи с джавой тут же стали пережитком прошлом.
А на Carbon я посмотрел ещё 2 года назад - ну не увидел никаких инноваций, чтобы с++ тут же стал пережитком прошлого (как случилось в своё время с дельфями). Увидел солянку из кучи всего от других языков. Более того, авторы не стеснялись говорить «присылайте нам свои идеи» - ну то есть взялись за разработку нового революционного языка не имея достаточного количества идей о том, а чем же он будем качественно превосходить все прочие уже существующие языки.
Это претендент на замену просто си, без плюсов.
Минусы наверняка за "подписывайтесь на мой телеграм-канал".
Хотелось бы почитать книги с такими же названиями, но за авторством Кармака и Ромеро.
Я когда-то заморачивался тем, чтобы математически вывести формулу периодического сигнала с заданным количеством гармоник (только чётных, только нечётных, и тех и других, а также с детюнингом), и с заданной степенью подавления в зависимости от их номера. Например, такая формула
при
эквивалентна этой
Но до практического применения её в собственном синтезаторе дело так и дошло.
Я за этой темой тоже давно не слежу, поскольку вопросы по устойчивой интерполяции/аппроксимации/сглаживанию давно закрыты, соответствующие алгоритмы написаны и отлажены. Современные изыскания по этой теме ищутся по ключевым словам на английском языке через гугл в научных работах, а сами работы часто можно прочитать бесплатно через сайт sci-hub (один из зеркалов) по DOI.
Тут можно добавить, что выражение как конечного, так и бесконечного набора чисел как коэффициентов многочлена - это очень мощный инструмент, а котором в школе даже не упоминают. Здесь важно понимать, что в
не надо ничего подставлять, он имеет тот же смысл, что и мнимая единица.
... и обычно называется "постоянная смещения", "dc offset".
Верно только по отношению к действительным данным, потому что в общем преобразование Фурье определено над комплексными числами.
От такой оптимизации будет больше неудобств, чем пользы. А вот что действительно можно оптимизировать - так это использовать преобразование Хартли вместо Фурье, которое даёт тот же результат (только слегка в другом виде), считается через действительные числа (для тех кто не хочет связываться с комплексными числами), и занимает в два раза меньше места. Для БПФ конечно тоже есть варианты для преобразования только половины спектра, но алгоритмически они значительно сложнее. Также через один БПФ можно обработать сразу два чисто действительных массива.
По логике-то прямо наоборот - чем меньше пропусков, тем достовернее аппроксимация. Если под нулями вы подразумеваете пропущенные значения - так они и не учитываются, в этом и смысл "неравноотстоящих" точек.
Синусоиды, кстати, можно поменять за многочлены Чебышева и наоборот, тут кому как удобнее считать.