Тогда была проблема найти информацию. Сейчас есть проблема не проще — отфильтровать информацию. Сложно начинать, когда тебе со всех сторон предлагают совершенно разные пути и никто не может объяснить, чем они отличаются. Я начинал программировать на спектруме (и это в 2000 году!) с одной книгой в руках и отлично вас понимаю. Но ещё я учусь программировать сейчас и считаю проблему поиска качественной информации не менее важной. Я находил фактические ошибки в самой рекомендуемой книге по изучению python, я вижу полнейшее безумие советов в каналах по JS и не вижу тенденций к улучшению. Неверные знания хуже их отсутствия. Поэтому наставник нужен как никогда.
Люди, хватит издеваться над человеком. Я тоже считаю позицию Zloy_starik крайне странной, но не вижу в ней причин для гонения и издевательств. Подобными высказываниями вы принижаете себя сильнее, чем его. Каждый имеет право на любую точку зрения и каждый имеет правое её высказывать. У вас есть право с ней не соглашаться, но нет права открыто насмехаться и унижать человека.
Спасибо за статью, пример взаимодействия с asio лучше любой синтетики. <holywar_mode="on"/>
Сколько уже копий сломано об эти корутины, но мне до сих пор не понятно. В бусте уже были нормальные корутины, что мешало внести в язык что-то похожее на boost::context? С чего вдруг предлагаемая модель обёрток над промисами лучше, чем корутины со стеком? Вот теперь придумывают, как использовать asio, хотя он уже работал с бустовыми корутинами. <holywar_mode="off"/>
Очень интересно, спасибо за статью. В вашу модель просто просятся автокаталитические процессы (например). Для демонстрации на клеточном автомате достаточно, чтобы жизнь потребляла ресурс и размножалась (это у вас есть) и происходило медленное восстановление ресурса, когда его никто не потребляет. Уже такая система может порождать очень интересные циклы и узоры. С некоторыми параметрами можно получать интересные деревья, кольцевые структуры и много чего ещё. Скорее всего это пригодится для многоклеточной жизни.
ИМХО, именно навигатор приводит к подобному поведению. В предложенной модели маршрут выбирается на основе загрузки всех дорог, а не только того, что может видеть водитель без навигатора. Ещё недавно, когда навигаторов не было, водители не были склонны к изменению маршрута, а ездили каждый день одинаково. Торопыги и таксисты были всегда, но даже они не имели полной картины, а объезжали локально видимые пробки.
Однако, я согласен, что навигаторы могут решать проблему пробок. Сейчас навигаторы предлагаю то самое эгоистическое решение — как лично мне доехать быстрее, но они могут предлагать другой маршрут, чтобы все ехали быстрее. Боюсь только что реальность куда сложнее указанного парадокса, и построить оптимальный алгоритм вообще невозможно.
Само упоминание цифры 14 — уже спойлер. Найти оптимальную стратегию не так сложно, и я думаю, что уважаемый ptyrss её знает. Потому как второе яйцо действительно кидается по одному этажу, не смотря на то, что стратегия первого сложнее. А вот доказать оптимальность и придти именно к 14, имхо, сложнее. Мне давали эту задачку, правда не в гугле, и к оптимуму пришлось придти перебором, хотя конечно же можно проще.
Они после такого будут ещё громче кричать, ведь теперь они видели, что Земля плоская. На видео закругление едва заметно и не противоречит ни идее с слегка выгнутым диском, ни оптическим иллюзиям. Говорить о шарообразности можно при полёте на несколько тысяч километров, где видна значительная часть планеты.
Так в том и дело, что это не tuple, а любая структура. Преобразовать структуру в tuple не так-то просто без «этого домостроя». Можете предложить реализацию шаблона с таким объявлением?
template <typename T>
auto as_tuple(T&& t) -> tuple<Types...>;
Здесь Types… — список типов полей структуры T. Для любого конкретного типа всё тривиально, а обобщённо? В статье описано, как это сделать, а где ещё есть что-то подобное? Это и называется открытием — что-то, что до недавнего времени казалось невозможным, ну или никто подобного не делал.
boost::multiindex вообще мимо. Там тонны метапрограммирования, но к сабжу отношения не имеет.
Да, это не runtime, это compile time reflection. От передаваемого value не требуется иметь специальные методы или перегружать специальные функции, или быть обработанным препроцессором. В то время как nlohmann json требует специальных методов.
Приведённый вами пример с json j2 = {...} создаёт объект типа json, а не типизированную структуру. Настоящая сериализация на основе рефлексии это что-то подобное:
Такое без препроцессора на C++ не сделать, но в статье показан приём, делающий нас на шаг ближе к желаемому. Имея итерацию по полям мы можем, потребовав каким-либо образом указать имена полей, решить задачу полностью.
Заглянул, не нашёл ничего, напоминающего рефлексию или автоматизацию. Как на основе обсуждаемой статьи сделать автоматическую сериализацию/десерализацию json я догадываюсь (хотя имена всё равно не вытащить, придётся делать ключами индексы и битовые представления типов). А в предложенном вами nlohmann json предлагается руками написать to_json и from_json.
А рефлексия это не обязательно строки. Это в первую очередь возможность, не глядя на типы, вытаскивать из объектов свойства. Да, в данном случае вытаскивать можно только по индексу. Но это уже даёт как минимум возможность итерироваться по полям произвольных структур, что уже достижение для C++.
Тема очень крутая, за текст +100500! Не так часто происходят такие открытия.
Придирка к языку статьи
в русском языке используется «строка» кода, а не линия.
Всё, что было рекомендовано до этого предложения. Возможно даже больше, все эксперименты не помню. Некоторое время назад я задался вопросом «в чём я верю науке, а что могу проверить?». Шарообразность земли была первым пунктом проверок. А потом ньютоновская механика. Дальше идти абсолютно фундаментально очень сложно, поэтому в биологии и антропогенезе, например, приходится гораздо больше доверять другим. Зато это даёт понимание откуда берётся необходимость научных рецензируемых журналов — абсолютно всё через себя пропустить невозможно.
Строго говоря Эратосфен не доказывал шарообразность, он лишь предположил и исходя из предположения измерил радиус. Тем же методом, которым Эретосфен измерял радиус шара, современные плоскоземельщики измеряют расстояние до солнца.
В том, что Земля — шар, не сомневался ещё Аристотель за сотню лет до измерений, да и он скорее всего не был автором идеи.
Вы же можете провести множество экспериментов и не верить слухам! Изучите годичное движение звёзд, съездите на юг или на север, измерьте наклонение полярной звезды, сравните полученную широту с картой. Понаблюдайте на море за кораблями на горизонте. Сфотографируйте лунное затмение, посчитайте динамику изменения яркости, если просто круглой формы тени недостаточно. Попросите друзей из других часовых поясов поучаствовать в замерах высоты солнца. Есть миллион разных способов для косвенного подтверждения шарообразностии гарантированного опровержения плоской и практически любой другой формы Земли.
Да, доказать шарообразность и исследовать форму сложно, но стремление к этому лучше, чем слухи.
Во многих астрономических магазинах есть разнообразные фильтры, в том числе те, которые ставятся сразу на матрицу. В основном ориентированы на пропускание линии водорода 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 строчки.
<holywar_mode="on"/>Сколько уже копий сломано об эти корутины, но мне до сих пор не понятно. В бусте уже были нормальные корутины, что мешало внести в язык что-то похожее на boost::context? С чего вдруг предлагаемая модель обёрток над промисами лучше, чем корутины со стеком? Вот теперь придумывают, как использовать asio, хотя он уже работал с бустовыми корутинами.
<holywar_mode="off"/>Однако, я согласен, что навигаторы могут решать проблему пробок. Сейчас навигаторы предлагаю то самое эгоистическое решение — как лично мне доехать быстрее, но они могут предлагать другой маршрут, чтобы все ехали быстрее. Боюсь только что реальность куда сложнее указанного парадокса, и построить оптимальный алгоритм вообще невозможно.
Здесь Types… — список типов полей структуры T. Для любого конкретного типа всё тривиально, а обобщённо? В статье описано, как это сделать, а где ещё есть что-то подобное? Это и называется открытием — что-то, что до недавнего времени казалось невозможным, ну или никто подобного не делал.
boost::multiindex вообще мимо. Там тонны метапрограммирования, но к сабжу отношения не имеет.
Да, это не runtime, это compile time reflection. От передаваемого value не требуется иметь специальные методы или перегружать специальные функции, или быть обработанным препроцессором. В то время как nlohmann json требует специальных методов.
Приведённый вами пример с json j2 = {...} создаёт объект типа json, а не типизированную структуру. Настоящая сериализация на основе рефлексии это что-то подобное:
Такое без препроцессора на C++ не сделать, но в статье показан приём, делающий нас на шаг ближе к желаемому. Имея итерацию по полям мы можем, потребовав каким-либо образом указать имена полей, решить задачу полностью.
Тема очень крутая, за текст +100500! Не так часто происходят такие открытия.
В том, что Земля — шар, не сомневался ещё Аристотель за сотню лет до измерений, да и он скорее всего не был автором идеи.
Да, доказать шарообразность и исследовать форму сложно, но стремление к этому лучше, чем слухи.
Как бы грубо не звучало, но скорее всего так. В физдвиижках давно научились правильно обрабатывать столкновения. Это же два бильярдных шара, там всё банально считается в лоб. Вывести формулы скоростей после соударения, да тут первокурсник справится! Главное правильно отследить момент удара, а не давать погружаться телам друг в друга за один кадр.
Для любопытства это здорово, но планета — не материальная точка, у неё размер есть. Взаимодействия на сравнимых с размером дистанциях уже интереснее. Материальной точке пофиг, а протяжённые объекты получат приливной градиент. Внутри планеты тоже всё будет не так. Ровно в центре гравитация вообще 0, а не бесконечность как в формуле G*M/R^2.
Моя мысль в том, что малые расстояния находятся за пределами применимости формул небесной механики, не надо пытаться добиваться точности от них.
Но скорее всего в вашей задаче не нужна эта безумная точность в окрестности ноля, для небесной механики достаточно ограничить расстояние радиусом планет. При сближении на такое расстояние посчитать соударение шариков (неупругих с потерями на нагрев).
Если же вы не обрабатывали это отдельно, а это был пролёт очень близко к центру масс, то всё ещё проще. Скорости около центров огромные, а влияние малейших изменений расстояния очень велико, поэтому любые погрешности (как метода, так и вычислительные) резко усиливаются. Выше писали про leap-frog, он не даст супер точности, но с энергией должно быть хорошо.
Рунге-Кутты 4 порядка всё же имеет 4-й порядок сходимости, соответственно O(h^4). Может вы имели в виду Рунге-Кутты 2-го порядка? Он действительно в 4 строчки.