Я вот откатился. В 8.1 иконки в панели задач компактнее, на ноуте это важно. И win 10 не поддерживает мою внешнюю звуковую плату, а свежих драйверов не было.
Вы правы: формулы на MathJax выглядят лучше SVG за счет субпиксельного сглаживания. Но это не имеет значения на экранах с высокой плотностью пикселей (ретина), а за ретиной будущее. Я вот уже почти два года смотрю на экран с ретиной и не могу нарадоваться.
MathJax не сможет построить такой график:
Кстати, вот его исходник (получается, если заменить в урле /svg/… на /g/...).
Посмотрите пост про мой редактор LaTeX + markdown. Я бы вообще не начал делать свой сервис по генерации качественных svg-картинок с формулами, если бы у MathJax не было недостатков.
Когда вы передаете содержимое формулы в URL, вы не знаете, блочная ли это формула, или строчная. Исторически скрипт tex.s2cms.ru/latex.js был написан раньше самого сервиса генерации картинок, использовался в моем движке S2 и работал сначала с codecogs.com.
Сервис codecogs.com генерировал строчную формулу, если начать ее с конструкции \inline. Я решил, что всегда буду использовать блочные формулы, а если надо — допишу \inline руками. (Это надо в редких случаях, например, чтобы уменьшить высоту дроби, добавляемой через \frac.)
К тому же ограничитель в виде двойных долларов почти наверняка никогда не встретится просто так в тексте страницы, так что не будет проблем с экранировкой.
Потом я сделал свой сервис и сохранил поведение с \inline для обратной совместимости.
А сейчас редактор сделал по аналогии. Еще проще написать одно дополнительное правило для markdown-it, добавляющее строчный элемент, чем два.
Также в эту схему удачно легла нумерация формул. Проще распарсить
$$...$$(1), когда это строчное содержимое одного блока, а не содержимое двух разных блоков, $$...$$ и (1).
Ворд 2003 не понимает картинки SVG. Я не знаю, что происходит в более новых версиях. В любом случае, при таком копировании формулы будут вставляться как картинки. Не думаю, что это удобно.
Задача моего редактора — подготовить html-код для публикации в вебе. Если вам нужен документ с кучей формул для печати, лучше всего сделать документ в самом латехе. В нем не так сложно разобраться, особенно когда под рукой гугл :)
На последнем графике есть интересный эффект, который я тоже наблюдал в мапле. Первые ~100 секунд ничего не происходит, а потом тело переворачивается с полупериодом ~50 секунд.
Я думаю, что это артефакт численных расчетов, потому что физических причин для такого поведения нет.
Скорее всего в момент переворачивания происходит потеря точности из-за округления, и численный расчет перескакивает к другой траектории на эллипсоиде Мак-Куллага, для которой период меньше. И, наверно, вместо замкнутой линии в ходе моделирования получается незамкнутая спираль.
Мне кажется, что если применить более точный метод численных расчетов, то полупериод на последнем графике будет ~200 секунд. Я больше доверяю времени до переворота, а не периоду «установившегося» движения, потому что оно растет как нужно, логарифмически:
Не совсем. На первых двух графиках три зеленых «зубца» смотрят в одну сторону, а четвертый в другую. На вторых двух — по два «зубца» смотрят вверх и вниз.
Вообще критические траектории из интерпретации Мак-Куллага делят эллипс на 4 части, в каждой из которых траектории своего типа.
Вот что пишет Журавлев
4 варианта начальных условий как раз соответствуют этим частям.
Принимаю поправку насчет терминов (возмущения и начальных условий). Но суть моего вопроса от этого не меняется.
Вектор момента импульса обходит траектории на эллипсоиде из интерпретации Мак-Куллага. Мой вопрос в том, какое время занимает этот обход. Время обхода у каждой траектории своё. Очевидно, выбор начальных условий эквивалентен выбору траектории, больше он ни на что не влияет.
Я поэкспериментировал с маплом. У меня получилось, что с уменьшением отклонения оси вращения от оси с промежуточным моментом инерции время обхода растет логарифмически. Из соображений размерности для угловой скорости время обхода должно быть таким: .
Логарифм наверняка можно получить из эллиптических функций, через которые в общем виде выражается решение уравнений для свободного вращения твердого тела.
Кстати, из первоначальной процитированной вами формулировки следует, что расстояние до переворота в 43 сантиметра повторялось от измерения к измерению. Скорее всего это объясняется неточностью изготовления гайки: ось ее вращения не совпадает с осью с промежуточным моментом инерции. Неопределенность начальных условий (то, как гайка болталась при закручивании) была небольшой и влияла меньше, чем несовпадение осей. Иначе гайка пролетала бы различные расстояния и переворачивалась бы в разные стороны.
Это вы выбрали возмущение малым, чтобы построить графики. Но ясно, что от величины возмущения будет зависеть, через какие промежутки времени тело переворачивается (у вас сейчас ~55 секунд). Иными словами, красные горизонтальные участки должны быть тем длиннее, чем меньше возмущение:
Если возмущение нулевое, то тело всегда будет вращаться вокруг оси с промежуточным моментом инерции, так как является решением (хоть и неустойчивым) уравнений (9).
Я тут подумал, а можно ли аналитически вычислить время переворачивания гайки (43 сантиметра из предыдущей статьи)?
С первого взгляда кажется, что это время зависит от возмущения . Если возмущение нулевое, время равно бесконечности. Какая зависимость времени переворачивания от ?
Было бы интересно с помощью моделирования определить время для нескольких значений возмущений и построить график.
Это всё уже не важно. Я сейчас проверил, и оказалось, что производитель выпустил драйвер для 10.
MathJax не сможет построить такой график:
Кстати, вот его исходник (получается, если заменить в урле /svg/… на /g/...).
Посмотрите пост про мой редактор LaTeX + markdown. Я бы вообще не начал делать свой сервис по генерации качественных svg-картинок с формулами, если бы у MathJax не было недостатков.
Когда вы передаете содержимое формулы в URL, вы не знаете, блочная ли это формула, или строчная. Исторически скрипт tex.s2cms.ru/latex.js был написан раньше самого сервиса генерации картинок, использовался в моем движке S2 и работал сначала с codecogs.com.
Сервис codecogs.com генерировал строчную формулу, если начать ее с конструкции \inline. Я решил, что всегда буду использовать блочные формулы, а если надо — допишу \inline руками. (Это надо в редких случаях, например, чтобы уменьшить высоту дроби, добавляемой через \frac.)
К тому же ограничитель в виде двойных долларов почти наверняка никогда не встретится просто так в тексте страницы, так что не будет проблем с экранировкой.
Потом я сделал свой сервис и сохранил поведение с \inline для обратной совместимости.
А сейчас редактор сделал по аналогии. Еще проще написать одно дополнительное правило для markdown-it, добавляющее строчный элемент, чем два.
Также в эту схему удачно легла нумерация формул. Проще распарсить
$$...$$(1), когда это строчное содержимое одного блока, а не содержимое двух разных блоков,$$...$$и(1).Формулы генерятся, кешируются и отдаются через nginx как статические файлы. Я уже описывал устройство сервиса.
Задача моего редактора — подготовить html-код для публикации в вебе. Если вам нужен документ с кучей формул для печати, лучше всего сделать документ в самом латехе. В нем не так сложно разобраться, особенно когда под рукой гугл :)
Я думаю, что это артефакт численных расчетов, потому что физических причин для такого поведения нет.
Скорее всего в момент переворачивания происходит потеря точности из-за округления, и численный расчет перескакивает к другой траектории на эллипсоиде Мак-Куллага, для которой период меньше. И, наверно, вместо замкнутой линии в ходе моделирования получается незамкнутая спираль.
Мне кажется, что если применить более точный метод численных расчетов, то полупериод на последнем графике будет ~200 секунд. Я больше доверяю времени до переворота, а не периоду «установившегося» движения, потому что оно растет как нужно, логарифмически:
Вообще критические траектории из интерпретации Мак-Куллага делят эллипс на 4 части, в каждой из которых траектории своего типа.
4 варианта начальных условий как раз соответствуют этим частям.
Вектор момента импульса обходит траектории на эллипсоиде из интерпретации Мак-Куллага. Мой вопрос в том, какое время занимает этот обход. Время обхода у каждой траектории своё. Очевидно, выбор начальных условий эквивалентен выбору траектории, больше он ни на что не влияет.
Я поэкспериментировал с маплом. У меня получилось, что с уменьшением отклонения оси вращения от оси с промежуточным моментом инерции время обхода растет логарифмически. Из соображений размерности для угловой скорости
Логарифм наверняка можно получить из эллиптических функций, через которые в общем виде выражается решение уравнений для свободного вращения твердого тела.
Кстати, из первоначальной процитированной вами формулировки следует, что расстояние до переворота в 43 сантиметра повторялось от измерения к измерению. Скорее всего это объясняется неточностью изготовления гайки: ось ее вращения не совпадает с осью с промежуточным моментом инерции. Неопределенность начальных условий (то, как гайка болталась при закручивании) была небольшой и влияла меньше, чем несовпадение осей. Иначе гайка пролетала бы различные расстояния и переворачивалась бы в разные стороны.
Если возмущение нулевое, то тело всегда будет вращаться вокруг оси с промежуточным моментом инерции, так как
С первого взгляда кажется, что это время зависит от возмущения
Было бы интересно с помощью моделирования определить время для нескольких значений возмущений и построить график.