Сейчас в РФ школьники могут получать деньги от государства за победы в олимпиадах. Для Москвичей там даже приличные суммы, например 100-500т.р.. В регионах на пару порядков скромнее, например 4,5т.р, но тоже деньги.
Хотя рассчитывать окупить этим затраты на многочисленные разрекламированные курсы полагаю не стоит.
Я тоже "старый ворчун", который любит С++ именно за приоритет в производительности. На мой взгляд, в программах 99% кода работает с данными в которых нет никаких secret-тов и по умолчанию лишать этот код производительности ради 1% специального кода работающего с паролями и т.п. на мой взгляд явный перебор. Тем более что и сейчас ничего не мешает писать этот 1% специального кода безопасно. Да, для этого нужно больше внимания и понимания, но как раз этот 1% его в любом случае требует. Опциональный ключ -ftrivial-auto-var-init=pattern прекрасен для отладочных сборок и для того самого 1% критичного к безопасности кода, но это не повод пихать его везде не глядя.
[offtop] Сдаётся мне что вся эта шумиха с “жуткой вредностью” CO2 сильно преувеличена. А так называемое “вызванное им глобальное потепление” то ли естественные колебания климата, то ли как раз его восстановление к норме после аномального похолодания (об этом нынче много версий на ютубе). И деятельность современного человека в этом вопросе ничтожно мала.[/offtop]
При этом современные техногенные выхлопы содержат кучу по настоящему вредных веществ, вот лучше бы на борьбу с ними гранты тратили. Сизый смог над городами явно не из прозрачного СО2 состоит.
Во-вторых, если массив не расплющивать в один линейный, то любое обращение к нему будет через 2 адресации, вместо одной, что заметно медленнее. Так что не факт что ваша оптимизация вообще в плюс, хоть и минимальный.
В моих тестах на алгоритме Гаусса (решение системы линейных уравнений) сравнение двойной адресации и расплющивания в линейный массив дают:
на clang: производительность одинаково высокая (как в варианте с двойной адресацией на msvc).
на msvc: "расплющивание" мешает компилятору применять SSE / AVX векторизацию из-за чего вариант с двойной адресацией работает в 2-3 раза быстрее.
И это тесты без использования выигрыша от возможности быстрой перестановки строк.
Пруфы выложу позже, когда наиграюсь с этими эффектами и оформлю их в статью.
Не вникал в код и пока вообще не понял что здесь и о чем.
Просто возникла мысль, что если матрицу сделать в стиле С++, то перестановку строк можно будет делать очень быстро через перестановку ссылок на строки.
Дело в том, что исторически изначально электроны считались положительными. Именно с этой идеей и работали Ом, Кирхгоф и др. Потом узнали что электроны отрицательны, но в инженерной схемотехнике договорились считать что ток по прежнему течет от + к -, чисто для совместимости версий.
Да, это добавляет путаницу (совместимость она такая), но поменять местами + и - в уже созданной теории никто не решился.
С температурой замерзания/таяния я пока лично не игрался.
С кипением в микроволновке всё очень интересно. Если налить обычную воду в обычный стеклянный стакан и довести в микроволновке до кипения, потом достать стакан - кипение тут же прекратиться. Но если в эту только что переставшую кипеть воду сунуть термометр, то он покажет около ~105°С (бытовые термометры имеют полное право привирать на 1-2°С, но +5°С уже явно за пределами этой погрешности) и вокруг него вода начнёт кипеть - термометр (который не выделяет, а забирает тепло) в такой воде провоцирует кипение. Аналогичный эффект кипения вызывает любой предмет, например та же ложка, погружённая в такую воду. Но стенки стакана, в котором вода изначально кипятилась, кипение этой перегретой воды не провоцируют, точнее провоцируют, но при ещё более высокой температуре.
Не понял, а что мешает у нас публиковать свой авторский контент, прикладывая к нему свободную лицензию по "иностранному" шаблону?
Автор же явно написал что именно и на каких условиях можно делать с его контентом. Это же публичная оферта, на которую можно ссылаться или нет?
ПС: контент с "сиротским" авторским правом меня тоже напрягает в вопросе можно ли им воспользоваться, когда он вроде бы свободно гуляет по сети, или на самом деле нельзя.
Острая для меня тема: абстрактность математики - палка о двух концах. С одной стороны хорошо что математика развивается как универсальный самодостаточный инструмент, не ограниченный узкими прикладными задачами.
А с другой стороны, когда в задаче из естественных наук (физики, сопромата, биологии и т.д.) применяется математическое моделирование, то уже на этапе математической постановки задачи физический смысл сильно ограничивается и здесь нужно быть очень внимательным и аккуратным чтобы не потерять важные нюансы, а то и полностью утратить связь математической модели с физической реальностью.
Затем следуют абстрактные математические операции (интегрирование, дифференцирование, матричные операции и т.д.) в которых связь с физическим смыслом отсутствует полностью. Увидеть хоть какие-то проблески физического смысла в промежуточных вычислениях задача крайне нетривиальная и обычно никто этим заниматься даже не пытается. И это ещё одно место где математическая модель, сохраняя свою восхитительную математическую строгость, запросто может уплыть очень далеко от моделируемого реального объекта.
Наконец, после завершения математического моделирования, появляется возможность как-то проассоциировать полученный результат с физическим смыслом, но тут опять требуется большая аккуратность, а то нынче модно писать в естественно научных диссертациях фразы типа “достоверность исследования подтверждается строгостью применяемого математического аппарата” - простите, но математическая строгость и физическая (любая естественно научная) достоверность - это вообще из разных реальностей и связать их можно только очень аккуратным отслеживанием и экспериментальными проверками.
Подход - “заложу-ка я как-нибудь (уж как смогу, так заложу) в сложную, не понятно (мне) как работающую программу исходные данные, программа мне что-то там смоделирует, а я этому безоговорочно поверю” появился не с развитием современных моделирующих программ, а значительно раньше, просто до распространения компьютеров роль этих “непонятных” программ выполнял не менее абстрактный и сложный для детального понимания математический аппарат.
Планирую к написанию серию статей с конкретными примерами по этой теме, возможно и здесь их тоже размещу.
Тогда уж основателей тензорного счисления, имхо, скорее следует назвать сопроматчиками :) Но, наверно, всё же не стоит переносить на тот период современную классификацию естественных наук.
А я всегда считал что понятие тензора исторически выросло из описания напряжённо-деформированного состояния твердых тел (см. тензор напряжений и тензор деформаций) и только потом превратилось в самодостаточную математическую абстракцию, к которой можно привязывать разные физические смыслы (например, модели жидкости, электромагнитного поля и т.д.) или не привязывать его вовсе (математика самодостаточна и может, но не обязана иметь привязку к какому либо физическому смыслу). Или я ошибаюсь?
Я в детстве изготавливал спутники из медной проволоки и вместе с друзьями запускал их в космос. Для запуска спутник нужно было бросить точно в сторону яркого солнца, тогда он зацеплялся за солнечные лучи и на солнечной энергии улетал на орбиту. Если после запуска спутник удавалось найти, то значит бросок был недостаточно точный и запуск необходимо повторить. Если же найти его не удавалось - значит запуск прошёл в штатном режиме и спутник благополучно достиг орбиты. А однажды, в местах запуска спутников был найден кусок обгоревшей скомканной проволоки, отдалённо напоминающий один из моих давно и успешно улетевших спутников. Это стало надёжным наглядным подтверждением, что мои спутники не только улетают на орбиту, но ещё и иногда успешно оттуда возвращаются в обгоревшем от трения об атмосферу состоянии.
Понравилось ваше структурирование информации! Начиная с уточнения года прямо в названии! (а то часто находишь в сети такую "современную" заметку, а потом оказывается что ей уже 10 лет). И то, как информация разложена по полочкам. Что хотелось бы улучшить: - на тач-экране пример с "Resize Me" не ресайзится, а в примере CONTAINER QUERIES разделитель перемещается коряво, имхо мобильный интернет сейчас популярен и хочется чтобы примеры это учитывали; - в примере VIEW TRANSITIONS кнопки "+", "-" маленькие и расположены так что в режиме 1х их не видно даже при скролинге; - в примере SUBGRID потерялась картинка. А в остальном статья порадовала - спасибо!
Попался ещё способ сделать "дзиньк" японской бензопиле std::string hello = "hello"; std::wstring message = std::format(L"{}", hello);
Здесь вываливается сразу куча ошибок и все эти ошибки ведут внутрь кишков самого format, вместо того чтобы сообщить о том что format не умеет смешивать string c wstring и указать на место где я это попытался смешать. Во всяком случае в MSVC 2022 так, в других компиляторах не проверял.
А можете пояснить как совместить StringTable с модульностью? Если выносить всё строки в ресурсы то становится недостаточно включить/исключить заголовочный файл, надо ещё где то хранить список строк этого модуля и добавлять/удалять их в ресурсах.
PS: это не возражение - реально пробую осилить StringTable.
Мысли на счёт снятия стекла:
Сделать макеты и пробовать на них
Сошлифовать стекло по контуру алмазным бором. Можно бормашинкой, можно ЧПУшником.
Пс: Понятно что поздно метаться, но раз уж анализ опыта то пусть будет.
Сейчас в РФ школьники могут получать деньги от государства за победы в олимпиадах. Для Москвичей там даже приличные суммы, например 100-500т.р.. В регионах на пару порядков скромнее, например 4,5т.р, но тоже деньги.
Хотя рассчитывать окупить этим затраты на многочисленные разрекламированные курсы полагаю не стоит.
Ага, особенно когда выделяешь память под массив, который по ссылке передается функции, которая его потом заполнит данными ;)
Я тоже "старый ворчун", который любит С++ именно за приоритет в производительности. На мой взгляд, в программах 99% кода работает с данными в которых нет никаких secret-тов и по умолчанию лишать этот код производительности ради 1% специального кода работающего с паролями и т.п. на мой взгляд явный перебор. Тем более что и сейчас ничего не мешает писать этот 1% специального кода безопасно. Да, для этого нужно больше внимания и понимания, но как раз этот 1% его в любом случае требует.
Опциональный ключ
-ftrivial-auto-var-init=patternпрекрасен для отладочных сборок и для того самого 1% критичного к безопасности кода, но это не повод пихать его везде не глядя.[offtop] Сдаётся мне что вся эта шумиха с “жуткой вредностью” CO2 сильно преувеличена. А так называемое “вызванное им глобальное потепление” то ли естественные колебания климата, то ли как раз его восстановление к норме после аномального похолодания (об этом нынче много версий на ютубе). И деятельность современного человека в этом вопросе ничтожно мала.[/offtop]
При этом современные техногенные выхлопы содержат кучу по настоящему вредных веществ, вот лучше бы на борьбу с ними гранты тратили. Сизый смог над городами явно не из прозрачного СО2 состоит.
В моих тестах на алгоритме Гаусса (решение системы линейных уравнений) сравнение двойной адресации и расплющивания в линейный массив дают:
на clang: производительность одинаково высокая (как в варианте с двойной адресацией на msvc).
на msvc: "расплющивание" мешает компилятору применять SSE / AVX векторизацию из-за чего вариант с двойной адресацией работает в 2-3 раза быстрее.
И это тесты без использования выигрыша от возможности быстрой перестановки строк.
Пруфы выложу позже, когда наиграюсь с этими эффектами и оформлю их в статью.
Не вникал в код и пока вообще не понял что здесь и о чем.
Просто возникла мысль, что если матрицу сделать в стиле С++, то перестановку строк можно будет делать очень быстро через перестановку ссылок на строки.
А можно привести примеры, где такое можно встретить на практике? Зачем оно может понадобиться?
Не все так просто:)
Дело в том, что исторически изначально электроны считались положительными. Именно с этой идеей и работали Ом, Кирхгоф и др. Потом узнали что электроны отрицательны, но в инженерной схемотехнике договорились считать что ток по прежнему течет от + к -, чисто для совместимости версий.
Да, это добавляет путаницу (совместимость она такая), но поменять местами + и - в уже созданной теории никто не решился.
А можете расшифровать эту магию.
Что здесь означает T& и T const & и зачем нужны они оба, а не только один из них?
С температурой замерзания/таяния я пока лично не игрался.
С кипением в микроволновке всё очень интересно. Если налить обычную воду в обычный стеклянный стакан и довести в микроволновке до кипения, потом достать стакан - кипение тут же прекратиться. Но если в эту только что переставшую кипеть воду сунуть термометр, то он покажет около ~105°С (бытовые термометры имеют полное право привирать на 1-2°С, но +5°С уже явно за пределами этой погрешности) и вокруг него вода начнёт кипеть - термометр (который не выделяет, а забирает тепло) в такой воде провоцирует кипение. Аналогичный эффект кипения вызывает любой предмет, например та же ложка, погружённая в такую воду. Но стенки стакана, в котором вода изначально кипятилась, кипение этой перегретой воды не провоцируют, точнее провоцируют, но при ещё более высокой температуре.
Не понял, а что мешает у нас публиковать свой авторский контент, прикладывая к нему свободную лицензию по "иностранному" шаблону?
Автор же явно написал что именно и на каких условиях можно делать с его контентом. Это же публичная оферта, на которую можно ссылаться или нет?
ПС: контент с "сиротским" авторским правом меня тоже напрягает в вопросе можно ли им воспользоваться, когда он вроде бы свободно гуляет по сети, или на самом деле нельзя.
Острая для меня тема: абстрактность математики - палка о двух концах. С одной стороны хорошо что математика развивается как универсальный самодостаточный инструмент, не ограниченный узкими прикладными задачами.
А с другой стороны, когда в задаче из естественных наук (физики, сопромата, биологии и т.д.) применяется математическое моделирование, то уже на этапе математической постановки задачи физический смысл сильно ограничивается и здесь нужно быть очень внимательным и аккуратным чтобы не потерять важные нюансы, а то и полностью утратить связь математической модели с физической реальностью.
Затем следуют абстрактные математические операции (интегрирование, дифференцирование, матричные операции и т.д.) в которых связь с физическим смыслом отсутствует полностью. Увидеть хоть какие-то проблески физического смысла в промежуточных вычислениях задача крайне нетривиальная и обычно никто этим заниматься даже не пытается. И это ещё одно место где математическая модель, сохраняя свою восхитительную математическую строгость, запросто может уплыть очень далеко от моделируемого реального объекта.
Наконец, после завершения математического моделирования, появляется возможность как-то проассоциировать полученный результат с физическим смыслом, но тут опять требуется большая аккуратность, а то нынче модно писать в естественно научных диссертациях фразы типа “достоверность исследования подтверждается строгостью применяемого математического аппарата” - простите, но математическая строгость и физическая (любая естественно научная) достоверность - это вообще из разных реальностей и связать их можно только очень аккуратным отслеживанием и экспериментальными проверками.
Подход - “заложу-ка я как-нибудь (уж как смогу, так заложу) в сложную, не понятно (мне) как работающую программу исходные данные, программа мне что-то там смоделирует, а я этому безоговорочно поверю” появился не с развитием современных моделирующих программ, а значительно раньше, просто до распространения компьютеров роль этих “непонятных” программ выполнял не менее абстрактный и сложный для детального понимания математический аппарат.
Планирую к написанию серию статей с конкретными примерами по этой теме, возможно и здесь их тоже размещу.
Тогда уж основателей тензорного счисления, имхо, скорее следует назвать сопроматчиками :) Но, наверно, всё же не стоит переносить на тот период современную классификацию естественных наук.
А я всегда считал что понятие тензора исторически выросло из описания напряжённо-деформированного состояния твердых тел (см. тензор напряжений и тензор деформаций) и только потом превратилось в самодостаточную математическую абстракцию, к которой можно привязывать разные физические смыслы (например, модели жидкости, электромагнитного поля и т.д.) или не привязывать его вовсе (математика самодостаточна и может, но не обязана иметь привязку к какому либо физическому смыслу).
Или я ошибаюсь?
А еще на ВДНХ меня впечатлили образцы оборудования для первых космических кораблей - там реально всё тщательно замотано синей изолентой!
Я в детстве изготавливал спутники из медной проволоки и вместе с друзьями запускал их в космос. Для запуска спутник нужно было бросить точно в сторону яркого солнца, тогда он зацеплялся за солнечные лучи и на солнечной энергии улетал на орбиту. Если после запуска спутник удавалось найти, то значит бросок был недостаточно точный и запуск необходимо повторить. Если же найти его не удавалось - значит запуск прошёл в штатном режиме и спутник благополучно достиг орбиты. А однажды, в местах запуска спутников был найден кусок обгоревшей скомканной проволоки, отдалённо напоминающий один из моих давно и успешно улетевших спутников. Это стало надёжным наглядным подтверждением, что мои спутники не только улетают на орбиту, но ещё и иногда успешно оттуда возвращаются в обгоревшем от трения об атмосферу состоянии.
Понравилось ваше структурирование информации!
Начиная с уточнения года прямо в названии! (а то часто находишь в сети такую "современную" заметку, а потом оказывается что ей уже 10 лет).
И то, как информация разложена по полочкам.
Что хотелось бы улучшить:
- на тач-экране пример с "Resize Me" не ресайзится, а в примере CONTAINER QUERIES разделитель перемещается коряво, имхо мобильный интернет сейчас популярен и хочется чтобы примеры это учитывали;
- в примере VIEW TRANSITIONS кнопки "+", "-" маленькие и расположены так что в режиме 1х их не видно даже при скролинге;
- в примере SUBGRID потерялась картинка.
А в остальном статья порадовала - спасибо!
Попался ещё способ сделать "дзиньк" японской бензопиле
std::string hello = "hello";std::wstring message = std::format(L"{}", hello);
Здесь вываливается сразу куча ошибок и все эти ошибки ведут внутрь кишков самого format, вместо того чтобы сообщить о том что format не умеет смешивать
stringcwstringи указать на место где я это попытался смешать.Во всяком случае в MSVC 2022 так, в других компиляторах не проверял.
А можете пояснить как совместить StringTable с модульностью?
Если выносить всё строки в ресурсы то становится недостаточно включить/исключить заголовочный файл, надо ещё где то хранить список строк этого модуля и добавлять/удалять их в ресурсах.
PS: это не возражение - реально пробую осилить StringTable.