У меня абсолютно тот же FEM, но только для одного типа задач (механическая деформация плоских пластин) и со многими оговорками про типы граничных условий.
Не совсем понял, каких интегралов вы ждали. Но те интегралы (по площади элемента), которых здесь действительно следовало ждать, скажем так, посчитаны аналитически и спрятаны в матрицу жёсткости элемента k. И интегралы эти самые простые: интегрируется постоянная относительная деформация и получается линейно нарастающее перемещение точек.
А что делать с силами, связями и материалом? Здесь в любом случае нужен специализированный редактор. Ну и вообще, продолжая вашу логику, можно просто взять ANSYS и сразу всё посчитать. Но удовольствие было не в этом.
Да, МКЭ — по сути, и есть метод перемещений, но доведённый до абсолютной формализации.
К сожалению, у нас в универе МКЭ демонстрировался только на одномерных задачах, что лишало его обаяния и оставляло недоумение ("Зачем огород городить? Рассчитать балку на растяжение я могу и попроще").
Способ декларирования замыкания выглядит ИМХО очень интересно, огромный плюс что декларирование именно явное.
Мне и коллегам по проекту тоже нравится. Но приходилось слышать и шумное возмущение.
Прошёлся по ридми, выглядит прям очень ГО-подобно, но способ объявления типов словарей расстроил. Опять же ИМХО в го это самая неинтуитивная конструкция.
А что не так с типами словарей? В любом случае, как-то нужно указать два типа: ключа и значения.
В целом язык выглядит интересно, захотелось пощупать. Я так понимаю, стандартная библиотека сейчас не может похвастаться богатым инструментарием?
Да, стандартная библиотека скудная. Рекомендую больше ориентироваться на пакеты из UmBox. Если чего-то всерьёз не хватает — не стесняйтесь просить.
Помню ваш проект и первую статью о нём. Рад, что затея жива. Наметились ли какие-нибудь применения языка? Или продолжаете чисто для собственного удовольствия и прокачки навыков?
Возможно я невнимательно читал, однако не заметил чтоб была опубликована ссылка на какое-либо сообщество пользователей umka или tophat. Может есть какой-то чат в telegram?
Как в этом случае сделать билд, например, под android?
Компиляция под Android пока ещё в разработке. Сейчас собираем под Windows, Linux, WASM.
Существует ли плагин подсветки синтаксиса и автокомлита для какой-либо IDE или редактора типа VSC, Geany, Kate и/или других?
В дистрибутиве Umka есть подсветка под Sublime Text. Существует также подсветка под Vim и VS Code, но она пока сыровата (можете поинтересоваться в канале Discord). Полноценный Language Server -- отдельная большая задача.
Однако, для кого? Для чего? Tophat чтоб пошалить на джемах или все же он готов к коммерческим проектам? К публикациям на таких площадках как poki, crazy games, yandex games, google play, app gallery, rustore и других?
По меньшей мере, для тех, кого не устраивает Lua. А в остальном -- предлагаю посмотреть и поэкспериментировать самостоятельно. Мы будем только рады замечаниям и по языку, и по фреймворку. Разумеется, степень готовности Tophat меньше, чем Love2D.
Нужна ли проектам поддержка? Голова с руками или донаты?
Голова с руками нужна всегда -- милости просим! Донатами пока не интересовались.
Пробавали внедрять поодержку Умки в существующие игровые движки?
А не думали сделать какой-нибудь отложенный способ освобождения памяти при выходе из некоторой области видимости
Управление памятью в Umka сделано на подсчёте ссылок. Чем не "отложенный способ"? Если на кусок памяти ссылается только одна переменная, то этот кусок будет освобождён как раз при выходе из области видимости переменной. Если ссылок больше -- то память освободится при обрывании последней из них. Метод классический и весьма надёжный. Уж точно лучше того, что было в V, когда я ещё пытался всерьёз воспринимать этот проект.
Маловато документации по multivalue return. Оно работает также как и в Go?
Возврат нескольких значений из функции? Да, как в Go. Но есть тонкости, когда нужно сделать функцию с реализацией на C, которая бы возвращала несколько значений.
А есть ли (планируется ли) LSP или TreeSitter для языка?
Нужны ли компиляторы чтобы писать приложения на Umka или можно как-то статически всё это дело скомпоновать имея только рантайм умки?
Umka -- интерпретируемый язык, в отличие от Go. Для запуска программы (*.um) нужен интерпретатор (*.exe). Если вы хотите использовать Umka именно как встроенный язык, то интерпретатор может стать частью вашего собственного *.exe. Для этого можно откомпилировать исходники Umka на C вместе с вашими (как это сделано для Tophat), можно носить с собой интерпретатор Umka как *.dll.
А асинхронная обработка будет? Или пока только самому крафтить?
Есть такая задача. Но она тоже, вероятно, уедет на Umka 2.
Я так понимаю есть возможность вкладывать типы, но не увидел как такие типы используются. Или это просто множественное определение нескольких типов
Это просто множественное определение типов. Синтаксис такой же, как в Go.
Есть ли Union типы как в C?
Нет, и неспроста. Если делать объединения именно как в C, то они становятся опасными, поскольку позволяют, например, вручную перезаписать значение указателя. Можно было бы сделать объединения "защищёнными", то есть всегда хранящими и проверяющими описание конкретного типа данных, который в данный момент туда уложен. Но это уже очень похоже на интерфейсы, которые и так в Umka есть.
Не совсем понял, к чему здесь столь многословная реклама ML. Я думаю, при желании вы могли бы написать об этом отдельный пост. Если вам интересно моё мнение, отчего функциональные языки "обделены вниманием", то дело тут не в корпорациях, а в человеческой психологии. Функциональные языки предполагают совсем иной взгляд на то, что такое программа и программирование, нежели языки императивные. Видимо, большинству людей легче мыслить в понятиях "последовательности указаний", чем в понятиях "вычисления композиции функций". Однако всё это не имеет никакого отношения к теме моей статьи, поэтому вряд ли мне хотелось бы пускаться в пространные дискуссии.
V²•R это энергия это постоянная величина небесного тела.
Полная нелепость. Поскольку вы не дали определения ни V, ни R, то ваше утверждение бессмысленно. Если вы скажете, что V - это модуль скорости, а R - длина радиус-вектора, то оно превратится из бессмысленного в неверное.
Энергия (в расчёте на единицу массы) равна V²/2 - GM/R, и именно эта величина и сохраняется. Ваша же величина V²R не только не постоянна вдоль эллиптической орбиты (в чём вы можете легко удостовериться из того же численного моделирования), но даже по размерности не совпадает с энергией.
Могу только гадать, откуда вы её взяли, и свою догадку уже высказывал: из школьной формулы для круговой орбиты V²R = GM. В таком случае не забывайте, что, во-первых, это не энергия и она не обязана сохраняться, а во-вторых, эта формула неприменима к эллипсу, гиперболе и вообще хоть чему-нибудь кроме окружности.
В начале поста эллипсная орбита. Если мы знаем, что большая полуось это средний радиус , мы легко можем догадаться, что можем узнать орбитальную скорость в любой точке эллипса, если знаем первую космическую к примеру.
Код будет работать если заменить GM=V²•R выразить через орбитальную скорость?
Я понятия не имею, что вы называете "средним радиусом" эллипса. Такого понятия нет. Что за V? Что за R? Что останется от вашего равенства, когда сила не перпендикулярна скорости (а на эллипсе такое будет непременно)? У меня ощущение, что вы пытаетесь за уши притащить сюда какую-то аналогию с круговой орбитой из школьного учебника. Тщетное занятие.
Запустить копию симуляции на природных законах. Для начала солнечной системы...
Тогда собирайте измерительные данные сами, как Тихо Браге, или берите готовые данные от какой-нибудь обсерватории, подставляйте их вместо симулятора и проверяйте хоть законы Кеплера, хоть законы Ньютона.
Чтобы не быть голословным и заодно уберечь вас от псевдонауки, предлагаю вам код численного моделирования, которое как раз и демонстрирует справедливость третьего закона Кеплера (в предположении справедливости второго закона Ньютона и закона всемирного тяготения). Можете сами поварьировать в нём начальные условия для планет и убедиться, что получите для всех одно и то же отношение куба большой полуоси к квадрату периода (варьируйте осторожно, чтобы не получить гиперболическую траекторию). Надеюсь, это избавит и вас, и нас от россказней про "фальсификации" и т.п.
Можете ли Вы написать код для проверки подлинности фундаментальных законов природы?
Нет. Численным моделированием можно проверить только корректность математических выкладок, но не справедливость закона как такового. Если в модель заложены неверные предпосылки, то получатся и неверные следствия. Моделированием можно, например, подтвердить, что из законов Ньютона следуют законы Кеплера, но это ничего не скажет нам о справедливости самих законов Ньютона.
масса небесного тела зависит от угловой скорости....что сразу вступает в конфликт с классической механикой Ньютона
Это неверно. Во-первых, не угловая скорость, а скорость изменения полярного угла. У материальной точки угловой скорости нет вовсе. У реальной планеты (тела конечных размеров) она есть, но не равна скорости изменения полярного угла из-за суточного вращения. Во-вторых, не масса зависит от этой скорости, а наоборот. Законы Ньютона первичны, а законы Кеплера - лишь их наблюдаемые следствия.
Страница 189 была сфальсифицирована и описание закона полностью утрачено, вероятно фальсификаторы добавили дату:"... 8 марта этого года одна тысяча шестьсот восемнадцать..." В 18 веке одну тысячу лет добавляли и на картинах... Слово "sesquialtera" - полтора, там шла речь о степени 3 и 2, фальсификатор прочитал как 3/2...=1,5 так и написал - полтора.
Чтобы судить о справедливости законов, стоит не читать древние трактаты, а проверять эти законы с карандашом, бумагой, компьютером и телескопом.
И образуется зазор, когда содержимое слабой ссылки уже зачитано в регистр, но ещё не произошёл AddRef. Прямо в этот момент объект может испариться, а на его месте появится другой или, чаще, мусор.
Если я правильно вас понял, то эта проблема возникает только когда потоки переключает некий внешний планировщик. В Umka нет поддержки "родных" потоков операционной системы; виртуальная машина Umka работает всегда в одном системном потоке. Внутри виртуальной машины может быть множество её собственных "потоков", но за их переключение отвечает сам программист, вызывая fibercall(). Этот подход я позаимствовал из Lua и Wren.
В случае действительно незнакомых законов, нет знаний куда надо подправлять.
Разумеется. Но вариантов "куда подправлять" в рассматриваемой задаче не так уж много: 2 в степени 4 = 16. Если речь идёт о незнакомой (особенно большой) системе, конечно, нужен ручной или полуавтоматический отбор и анализ решений.
И кстати, эта задача трудна даже когда человек-исследователь сам берётся искать законы сохранения: независима ли сохраняющаяся величина от всех предыдущих? случайно ли величина сохраняется или это глубокий закон? В статье в Science цитируются исследования насчёт ошибок, которые люди при этом допускают.
Не очень понятен вопрос. В Umka передаётся структура или указатель на структуру? Если структура, то у неё есть адрес в стеке Umka, и ничто не мешает этот адрес взять. Если указатель на структуру (вам очень не хочется копировать в стек саму структуру), то в принципе вы и тут можете пользоваться этим указателем из Umka, но на свой страх и риск: Umka не управляет памятью по этому указателю.
Не согласен. Разумеется, алгоритм не знает, что такое энергия и момент импульса, поэтому от него нельзя требовать, чтобы он искал именно закон сохранения энергии или момента импульса. Он ищет любые сохраняющиеся величины, не отдавая преимущества ни одной из них, кроме как в силу их встречаемости в пространстве поиска. Интерпретация этих величин - задача человека.
Для установления универсальности сохраняющейся величины можно запустить симулятор несколько раз с разными параметрами и начальными условиями. Тогда и окажется, что -10 в первом случае действительно остаётся неизменным, а 2 во втором случае изменится вместе с моментом импульса.
Если вы хотите найти этим алгоритмом по-настоящему неизвестное, то для начала надо предложить ему такую физическую систему, для которой вы не знаете законов сохранения. Я намеренно взял знакомую систему, чтобы проконтролировать результат.
У меня абсолютно тот же FEM, но только для одного типа задач (механическая деформация плоских пластин) и со многими оговорками про типы граничных условий.
Не совсем понял, каких интегралов вы ждали. Но те интегралы (по площади элемента), которых здесь действительно следовало ждать, скажем так, посчитаны аналитически и спрятаны в матрицу жёсткости элемента k. И интегралы эти самые простые: интегрируется постоянная относительная деформация и получается линейно нарастающее перемещение точек.
А что делать с силами, связями и материалом? Здесь в любом случае нужен специализированный редактор. Ну и вообще, продолжая вашу логику, можно просто взять ANSYS и сразу всё посчитать. Но удовольствие было не в этом.
А триангуляцию тоже на этих лабах писали?
Спасибо. При беглом просмотре увидел:
Счётчики ссылок
Сильные и слабые ссылки
Запрет на циклические сильные ссылки
Верно ли я понял? Если да, то как исполняется запрет?
Где-то можно прочесть про управление памятью?
Да, МКЭ — по сути, и есть метод перемещений, но доведённый до абсолютной формализации.
К сожалению, у нас в универе МКЭ демонстрировался только на одномерных задачах, что лишало его обаяния и оставляло недоумение ("Зачем огород городить? Рассчитать балку на растяжение я могу и попроще").
Мне и коллегам по проекту тоже нравится. Но приходилось слышать и шумное возмущение.
А что не так с типами словарей? В любом случае, как-то нужно указать два типа: ключа и значения.
Да, стандартная библиотека скудная. Рекомендую больше ориентироваться на пакеты из UmBox. Если чего-то всерьёз не хватает — не стесняйтесь просить.
Помню ваш проект и первую статью о нём. Рад, что затея жива. Наметились ли какие-нибудь применения языка? Или продолжаете чисто для собственного удовольствия и прокачки навыков?
Была опубликована ссылка на Discord.
Компиляция под Android пока ещё в разработке. Сейчас собираем под Windows, Linux, WASM.
В дистрибутиве Umka есть подсветка под Sublime Text. Существует также подсветка под Vim и VS Code, но она пока сыровата (можете поинтересоваться в канале Discord). Полноценный Language Server -- отдельная большая задача.
По меньшей мере, для тех, кого не устраивает Lua. А в остальном -- предлагаю посмотреть и поэкспериментировать самостоятельно. Мы будем только рады замечаниям и по языку, и по фреймворку. Разумеется, степень готовности Tophat меньше, чем Love2D.
Голова с руками нужна всегда -- милости просим! Донатами пока не интересовались.
Пока нет.
Управление памятью в Umka сделано на подсчёте ссылок. Чем не "отложенный способ"? Если на кусок памяти ссылается только одна переменная, то этот кусок будет освобождён как раз при выходе из области видимости переменной. Если ссылок больше -- то память освободится при обрывании последней из них. Метод классический и весьма надёжный. Уж точно лучше того, что было в V, когда я ещё пытался всерьёз воспринимать этот проект.
Возврат нескольких значений из функции? Да, как в Go. Но есть тонкости, когда нужно сделать функцию с реализацией на C, которая бы возвращала несколько значений.
Задача большая. Планируется только в Umka 2.
Umka -- интерпретируемый язык, в отличие от Go. Для запуска программы (*.um) нужен интерпретатор (*.exe). Если вы хотите использовать Umka именно как встроенный язык, то интерпретатор может стать частью вашего собственного *.exe. Для этого можно откомпилировать исходники Umka на C вместе с вашими (как это сделано для Tophat), можно носить с собой интерпретатор Umka как *.dll.
Есть такая задача. Но она тоже, вероятно, уедет на Umka 2.
Это просто множественное определение типов. Синтаксис такой же, как в Go.
Нет, и неспроста. Если делать объединения именно как в C, то они становятся опасными, поскольку позволяют, например, вручную перезаписать значение указателя. Можно было бы сделать объединения "защищёнными", то есть всегда хранящими и проверяющими описание конкретного типа данных, который в данный момент туда уложен. Но это уже очень похоже на интерфейсы, которые и так в Umka есть.
Не совсем понял, к чему здесь столь многословная реклама ML. Я думаю, при желании вы могли бы написать об этом отдельный пост. Если вам интересно моё мнение, отчего функциональные языки "обделены вниманием", то дело тут не в корпорациях, а в человеческой психологии. Функциональные языки предполагают совсем иной взгляд на то, что такое программа и программирование, нежели языки императивные. Видимо, большинству людей легче мыслить в понятиях "последовательности указаний", чем в понятиях "вычисления композиции функций". Однако всё это не имеет никакого отношения к теме моей статьи, поэтому вряд ли мне хотелось бы пускаться в пространные дискуссии.
Полная нелепость. Поскольку вы не дали определения ни V, ни R, то ваше утверждение бессмысленно. Если вы скажете, что V - это модуль скорости, а R - длина радиус-вектора, то оно превратится из бессмысленного в неверное.
Энергия (в расчёте на единицу массы) равна V²/2 - GM/R, и именно эта величина и сохраняется. Ваша же величина V²R не только не постоянна вдоль эллиптической орбиты (в чём вы можете легко удостовериться из того же численного моделирования), но даже по размерности не совпадает с энергией.
Могу только гадать, откуда вы её взяли, и свою догадку уже высказывал: из школьной формулы для круговой орбиты V²R = GM. В таком случае не забывайте, что, во-первых, это не энергия и она не обязана сохраняться, а во-вторых, эта формула неприменима к эллипсу, гиперболе и вообще хоть чему-нибудь кроме окружности.
Я понятия не имею, что вы называете "средним радиусом" эллипса. Такого понятия нет. Что за V? Что за R? Что останется от вашего равенства, когда сила не перпендикулярна скорости (а на эллипсе такое будет непременно)? У меня ощущение, что вы пытаетесь за уши притащить сюда какую-то аналогию с круговой орбитой из школьного учебника. Тщетное занятие.
Тогда собирайте измерительные данные сами, как Тихо Браге, или берите готовые данные от какой-нибудь обсерватории, подставляйте их вместо симулятора и проверяйте хоть законы Кеплера, хоть законы Ньютона.
Чтобы не быть голословным и заодно уберечь вас от псевдонауки, предлагаю вам код численного моделирования, которое как раз и демонстрирует справедливость третьего закона Кеплера (в предположении справедливости второго закона Ньютона и закона всемирного тяготения). Можете сами поварьировать в нём начальные условия для планет и убедиться, что получите для всех одно и то же отношение куба большой полуоси к квадрату периода (варьируйте осторожно, чтобы не получить гиперболическую траекторию). Надеюсь, это избавит и вас, и нас от россказней про "фальсификации" и т.п.
Нет. Численным моделированием можно проверить только корректность математических выкладок, но не справедливость закона как такового. Если в модель заложены неверные предпосылки, то получатся и неверные следствия. Моделированием можно, например, подтвердить, что из законов Ньютона следуют законы Кеплера, но это ничего не скажет нам о справедливости самих законов Ньютона.
Это неверно. Во-первых, не угловая скорость, а скорость изменения полярного угла. У материальной точки угловой скорости нет вовсе. У реальной планеты (тела конечных размеров) она есть, но не равна скорости изменения полярного угла из-за суточного вращения. Во-вторых, не масса зависит от этой скорости, а наоборот. Законы Ньютона первичны, а законы Кеплера - лишь их наблюдаемые следствия.
Чтобы судить о справедливости законов, стоит не читать древние трактаты, а проверять эти законы с карандашом, бумагой, компьютером и телескопом.
Если я правильно вас понял, то эта проблема возникает только когда потоки переключает некий внешний планировщик. В Umka нет поддержки "родных" потоков операционной системы; виртуальная машина Umka работает всегда в одном системном потоке. Внутри виртуальной машины может быть множество её собственных "потоков", но за их переключение отвечает сам программист, вызывая
fibercall(). Этот подход я позаимствовал из Lua и Wren.Разумеется. Но вариантов "куда подправлять" в рассматриваемой задаче не так уж много: 2 в степени 4 = 16. Если речь идёт о незнакомой (особенно большой) системе, конечно, нужен ручной или полуавтоматический отбор и анализ решений.
И кстати, эта задача трудна даже когда человек-исследователь сам берётся искать законы сохранения: независима ли сохраняющаяся величина от всех предыдущих? случайно ли величина сохраняется или это глубокий закон? В статье в Science цитируются исследования насчёт ошибок, которые люди при этом допускают.
Да. Если указатель не попадает ни на одну выделенную страницу кучи, значит и ссылки для него не считаются.
Другое дело, что иногда приходится и сам кадр для локальных переменных устраивать не в стеке, а в куче. Но это нюансы.
Не очень понятен вопрос. В Umka передаётся структура или указатель на структуру? Если структура, то у неё есть адрес в стеке Umka, и ничто не мешает этот адрес взять. Если указатель на структуру (вам очень не хочется копировать в стек саму структуру), то в принципе вы и тут можете пользоваться этим указателем из Umka, но на свой страх и риск: Umka не управляет памятью по этому указателю.
Не согласен. Разумеется, алгоритм не знает, что такое энергия и момент импульса, поэтому от него нельзя требовать, чтобы он искал именно закон сохранения энергии или момента импульса. Он ищет любые сохраняющиеся величины, не отдавая преимущества ни одной из них, кроме как в силу их встречаемости в пространстве поиска. Интерпретация этих величин - задача человека.
Для установления универсальности сохраняющейся величины можно запустить симулятор несколько раз с разными параметрами и начальными условиями. Тогда и окажется, что -10 в первом случае действительно остаётся неизменным, а 2 во втором случае изменится вместе с моментом импульса.
Если вы хотите найти этим алгоритмом по-настоящему неизвестное, то для начала надо предложить ему такую физическую систему, для которой вы не знаете законов сохранения. Я намеренно взял знакомую систему, чтобы проконтролировать результат.