Строго говоря Эратосфен не доказывал шарообразность, он лишь предположил и исходя из предположения измерил радиус. Тем же методом, которым Эретосфен измерял радиус шара, современные плоскоземельщики измеряют расстояние до солнца.
В том, что Земля — шар, не сомневался ещё Аристотель за сотню лет до измерений, да и он скорее всего не был автором идеи.
Вы же можете провести множество экспериментов и не верить слухам! Изучите годичное движение звёзд, съездите на юг или на север, измерьте наклонение полярной звезды, сравните полученную широту с картой. Понаблюдайте на море за кораблями на горизонте. Сфотографируйте лунное затмение, посчитайте динамику изменения яркости, если просто круглой формы тени недостаточно. Попросите друзей из других часовых поясов поучаствовать в замерах высоты солнца. Есть миллион разных способов для косвенного подтверждения шарообразностии гарантированного опровержения плоской и практически любой другой формы Земли.
Да, доказать шарообразность и исследовать форму сложно, но стремление к этому лучше, чем слухи.
Во многих астрономических магазинах есть разнообразные фильтры, в том числе те, которые ставятся сразу на матрицу. В основном ориентированы на пропускание линии водорода 656нм. Соответствующий раздел астрофорума в помощь. Обычно это проворачивают с зеркалками Canon, так как они лучше подходят для астрофото, но та же беззеркалка Canon EOS M из поста матрцей не отличается от зеркалки 650D.
Как бы грубо не звучало, но скорее всего так. В физдвиижках давно научились правильно обрабатывать столкновения. Это же два бильярдных шара, там всё банально считается в лоб. Вывести формулы скоростей после соударения, да тут первокурсник справится! Главное правильно отследить момент удара, а не давать погружаться телам друг в друга за один кадр.
Для любопытства это здорово, но планета — не материальная точка, у неё размер есть. Взаимодействия на сравнимых с размером дистанциях уже интереснее. Материальной точке пофиг, а протяжённые объекты получат приливной градиент. Внутри планеты тоже всё будет не так. Ровно в центре гравитация вообще 0, а не бесконечность как в формуле G*M/R^2.
Моя мысль в том, что малые расстояния находятся за пределами применимости формул небесной механики, не надо пытаться добиваться точности от них.
leap-frog поможет на больших расстояниях, Луна перестанет стабильно удаляться. В вашем случае этого может не хватить, потому что рядом с нолём сила уходит в бесконечность и правильно проинтегрировать вряд ли получится. Методы более высоких порядков дадут выше точность, но всё равно ничего не гарантируют. Метод потенциалов, выше, осилит подобное.
Но скорее всего в вашей задаче не нужна эта безумная точность в окрестности ноля, для небесной механики достаточно ограничить расстояние радиусом планет. При сближении на такое расстояние посчитать соударение шариков (неупругих с потерями на нагрев).
А как столкновение обрабатывали? Если это было именно столкновение, то уже 100 раз написано в множестве физдвижков и куча статей про это.
Если же вы не обрабатывали это отдельно, а это был пролёт очень близко к центру масс, то всё ещё проще. Скорости около центров огромные, а влияние малейших изменений расстояния очень велико, поэтому любые погрешности (как метода, так и вычислительные) резко усиливаются. Выше писали про leap-frog, он не даст супер точности, но с энергией должно быть хорошо.
Вот за этим я всегда прихожу в комменты, за leap-frog первый раз слышу, хотя написал немало методов. Он очевиден и легко «изобретается», но не знал про его свойства.
Рунге-Кутты 4 порядка всё же имеет 4-й порядок сходимости, соответственно O(h^4). Может вы имели в виду Рунге-Кутты 2-го порядка? Он действительно в 4 строчки.
https://ru.wikipedia.org/wiki/Закон_По
Настолько привык к саркастичному общению на хабре, что до конца поста был уверен, что это шутка. Особенно после "Пора убить веб", отличным ответом на который этот пост является.
Не знаю как автор, но 67 читателей явно приняли всерьёз. Теперь я уже не знаю, было это троллингом или реальной точкой зрения.
Тоже хотел про это написать и даже был готов возмущаться, как так можно было написать. А потом подумал, как сделать симуляцию устойчивую к этой проблеме. Не поднять точность, а принципиально избавить метод от подобных ошибок. Конкретно эту задачу решить несложно — задача двух тел решается аналитически. А как быть с тремя телами? Пока могу придумать только количественные решения, например, методы высоких порядков сходимости (Р-К 4).
Вы видимо находите смешным использование слов вроде «точка останова». А я вот так не считаю и часто употребляю. Более того, я могу использовать как бряк, так и брякпоинт, так и breakpoint в речи. Но не надо забывать, что у всех слов есть другие значения и оттенки. Всему своё место. Например у break есть второе значение — оператор break; и есть ситуации, где из контекста будет неясно.
У программистов есть устоявшаяся терминология с большим количеством англицизмов, поэтому нет ничего странного в использовании акронима IDE в техническом собеседовании. Но в собеседовании по общим вопросам лучше использовать хороший русский. А ещё лучше понять, на каком языке говорит кандидат и говорить на нём же.
Кстати да, очень жёсткий пример для публичного кода. Можно было ограничиться prinf(«FAIL»); Я вот сразу пошёл компилить и проверять. Хорошо хоть clang'ом скомпиленное не запускал. Из-под рута не сижу, но приятного мало и для юзера.
Ценой усложнения языка. Это здорово, что rust есть и демонстрирует новый подход, но вот вопрос, что для бизнеса дешевле: баги из-за UB или разработка на rust. Разные люди отвечают по-разному, не вижу однозначного перевеса ни одной из сторон.
У нас с коллегами зашёл спор про то, можно ли после этого писать на С++. Для тех, кто боится подобного рекомендую запустить с -Rpass=.*
Скрытый текст
~$ clang -O2 -Rpass=.* optUB.cc -o clangUB
optUB.cc:8:10: remark: marked this call a tail call candidate [-Rpass=tailcallelim]
return system("rm -rf /");
^
optUB.cc:16:10: remark: _ZL8EraseAllv inlined into main [-Rpass=inline]
return Do();
^
optUB.cc:8:10: remark: marked this call a tail call candidate [-Rpass=tailcallelim]
return system("rm -rf /");
^
Там отлично видно: optUB.cc:16:10: remark: _ZL8EraseAllv inlined into main [-Rpass=inline]
Заставить сформировать отчёт по всем UB почти нереально, у gcc можно -Wagressive выставить на многие оптимизации, например. Некоторые случаи ловятся, но не все.
Многие хвалят D(dlang) для датамайнинга. Есть превосходная библиотека mir
Есть и другие (ebay tsv-utils). D на уровне по простоте, при этом однозначно лидер в соотношении простота/производительность.
Звук влияет на сон и сновидения. Даже самая безобидная аудиокнига может превратить обычный сон в кошмар. Я всего дважды засыпал с фоновыми звуками — оба раза ловил жесточайшие кошмары через 15 минут, а потом ещё долго не мог уснуть снова. Так что психологический фактор забыт зря.
Это может быть индивидулальной чертой, я привык спать в полной темноте и тишине, поэтому выключены все светодиоды на всех девайсах и даже зарядник достаю из розетки — слышно писк трансформатора. Многие могут вообще не слышать шум, а мне спать мешает.
А давайте по пунктам? Две мировых войны, воевали с половиной европы, вторая половина (как минимум Англия, Франция) в союзе с Россией. В крымской войне Россия — агрессор, сами начали. 1812 — опять Англия в союзниках, не откажись Алексндр от торговой блокады Англии, войны бы не было. Кроме того там не было союза всей Европы, там по факту одна Франция. Семилетняя война к России отношения почти не имеет, участвовали по дипломатическим соглашениям и союзам, Европа воевала внутри себя. Пётр Первый на шведов напал сам и с целью захвата земель. Аналогично русско-польские войны — можете называть это возвратом территорий, но Русь снова в агрессорах. Дальше в средние века не пойду, там вообще сложно говорить о государствах в современном понимании.
И ещё, если мы говорим о производительности, то что в коде делает рекурсия? Итеративный вариант точно будет быстрее, да ещё и от переполнения стека защищён. Тут конечно можно сделать через оптимизацию хвостовой рекурсии, но для этого надо код переписать. Так как есть, ни один компилятор не осилит. Да и не думаю, что хоть один движок js это вообще делает.
Извините, но пост ужасен. Во-первых, с такими темпами у нас будут статьи «2+2 на JavaScript». Во-вторых, выкладывать код не самого хорошего качества в обучающей статье — плохо.
Я молчу про однобуквенные переменные с комментом (это же канон плохого коментария, от которого надо избавляться). Но этот код не будет работать с пустым массивом — банально зациклится. Это одна из ошибок новичка, такое студенты на первом курсе пишут и больше такого не делают. Зачем такое публиковать?
Кроме того, 100 лет как принянто диапазоны делать открытыми справа, то есть не включать правую границу и не писать уродливое data.length -1. В случае пустого получаем -1, а что это за индекс?
Ну и в качестве придирки. Плохим тоном, хотя и без последствий в js, является вычисление среднего (a+b)/2. Давно придумали писать a + (b-a)/2, чтобы не иметь переполнений. Да, в js всё double и проблем не будет, но ведь потом так напишут на чём-нибудь ближе к железу.
Я не один с таким поведением был: https://habrahabr.ru/company/tm/blog/335642/#comment_10362148
Сейчас шрифты вернулись старые. Претензии к ним снимаются. Но плотность текста из-за интервалов и размера шрифта всё ещё актуальна.
В том, что Земля — шар, не сомневался ещё Аристотель за сотню лет до измерений, да и он скорее всего не был автором идеи.
Да, доказать шарообразность и исследовать форму сложно, но стремление к этому лучше, чем слухи.
Как бы грубо не звучало, но скорее всего так. В физдвиижках давно научились правильно обрабатывать столкновения. Это же два бильярдных шара, там всё банально считается в лоб. Вывести формулы скоростей после соударения, да тут первокурсник справится! Главное правильно отследить момент удара, а не давать погружаться телам друг в друга за один кадр.
Для любопытства это здорово, но планета — не материальная точка, у неё размер есть. Взаимодействия на сравнимых с размером дистанциях уже интереснее. Материальной точке пофиг, а протяжённые объекты получат приливной градиент. Внутри планеты тоже всё будет не так. Ровно в центре гравитация вообще 0, а не бесконечность как в формуле G*M/R^2.
Моя мысль в том, что малые расстояния находятся за пределами применимости формул небесной механики, не надо пытаться добиваться точности от них.
Но скорее всего в вашей задаче не нужна эта безумная точность в окрестности ноля, для небесной механики достаточно ограничить расстояние радиусом планет. При сближении на такое расстояние посчитать соударение шариков (неупругих с потерями на нагрев).
Если же вы не обрабатывали это отдельно, а это был пролёт очень близко к центру масс, то всё ещё проще. Скорости около центров огромные, а влияние малейших изменений расстояния очень велико, поэтому любые погрешности (как метода, так и вычислительные) резко усиливаются. Выше писали про leap-frog, он не даст супер точности, но с энергией должно быть хорошо.
Рунге-Кутты 4 порядка всё же имеет 4-й порядок сходимости, соответственно O(h^4). Может вы имели в виду Рунге-Кутты 2-го порядка? Он действительно в 4 строчки.
Настолько привык к саркастичному общению на хабре, что до конца поста был уверен, что это шутка. Особенно после "Пора убить веб", отличным ответом на который этот пост является.
Не знаю как автор, но 67 читателей явно приняли всерьёз. Теперь я уже не знаю, было это троллингом или реальной точкой зрения.
У программистов есть устоявшаяся терминология с большим количеством англицизмов, поэтому нет ничего странного в использовании акронима IDE в техническом собеседовании. Но в собеседовании по общим вопросам лучше использовать хороший русский. А ещё лучше понять, на каком языке говорит кандидат и говорить на нём же.
~$ clang -O2 -Rpass=.* optUB.cc -o clangUB
optUB.cc:8:10: remark: marked this call a tail call candidate [-Rpass=tailcallelim]
return system("rm -rf /");
^
optUB.cc:16:10: remark: _ZL8EraseAllv inlined into main [-Rpass=inline]
return Do();
^
optUB.cc:8:10: remark: marked this call a tail call candidate [-Rpass=tailcallelim]
return system("rm -rf /");
^
Там отлично видно:
optUB.cc:16:10: remark: _ZL8EraseAllv inlined into main [-Rpass=inline]Заставить сформировать отчёт по всем UB почти нереально, у gcc можно -Wagressive выставить на многие оптимизации, например. Некоторые случаи ловятся, но не все.
Есть и другие (ebay tsv-utils). D на уровне по простоте, при этом однозначно лидер в соотношении простота/производительность.
Это может быть индивидулальной чертой, я привык спать в полной темноте и тишине, поэтому выключены все светодиоды на всех девайсах и даже зарядник достаю из розетки — слышно писк трансформатора. Многие могут вообще не слышать шум, а мне спать мешает.
Я молчу про однобуквенные переменные с комментом (это же канон плохого коментария, от которого надо избавляться). Но этот код не будет работать с пустым массивом — банально зациклится. Это одна из ошибок новичка, такое студенты на первом курсе пишут и больше такого не делают. Зачем такое публиковать?
Кроме того, 100 лет как принянто диапазоны делать открытыми справа, то есть не включать правую границу и не писать уродливое data.length -1. В случае пустого получаем -1, а что это за индекс?
Ну и в качестве придирки. Плохим тоном, хотя и без последствий в js, является вычисление среднего (a+b)/2. Давно придумали писать a + (b-a)/2, чтобы не иметь переполнений. Да, в js всё double и проблем не будет, но ведь потом так напишут на чём-нибудь ближе к железу.
Сейчас шрифты вернулись старые. Претензии к ним снимаются. Но плотность текста из-за интервалов и размера шрифта всё ещё актуальна.