Знаете, первый раз я хочу закрыть хабр и не возвращаться. Шрифты вообще невменяемые. Если сегодня утром они были просто мелкими, то сейчас они мелкие полужирные. Начертание цифр невменяемое, 1 вылазит за пределы, как в падонкаффском сленге. Я нЕ хОчУ ЧиТаТь ЭтИ зАбОрЧиКи. Интервалы — п#z$@ц, границ между блоками вообще не видно. Где комментарии, где пост, не понять.
Плотность информации упала в разы — читать по диагонали стало невозможно, а точнее не даёт прироста скорости. Похоже буду читать хабр не на сайте, а через агрегаторы, а если не получится, то ну нахер.
P.S. Пока писал жирность пофиксили, но всё так же плохо читается.
Без знаний вам даже в голову не придёт, что вам нужно умножать матрицы. Я видел код, где из двух матриц трансформации вытаскивались компоненты сдвига и скейла, чтобы просуммировать руками и создать из них матрицу. В то время как надо было просто перемножить исходные. Это проще, это быстрее писать, быстрее работает. Или поиск минимума через сортировку массива. Такое сплошь и рядом, но это же полный бред. С точки зрения абстракций всё хорошо, так как очень мало кто включает алгоритмическую сложность в свой интерфейс.
Абстракции это очень важно, но это два ортогональных навыка: абстракции программирования и математическая подготовка.
А я нигде и не писал про знание алгоритмов. Алгоритмические задачки они именно про мышление, а не знание. Чтобы написать бинарный поиск или какую-нибудь сортировку нужно именно мышление. А за одно и проверка опыта обработки краевых случаев, знания известных проблем (все возможные переполнения и выходы за границу). Такие алгоритмы выявляют массу проблем, которые будут встречаться в коде.
Видите ли в чём дело, обычно не перемножают. А того, кто этим занимается каждый день, нужно спрашивать более сложные вещи. Проблема часто не может быть решена на том уровне, на котором создана. То есть квалификация кандидата должна быть выше, чем уровень повседневных задач. Кроме того это индикатор общих и частных знаний — насколько глубоко человек погружается в ту или иную тему, на сколько интересуется смежными. Умножение матриц действительно считаю минимальным возможным знанием в геометрии и алгебре. Так же как и геометрический смысл и идею аффинных преобразований. Неспециалисту не надо влёт писать матрицу хитрой трансформации, но хотя бы представлять, как это работает.
С большинством проблема — оно создаёт стереотипы и ожидания. И такие вот статьи укрепляют стереотипы, что можно особо не учиться и пойти работать, обесценивают высшее образование и тд и тп. Может вместо выкидывания вопросов из собеседования лучше просто поднять общий уровень и научить решать эти задачи? Может так мы поднимем общее качество софта, которым пользуемся?
Ну вот опять 25. Почему все постоянно пишут, что алгоритмы никому не нужны. Если они не нужны вам, чтобы делать сайтики, то это не значит, что они не нужны никому. Я вот ни за что не возьму на работу человека, у которого есть высшее профильное образование, а он не знает, как оценить сложность алгоритма сортировки. Или высшее математическое без умения перемножить две матрицы на доске. Оба этих навыка мне нужны примерно раз в месяц, то есть постоянно. Отсутствие базовых навыков говорит о полном нежелании разбираться в том, как всё устроено.
Ну и логические задачки тоже могут быть полезны. Далеко не всем и не везде, но обычно в команде нужен хотя бы один круто соображающий человек для решения нестандартных проблем. Дебаг редко воспроизводящегося бага — очень сложная логическая задача, иногда нужны не инструменты и опыт, а просто мозги. Разумеется опыт первичен, а алгоритмы и логика вторичны, если вам нужен работник прямо сейчас. А вот для джунов всё наоборот — можно научить умного интересующегося человека, но раскачать логику «опытному» программисту на грани невозможного.
Это опера 12 тормозит? JS может быть, но рендер там самый быстрый. На слабых компах хром до сих пор может адски тормозить при обычном скроле, когда в фоне грузится десяток страниц. Это мой основной кейс гугления: открыть в фоне всю первую страницу выдачи и идти по вкладкам. Так вот опера не тормозила в этом случае никогда. Это ещё и единственный браузер, который начинал отображать текст страницы до полной загрузки — на медленном интернете это must have фича. И единственный браузер, который мог выравнивать страницу по ширине, что было следствием своего движка. А хром так не умеет.
Свой движок — свои фичи, а хромоклоны вообще все одинаковые.
Отредактировано Вероятно нужны ещё скобочки, чтобы вызвать функцию на созданном объекте:
double z=Add{ .y=20, .x=10 }();
Перепутал оператор double с оператором (). Вот такое приведение кажется опасным. Ещё никогда операторы неявного приведения до добра не доводили.
Но выглядит очень круто, никогда не смотрел на именованные аргументы с этой стороны.
Непонятно, как они собрались ставить рапторы на Falcon 9. Он точно не будет дросселироваться до уровня минимальной тяги мерлина, слишком уж мощный. Как возвращать ступень? Или они поставят один маленький раптор специально для посадки?
Правила перегрузки со списками инициализации вообще безумные. То, что один элемент списка приводит к поиску других конструкторов, регулярно ломает код. Например:
struct InitMap {
using Map = map<string, string>;
InitMap(Map m) {}
};
InitMap m({{"k", "v"}});
Компилятору непонятно, то ли конструктор копирования звать, то ли конструктор от map. Добавляем «пустой» элемент:
InitMap m({{"k", "v"}, {});
И всё работает. Самая магия, что вариант
InitMap m({{string("k"), "v"}});
Работает, а приведение обоих элементов нет:
InitMap m({{string("k"), string("v")}});
Это всё объяснимо и после поллитра, а то и больше, даже понятно. Но лучше бы не усложняли инициализацию. Задача сделать универсальную инициализацию на все случаи жизни так и не решена. Куча мест, где в шаблонах нельзя бездумно написать {}, иногда ещё и две версии приходится делать.
Спасибо за статью. Интересно.
Не совсем понятен вопрос, в чём преимущество перед диапазонами? Вы сами про них упоминаете, но в чём их минусы? Почему бы не пользоваться ими?
Там компонуемость лучше, написание функций проще и без макросов. Тот же пример из документации:
std::vector<int> vi{1,2,3,4,5,6,7,8,9,10};
using namespace ranges;
auto rng = vi | view::remove_if([](int i){return i % 2 == 1;})
| view::transform([](int i){return std::to_string(i);});
// rng == {"2","4","6","8","10"};
Ничто не мешает пользоваться ими уже сейчас. Да, не в std, но ranges-v3 уже работающая header-only имплементация. Принести её в проект ничего не стоит.
Предложите конфигурацию атмосферы, которая так делает. Максимум, на что способна наша — сплющивать луну у горизонта. Что-то мне подсказывает, что любые искажения атмосферы будут сжимать или тянуть солнце по-вертикали, но не будут влиять на горизонталь. Даже если Солнце в атмосфере земли. Для одного наблюдателя ещё возможно загнуть атмосферу, но не для всей же поверхности Земли.
Отвечу сразу нескольким сомневающимся по поводу большого Солнца и параллельности лучей. Самое очевидное: Солнце имеет одинаковые размеры везде. То есть перемещения по земле вносят очень маленькие изменения относительно расстояния до Солнца. Если же пытаться объяснять тени близким солнцем, то там могут получаться очень маленькие расстояния (обычно говорят про 6000км), что даст измеримые отклонения размеров солнца в зависимости от его положения на небе и места наблюдения.
Есть и друге подтверждения, например, наблюдение солнечных пятен, тонкие измерения расстояние до Луны, а Солнце точно дальше и тд и тп.
Этот аргумент сам по себе не доказывает шарообразность, это просто очередное подтверждение. Не могу ручаться за точность, но трёх замеров достаточно, чтобы отличить плоскую землю с маленьким солнцем, от большого далеко удалённого солнца. В случае сферической земли высота солнца линейно зависит от расстояния до экватора, в случае плоской тангенциальная. Трёх замеров достаточно чтобы отличить линейную от нелинейной зависимости. У меня были данные по Москве, Кирову и Ялте. Да, расстояния между ними я сам не измерял, но теория заговора отсекается бритвой Оккама.
Против плоской земли набрать доказательств можно ещё немало: наблюдать полярную ночь и перелететь южнее, где её нет (в личном опыте не совсем полярная ночь, но очень большая разница продолжительности суток). На плоской земле вообще не может различаться продолжительность дня. Что действительно сложно, так это доказать, что земля не является изогнутой лентой, тором, ещё какой-нибудь сложной формой, а именно геоид.
Вы знаете, я потратил около двух лет на сбор собственных доказательств, что земля — шар. Среди них: замеры высоты солнца в известных мне городах в дни солнцестояния, наблюдения лунного затмения, замеры высоты полярной звезды, наблюдение траекторий звёзд, и что важнее, планет. Это что касается лично проведённых наблюдений. Кроме того: разговор по скайпу с человеком из другого часового пояса, вплоть до противоположного, а на плоской земле невозможна разница в 12 часовых поясов. Примерно так же дошёл до трёх законов Ньютона. С всемирным тяготением сложнее, там скорее подтверждения, чем доказательства
Века до 18 можно дойти самому, дальше сложнее, можно проверять только выборочно. Но даже проверка неравенства Белла доступна любому желающему.
Может быть буду непопулярен с таким мнением, но: и что? Если мы не на эмбедед железе, то какое нам дело до размеров виртуальной таблицы? На скорость это, конечно, влияет, но как сильно? Интересно было бы посмотреть на бенчмарки, желательно из реального кода, где кроме вызовов есть что-то ещё. Порог скорости при переходе с невиртуального вызвова, который потенциально инлайнится, на виртуальный мне понятен. А как влияет размер vtbl угадывать не возьмусь.
Наши рассуждения уже зашли далеко в терминологическую область. Перечитал вики ещё несколько раз и наконец-то понял в чём проблема и почему я вас не понимаю. Определений вектора много, мне привычно то, что называется кортеж. А слово кортеж за 6 лет на ВМК (Лобачевский, Нижний Новгород) я слышал буквально пару раз и в других контекстах. Чтож буду знать, что это ещё одно место где общепринятая терминология отличается от той, которой меня учили. Ну или которую я понял, не буду всё валить на других.
Не первый раз надо сказать уже натыкаюсь. У нас аналитическая и регулярная функция на ТФКП (комплексные функции) вообще не так как у всех вводились и то, что обычно понимают под регулярной у нас было аналитической. Что понимали под регулярной уже не помню. Сильно мешало, когда я пытался пользоваться чем-то кроме конспектов.
Буду привыкать к слову кортеж, раз именно его имею в виду.
Я не спорю, но вектора существуют и вне векторного пространства. Чтобы множество векторов было векторным пространством нужна коммутативность и много чего ещё, это так. Но для определения самой сущности «вектор» этого не требуется.
Я соглашусь, что в случае афинного пространства у нас действительно сущности разделены на вектора и точки, чтобы не путать их друг с другом. Это действительно та область, где нельзя просто так сказать, что это одно и то же. Убедили.
Однако, согласитесь, что это в этой конкретной абстракции. Когда вы оперируете физическими величинами, вам не важно это разделение, так как множество точек само по себе является линейным пространством. Точно так же различия стираются во всех применениях над большинством пространств. То есть точка и вектор отличаются терминологически в рамках теории афинных пространств, но не отличаются в применениях.
Считайте этот аргумент «последней придиркой». В целом ваша аргументация принята.
Плотность информации упала в разы — читать по диагонали стало невозможно, а точнее не даёт прироста скорости. Похоже буду читать хабр не на сайте, а через агрегаторы, а если не получится, то ну нахер.
P.S. Пока писал жирность пофиксили, но всё так же плохо читается.
Абстракции это очень важно, но это два ортогональных навыка: абстракции программирования и математическая подготовка.
С большинством проблема — оно создаёт стереотипы и ожидания. И такие вот статьи укрепляют стереотипы, что можно особо не учиться и пойти работать, обесценивают высшее образование и тд и тп. Может вместо выкидывания вопросов из собеседования лучше просто поднять общий уровень и научить решать эти задачи? Может так мы поднимем общее качество софта, которым пользуемся?
Ну вот опять 25. Почему все постоянно пишут, что алгоритмы никому не нужны. Если они не нужны вам, чтобы делать сайтики, то это не значит, что они не нужны никому. Я вот ни за что не возьму на работу человека, у которого есть высшее профильное образование, а он не знает, как оценить сложность алгоритма сортировки. Или высшее математическое без умения перемножить две матрицы на доске. Оба этих навыка мне нужны примерно раз в месяц, то есть постоянно. Отсутствие базовых навыков говорит о полном нежелании разбираться в том, как всё устроено.
Ну и логические задачки тоже могут быть полезны. Далеко не всем и не везде, но обычно в команде нужен хотя бы один круто соображающий человек для решения нестандартных проблем. Дебаг редко воспроизводящегося бага — очень сложная логическая задача, иногда нужны не инструменты и опыт, а просто мозги. Разумеется опыт первичен, а алгоритмы и логика вторичны, если вам нужен работник прямо сейчас. А вот для джунов всё наоборот — можно научить умного интересующегося человека, но раскачать логику «опытному» программисту на грани невозможного.
Свой движок — свои фичи, а хромоклоны вообще все одинаковые.
Вероятно нужны ещё скобочки, чтобы вызвать функцию на созданном объекте:
Перепутал оператор double с оператором (). Вот такое приведение кажется опасным. Ещё никогда операторы неявного приведения до добра не доводили.
Но выглядит очень круто, никогда не смотрел на именованные аргументы с этой стороны.
Компилятору непонятно, то ли конструктор копирования звать, то ли конструктор от map. Добавляем «пустой» элемент:
И всё работает. Самая магия, что вариант
Работает, а приведение обоих элементов нет:
Это всё объяснимо и после поллитра, а то и больше, даже понятно. Но лучше бы не усложняли инициализацию. Задача сделать универсальную инициализацию на все случаи жизни так и не решена. Куча мест, где в шаблонах нельзя бездумно написать {}, иногда ещё и две версии приходится делать.
Не совсем понятен вопрос, в чём преимущество перед диапазонами? Вы сами про них упоминаете, но в чём их минусы? Почему бы не пользоваться ими?
Там компонуемость лучше, написание функций проще и без макросов. Тот же пример из документации:
Ничто не мешает пользоваться ими уже сейчас. Да, не в std, но ranges-v3 уже работающая header-only имплементация. Принести её в проект ничего не стоит.
Есть и друге подтверждения, например, наблюдение солнечных пятен, тонкие измерения расстояние до Луны, а Солнце точно дальше и тд и тп.
Против плоской земли набрать доказательств можно ещё немало: наблюдать полярную ночь и перелететь южнее, где её нет (в личном опыте не совсем полярная ночь, но очень большая разница продолжительности суток). На плоской земле вообще не может различаться продолжительность дня. Что действительно сложно, так это доказать, что земля не является изогнутой лентой, тором, ещё какой-нибудь сложной формой, а именно геоид.
Века до 18 можно дойти самому, дальше сложнее, можно проверять только выборочно. Но даже проверка неравенства Белла доступна любому желающему.
Не первый раз надо сказать уже натыкаюсь. У нас аналитическая и регулярная функция на ТФКП (комплексные функции) вообще не так как у всех вводились и то, что обычно понимают под регулярной у нас было аналитической. Что понимали под регулярной уже не помню. Сильно мешало, когда я пытался пользоваться чем-то кроме конспектов.
Буду привыкать к слову кортеж, раз именно его имею в виду.
Однако, согласитесь, что это в этой конкретной абстракции. Когда вы оперируете физическими величинами, вам не важно это разделение, так как множество точек само по себе является линейным пространством. Точно так же различия стираются во всех применениях над большинством пространств. То есть точка и вектор отличаются терминологически в рамках теории афинных пространств, но не отличаются в применениях.
Считайте этот аргумент «последней придиркой». В целом ваша аргументация принята.