Здесь должна быть эта ссылка: https://github.com/ericniebler/range-v3
Библиотека диапазонов, которая покрывает не только рассмотренный случай генераторов, но и более сложные операции. Вообще очень полезна вся линейка постов, автор которых Eric Niebler.
Для набора высоты в 200км действительно надо немного, но тогда спутник упадёт обратно. Для выхода на орбиту надо ещё почти 8км/с. Так что стартовая скорость с земли не меньше 10км/с. В вакууме может и прокатило бы, но перегрузки при ударе об атмосферу будут адскими. Это в разы хуже, чем балистический спуск с орбиты и даже возвращение с Луны, потому что там верхние слои успевают сильно затормозить корабль, а на земле это будет удар об стену.
Сам себе отвечу, кажется понял. Там проходит плоскость эклиптики, а значит бывают планеты. Так как рассвет или закат, то вероятна Венера. Может и Юпитер.
Заглавная фотка сломала мне мозг. Мало того, что Орион перевёрнут (для наблюдателя из северного полушария), так ещё и что-то очень-очень яркое рядом с ним. Если Орион перевернуть обратно, то это как раз Сириус, но в таком положении мне непонятно. Там должен быть Альдебаран, но чтож так ярко-то?
Так и не смог найти описание оборудования. С азимуталом всё понятно, а труба?
Даже для очень простого инструмента слабо. Например, одиночный кадр на SW 1149 EQ2 из центра Москвы выглядит лучше. А это вторая по хилости экваториальная монтировка, пусть и с мотором, с самым планетным из возможных для неё телескопом.
Тут же только самый центр туманности, никаких интересных деталей. Да, эта техника применима для проработки этого яркого центра (хотя света на каждый кадр всё равно надо раз в 5 больше), чтобы потом использовать как часть результата. Но как итоговый результат очень слабо.
И не надо говорить, что професионалы понабежали. Я в этом году тоже впервые снимал М42. После стекинга даже у начинающих получается что-то вроде https://geektimes.ru/post/283328/#comment_9730906.
Понимание не приводит к беглости. Беглость приводит к пониманию.
Я конечно не учил иностранный и не ломал себе мозги с гуманитария на математика, но в корне не согласен. За собой не припомню ни одного случая чтобы «Беглость приводит к пониманию», зато в большинстве случаев наблюдаю обратное. Сначала я понимаю, что такое интеграл, а потом учусь быстро брать их на экзамене.
Я согласен, что для понимания надо накопить критическую массу примеров использования, но она ничтожно мала по сравнению с тем, что требуется для беглого использования. Как пример — изучение английского языка. Я могу объяснить отличия Past Simple и Present Perfect и хитрые случаи их применения. Я успешно решаю задания на грамматику. Но в речи мне всё ещё требуется прокрутить правила или примеры в течении пары секунд. Если конечно это не простейшие случаи. Тесты грамматики вполне подтверждают уверенность в понимании, но о беглости не может быть и речи.
И как абсолютную противоположность я видел некоторых преподавателей математики в университетах. Это обычно дамы неопределённого возраста, которым доверяют темы не сложнее первого курса. Они быстро решают задачки из учебника, на автомате находят ошибки и показывают их студентам, но вообще ничего из себя не представляют как учёные. Хороший второкурсник ничуть не меньше понимает в предмете, но ему-то учиться и развиваться, а преподаватель «застрял». А всё потому, что это была девочка отличница, которая на зубрёжке может взять базовый уровень, но не может развиваться самостоятельно.
Вы, @#$, серьёзно? Теперь ещё и вакансии на главную хабра публиковаться будут? Это не просто «Я пиарюсь», это вообще превращение сайта в рекламную доску.
Выглядит хорошо, но сложно. За каждым решением стоит обоснование, но всё вместе выглядит монструозно. Может быть пример с калькулятором не очень удачный, может быть просто непонятна общая архитектура для которой всё придумано, но я не смог спроецировать что-нибудь на свои задачи. Я видел только гораздо более простые RPC, может быть в этом дело.
Ну и мелкое предложение для повышения читаемости: json лучше писать в сырых(raw) литералах, чтобы не приходилось экранировать кавычки. У вас же всё равно С++11.
Километровые слои льда могут создавать очень большое давление. Например, при появлении замкнутых полостей заполненных водой и приливной деформации льда. Жаль, что узнаем мы не скоро — 6 лет лететь всё-таки, да и не спешит никто с запуском.
Не хотелось бы чтобы это выглядело как понты, но не вижу ничего ужасно сложного в данном коде. При необходимости любой С++ программист интересующийся шаблонами (укушенный Александреску) разберётся.
Тем, кто на этом не пишет, непонятно, но шаблоны это другой язык и его просто надо знать. Если знаете, то ничего сложного, если нет, то китайская грамота.
Писал когда-то подобное для лаб по численным методам. Но у меня было просто обобщённое представление функции и возможности собирать суперфункции (каррирование по сути) и подставлять аргументы (частичное применение). Производные — это очень круто, можно развивать дальше.
Хороший мануал, за vibe.d всегда респект.
На правах пожеланий: было бы очень неплохо добавить хотя бы ссылку на то, что такое UDA и немножко деталей об использовании в vibe.d. Например, до авторизации не мешало бы рассказать об атрибуте before.
Спасибо за статью!
При всём том качестве гифок и объёме проделанной работе, пост про один хоткей? Вы серьёзно? При том что фича весьма известная и обычный мультикрусор по альту умеет множество редакторов. Вимеры вообще тихо хихикают от подобных «фич».
Никак. По крайней мере в продакшн коде. Если надо будет мокнуть для теста, то переопределяются Add и AddRange и складываются. Требует знания о связи этих методов, не зовут ли друг друга, но тут мы возвращаемся к первому ответу: никак.
Возможность наследования — часть интерфейса класса и, внезапно, его тоже надо проектировать. А если вы используете наследование для хаков против воли автора класса, то сами себе злобный Буратино. Вы ещё скажите, что package(или internal, только для этого пакета) область видимости это плохо и нарушает инкапсуляцию.
А вот проектировать под наследование многие действительно не умеют, а потом наезжают на ООП.
под сложностью мы понимает взвешенную сумму всех выполненных над заданным набором данных элементарных операций, сложность которых мы можем указать априори
Вот в определении этих элементарных операций у нас и проблема. Вся статья про квадратный корень была про то, что принято рандомный доступ принято считать элементарной операцией, а он на самом деле гораздо сложнее. Хорошим теоретическим обоснованием было бы формальное представление структуры данных, включающей все уровни кэшей, памяти, свопа и тд. Со всеми подструктурами, алгоритмами, работающими на каждом уровне, пока мы не доберёмся до действительно элементарных операций. И тогда окажется, что мы таки зависим от железа, потому что кэши и алгоритмы выборок разные.
Да, sqrt(N) — совершенно среднепотолочная штука, да O нотация ничего не обещает, особенно когда её так неправильно используют, но пользоваться чем-то надо, а оно берёт и работает, не обещая.
Вы конечно правы, теоретически. Но вот на практике знать об асимптотике без возможности проецировать на задачу бессмысленно. Какие применения O нотации в программировании? Отсечь на ранних этапах совсем невозможное (O(e^n) при заведомо известных n > 100500) и оценить масштабируемость работающего решения. И в большинстве случаев масштабируемость оценивается очень хорошо. Линейный поиск на вдвое большем массиве работает вдвое медленней. А перебор всех пар (O(n^2)) — в 4 раза медленней. И это действительно работает и этим активно пользуются. Предложение считать доступ к памяти как O(sqrt(n)) вместо O(1) — всего лишь способ учесть на практике иерархии кэшей, просто эвристика. В любом инженерном деле таких допущений множество, эврситики проще точной теории. У математиков всегда волосы дыбом встают от того, что вытворяют физики и тем более инженеры. «Так нельзя!», зато работает.
При программировании же не асимптотика нужна, а просто прогноз масштабируемости, и с sqrt он будет ближе к правде.
Эта статистика показывает только одно — абсолютно всё равно, пробелы или табы. Можно юзать и то, и то, и никто от этого не умрёт. Кодстайлы в первую очередь должны быть одинаковыми у всех в проекте и лишь во вторую очередь учитывать мелкие плюсы и минусы пробелов/табов, переноса открывающей фигурной скобки, ширины отступа и тд.
https://github.com/ericniebler/range-v3
Библиотека диапазонов, которая покрывает не только рассмотренный случай генераторов, но и более сложные операции. Вообще очень полезна вся линейка постов, автор которых Eric Niebler.
Как же не видно?! Самая яркая блямба на фото.
Даже для очень простого инструмента слабо. Например, одиночный кадр на SW 1149 EQ2 из центра Москвы выглядит лучше. А это вторая по хилости экваториальная монтировка, пусть и с мотором, с самым планетным из возможных для неё телескопом.
Тут же только самый центр туманности, никаких интересных деталей. Да, эта техника применима для проработки этого яркого центра (хотя света на каждый кадр всё равно надо раз в 5 больше), чтобы потом использовать как часть результата. Но как итоговый результат очень слабо.
И не надо говорить, что професионалы понабежали. Я в этом году тоже впервые снимал М42. После стекинга даже у начинающих получается что-то вроде https://geektimes.ru/post/283328/#comment_9730906.
Я конечно не учил иностранный и не ломал себе мозги с гуманитария на математика, но в корне не согласен. За собой не припомню ни одного случая чтобы «Беглость приводит к пониманию», зато в большинстве случаев наблюдаю обратное. Сначала я понимаю, что такое интеграл, а потом учусь быстро брать их на экзамене.
Я согласен, что для понимания надо накопить критическую массу примеров использования, но она ничтожно мала по сравнению с тем, что требуется для беглого использования. Как пример — изучение английского языка. Я могу объяснить отличия Past Simple и Present Perfect и хитрые случаи их применения. Я успешно решаю задания на грамматику. Но в речи мне всё ещё требуется прокрутить правила или примеры в течении пары секунд. Если конечно это не простейшие случаи. Тесты грамматики вполне подтверждают уверенность в понимании, но о беглости не может быть и речи.
И как абсолютную противоположность я видел некоторых преподавателей математики в университетах. Это обычно дамы неопределённого возраста, которым доверяют темы не сложнее первого курса. Они быстро решают задачки из учебника, на автомате находят ошибки и показывают их студентам, но вообще ничего из себя не представляют как учёные. Хороший второкурсник ничуть не меньше понимает в предмете, но ему-то учиться и развиваться, а преподаватель «застрял». А всё потому, что это была девочка отличница, которая на зубрёжке может взять базовый уровень, но не может развиваться самостоятельно.
Ну и мелкое предложение для повышения читаемости: json лучше писать в сырых(raw) литералах, чтобы не приходилось экранировать кавычки. У вас же всё равно С++11.
Тем, кто на этом не пишет, непонятно, но шаблоны это другой язык и его просто надо знать. Если знаете, то ничего сложного, если нет, то китайская грамота.
На правах пожеланий: было бы очень неплохо добавить хотя бы ссылку на то, что такое UDA и немножко деталей об использовании в vibe.d. Например, до авторизации не мешало бы рассказать об атрибуте before.
Спасибо за статью!
Никак. По крайней мере в продакшн коде. Если надо будет мокнуть для теста, то переопределяются Add и AddRange и складываются. Требует знания о связи этих методов, не зовут ли друг друга, но тут мы возвращаемся к первому ответу: никак.
Возможность наследования — часть интерфейса класса и, внезапно, его тоже надо проектировать. А если вы используете наследование для хаков против воли автора класса, то сами себе злобный Буратино. Вы ещё скажите, что package(или internal, только для этого пакета) область видимости это плохо и нарушает инкапсуляцию.
А вот проектировать под наследование многие действительно не умеют, а потом наезжают на ООП.
Вот в определении этих элементарных операций у нас и проблема. Вся статья про квадратный корень была про то, что принято рандомный доступ принято считать элементарной операцией, а он на самом деле гораздо сложнее. Хорошим теоретическим обоснованием было бы формальное представление структуры данных, включающей все уровни кэшей, памяти, свопа и тд. Со всеми подструктурами, алгоритмами, работающими на каждом уровне, пока мы не доберёмся до действительно элементарных операций. И тогда окажется, что мы таки зависим от железа, потому что кэши и алгоритмы выборок разные.
Да, sqrt(N) — совершенно среднепотолочная штука, да O нотация ничего не обещает, особенно когда её так неправильно используют, но пользоваться чем-то надо, а оно берёт и работает, не обещая.
При программировании же не асимптотика нужна, а просто прогноз масштабируемости, и с sqrt он будет ближе к правде.