Уже отметили выше, но переформулирую. Из бесконечности последовательности шагов Ахилеса на конечной не следует и квантование пространства и времени. Как раз наоборот, если члены последовательности с какого-то момента перестанут ументшаться, то ряд разойдётся и дистанция будет бесконечной. Из того, что мы можем вообразить бесконечную делимость чего-либо совершенно не следует ни бесконечный размер, ни квантование. Апории Зенона отлично решаются матанализом, если вас интресует именно логическая сторона вопроса.
Что-то вы написали какие-то очень несовременные банальности, которые и без авто в языке были проблемами. Авто внёс свои, но ни одну из них вы не затронули. А вся эта игра с числами была всегда, например
float half = 1/2;
Вас же не удивляет, что здесь будет ноль?
Ну а противиться фиче через 12 лет после её внедрения, когда уже со всех сторон разобраны хорошие и плохие её применения, это как-то странно. У меня есть много кода, который без авто либо не написать вообще (сложные шаблоны), либо он будет выглядеть настолько ужасно, что читать его невозможно.
Я сам не люблю, когда авто используют слишком часто, или вообще рекоомендуют использовать везде. Слишком падает читаемость, IDE не всегда спасает. Но совсем отрицать - перебор. Моё личное требование - тип должен быть
либо написан в этой же строке кода, условно auto o = new Object();
либо быть сложным для написания, но очевидным (auto iter = vec.begin()),
либо быть очень сложным или невозможным для написания (сложные шаблонные выводы)
Имеет смысл рассматривать вопросы читаемости, не всем очевидные правила отбросывания ссылок, работу с промежуточными типами вроде vector<bool>::reference, а не вот эти наличия буковки f.
Простите, что докапываюсь до слов, а не содержимого, но очередь точно конкурентная, а не потокобезопасная или многопоточная? Если в английском concurrent (одновременный) тут применимо, то созвучное русское слово ну вообще же не в тему. Это не прямой перевод, не устоявшийся в русском термин.
Напомнило мне вопрос для собесов "Что происходит после того как вы набираете адрес сайта в браузере и жмёте enter". Очень глубокий вопрос, который подходит как новичкам, так и матёрым. При чём хорошо подсвечивает, чем именно человек занимался и на чём фокусировался. Условно админ больше расскажет про резолвинг имён, процесс подключения, JS программист про то, как сайты динамически подгружают сами себя, я вот могу больше про HTTP протокол и SSL handshake. То есть показывает глубину, ширину и область знаний.
Спасибо за статью, как раз то, что хотел почитать, но руки не доходили.
Я правильно понимаю, что можно дообучить таким образом ту же LLaMA на какой-нибудь большой доке и она начнёт ориентироваться в предмете? Или дать очень большой текст (условную войну и мир) и дальше сделать сокращённый пересказ и уточнить детали, пропущенные в нём? Если да, то буду рад разбору задач в будущем, ну или просто ссылкам по теме.
Очередной раз в С++ придумали, как сделать новую фичу на основе уже существующих, вообще для этого не задуманных. Это же почти static exceptions, которые может быть будут в следующих стандартах. И не поймите меня не правильно, мне очень понравилась идея и я даже ею воспользуюсь при необходимости, но почему-то весь С++ состоит из таких вот вещей, что настораживает.
Есть ли бенчмарки или разбор того, как компилятор это оптимизирует? Теоретически это всё сводится примерно к тому же коду, что был на ифах, но осиливает ли компилятор такие оптимизации? Не вносят ли корутины слишком много накладных расходов?
И почему Дейстра сделает 1 653 963 операций? Если в графе всего 5 ребёр, то это максимум 5 итераций, сотоящих из поиска минимума в очереди из не более 5 элементов и вставок в неё же. Это 5 * (log(5) + log(5)), что не более 30 базовых сравнений, а никак не миллион. Формулы же на худший случай, если случай лучше, то это не значит, что будет впустую молотить.
А почему |E| = 5? |E| - общее количество рёбер в графе, а не среднее на вершину. Так что для случая, когда есть хотя бы по одному ребру на вершину у вас не лучше |V|^2. Ну а если граф настолько уж разрежен, то и Дейкстра с нормальной очердью будет очень быстр. В очереди же лежат достижимые вершины, а не все, поэтому он быстро переберёт все достижимые и выйдет. За то же время количество посещённых вершин, что и у вас, только выбирать наименьший вес будет много быстрее, чем линейный поиск по всем рёбрам в графе.
Если вы утверждаете, что в каких-то случаях ваш алгоритм быстрее, то показали бы бенчмарки на этих примерах и сравнили бы с какой-нибудь готовой реализацей Дейкстры.
Соглашусь с вами, но не про данную модель. Горный велосипед - спортивный инвентарь. На нём можно ездить по городу и использовать как транспорт, но для этого гораздо лучше подходит городской велосипед: шоссейник, гибрид, да даже гравел. В городе MTB выглядит как прокаченный внедорожник (которые несомненно встречаются).
А в качестве горного и внедорожного у электрического есть большой минус - он тяжёлый, что очень плохо для маневренности и отработки неровностей. Единственное известное мне применение - полный привод для грязи и снега. Сам хотел поставить передний привод для глубокого снега зимой.
Запрещено. В силу требований потоковой безопасности в первую очередь. Вот только не всем она нужна, особенно с учётом её цены. Такой же пример - std::shared_ptr, его атомарный счётчик слишком уж дорог для многих применений. Имхо, это нарушение базового принципа "не платить за то, что не используешь". Поэтому мы отказались от этих довольно слабых гарантий (класс в целом всё равно не thread-safe) в пользу производительности в одном потоке.
P.S. Струкутуру проекта поправили, ссылка изменилась panda::string
Сложно утвержать сразу про все реализации std, но скорее нет, чем да. На 64-битной архитектуре sizeof(panda::string) == 40. Стандартная у меня 32 (Debian 11, GCC 10.2). То есть просто так передавать по значению тоже может быть чуть-чуть дороговато, лучше бы по ссылке. Но скопировать себе для хранения - ни о чём на фоне аллокации и копии в std.
Шёл 2023 год, а в статьях GCC 6.3. Не удивительно при оригинале статьи из 2017 года. При этом ни про устройство, ни про гарантии и потенциальный UB от повисших указателей. `string_view` - замечательная вещь, но хоть какие-нибудь размышления и сравнения с char* не помешали бы.
Ну и воспользуюсь случаем и порекламмирую panda::string. CopyOnWrite(CoW), все те же substr тоже без копирований и аллокаций, но с полной гарантией безопасности. Тот же SSO на 23 байта. Цена полной безопасности дешёвого subbstr - CoW не лучшим образом дружит с потоками. Но если не шарить стейт и передавать копии данных аккуратно, ну или как мы вообще не использовать потоки, то это совсем не цена.
Я так понял, что в векторе вы взяли magic_get (который нынче Boost.PFR) и развернули массив структур в структуру массивов. Интересное упражнение.
А что насчёт индексов и выборок? Для ECS же важно уметь выбирать наборы компонент. Типа для всех, содержащих компоненту Health и Collision, запустить систему нанесения урона при столкновении.
Немецкие власти запретили в школах земли Гессен Office 365 ещё в 2019 году. В июле текущего года Microsoft представила облачную услугу, которая позволит клиентам из государственного сектора использовать сервисы в соответствии с политикой ЕС.
Вот так, например? Да, французы ещё не сделали, но явно не в вакууме решение принимали.
Я не C, а C++ программист и может быть поэтому не понимаю, но как использовать сигналы вместо исключений? Для взаимодействия с другими процессами - понятно, но что толку слать сигнал самому себе? Стек после хэндлера будет тем же, выполнение продолжится со следующей после kill строки. Зачем?
Я действительно не специалист, но разве доказательство теоремы Белла не опровергает наличие скрытых параметров? Ок, остаются версии типа возможности путешествия во времени, но мы серьёзно будем их рассматривать?
Как-то слегка нелепо даже упоминать, не то что продвигать, теорию скрытых параметров, когда в этом году за практическое её низвержение дали нобелевку. Как минимум в том, что там честный рандом в связанных частицах, сомневаться уже давно не приходится. Алогритм в посте разобран интересно, но не надо так смеяться над теоретиками.
Есть и другое решение вопроса производительности - кэш. Мы реализовали банальный map по typeid и это стало тоже в разы быстрее. Да, всё ещё требует rtti, зато работает с любыми наследованиями (множественным виртуальным), не требует модификации базового класса и тд. https://github.com/CrazyPandaLimited/panda-lib/blob/master/clib/src/panda/cast.h
Уже отметили выше, но переформулирую. Из бесконечности последовательности шагов Ахилеса на конечной не следует и квантование пространства и времени. Как раз наоборот, если члены последовательности с какого-то момента перестанут ументшаться, то ряд разойдётся и дистанция будет бесконечной. Из того, что мы можем вообразить бесконечную делимость чего-либо совершенно не следует ни бесконечный размер, ни квантование. Апории Зенона отлично решаются матанализом, если вас интресует именно логическая сторона вопроса.
Что-то вы написали какие-то очень несовременные банальности, которые и без авто в языке были проблемами. Авто внёс свои, но ни одну из них вы не затронули. А вся эта игра с числами была всегда, например
Вас же не удивляет, что здесь будет ноль?
Ну а противиться фиче через 12 лет после её внедрения, когда уже со всех сторон разобраны хорошие и плохие её применения, это как-то странно. У меня есть много кода, который без авто либо не написать вообще (сложные шаблоны), либо он будет выглядеть настолько ужасно, что читать его невозможно.
Я сам не люблю, когда авто используют слишком часто, или вообще рекоомендуют использовать везде. Слишком падает читаемость, IDE не всегда спасает. Но совсем отрицать - перебор. Моё личное требование - тип должен быть
либо написан в этой же строке кода, условно auto o = new Object();
либо быть сложным для написания, но очевидным (auto iter = vec.begin()),
либо быть очень сложным или невозможным для написания (сложные шаблонные выводы)
Имеет смысл рассматривать вопросы читаемости, не всем очевидные правила отбросывания ссылок, работу с промежуточными типами вроде vector<bool>::reference, а не вот эти наличия буковки f.
Простите, что докапываюсь до слов, а не содержимого, но очередь точно конкурентная, а не потокобезопасная или многопоточная? Если в английском concurrent (одновременный) тут применимо, то созвучное русское слово ну вообще же не в тему. Это не прямой перевод, не устоявшийся в русском термин.
Напомнило мне вопрос для собесов "Что происходит после того как вы набираете адрес сайта в браузере и жмёте enter". Очень глубокий вопрос, который подходит как новичкам, так и матёрым. При чём хорошо подсвечивает, чем именно человек занимался и на чём фокусировался. Условно админ больше расскажет про резолвинг имён, процесс подключения, JS программист про то, как сайты динамически подгружают сами себя, я вот могу больше про HTTP протокол и SSL handshake. То есть показывает глубину, ширину и область знаний.
Спасибо за статью, как раз то, что хотел почитать, но руки не доходили.
Я правильно понимаю, что можно дообучить таким образом ту же LLaMA на какой-нибудь большой доке и она начнёт ориентироваться в предмете? Или дать очень большой текст (условную войну и мир) и дальше сделать сокращённый пересказ и уточнить детали, пропущенные в нём? Если да, то буду рад разбору задач в будущем, ну или просто ссылкам по теме.
Стоит отметить, что 9 это не рекорд, они уже делали 12. https://en.wikipedia.org/wiki/List_of_Falcon_9_first-stage_boosters#Booster_1051
Upd. Рекорд судя по всему 15. https://en.wikipedia.org/wiki/List_of_Falcon_9_first-stage_boosters#B1058
Очередной раз в С++ придумали, как сделать новую фичу на основе уже существующих, вообще для этого не задуманных. Это же почти static exceptions, которые может быть будут в следующих стандартах. И не поймите меня не правильно, мне очень понравилась идея и я даже ею воспользуюсь при необходимости, но почему-то весь С++ состоит из таких вот вещей, что настораживает.
Есть ли бенчмарки или разбор того, как компилятор это оптимизирует? Теоретически это всё сводится примерно к тому же коду, что был на ифах, но осиливает ли компилятор такие оптимизации? Не вносят ли корутины слишком много накладных расходов?
И почему Дейстра сделает 1 653 963 операций? Если в графе всего 5 ребёр, то это максимум 5 итераций, сотоящих из поиска минимума в очереди из не более 5 элементов и вставок в неё же. Это 5 * (log(5) + log(5)), что не более 30 базовых сравнений, а никак не миллион. Формулы же на худший случай, если случай лучше, то это не значит, что будет впустую молотить.
А почему |E| = 5? |E| - общее количество рёбер в графе, а не среднее на вершину. Так что для случая, когда есть хотя бы по одному ребру на вершину у вас не лучше |V|^2. Ну а если граф настолько уж разрежен, то и Дейкстра с нормальной очердью будет очень быстр. В очереди же лежат достижимые вершины, а не все, поэтому он быстро переберёт все достижимые и выйдет. За то же время количество посещённых вершин, что и у вас, только выбирать наименьший вес будет много быстрее, чем линейный поиск по всем рёбрам в графе.
Если вы утверждаете, что в каких-то случаях ваш алгоритм быстрее, то показали бы бенчмарки на этих примерах и сравнили бы с какой-нибудь готовой реализацей Дейкстры.
Соглашусь с вами, но не про данную модель. Горный велосипед - спортивный инвентарь. На нём можно ездить по городу и использовать как транспорт, но для этого гораздо лучше подходит городской велосипед: шоссейник, гибрид, да даже гравел. В городе MTB выглядит как прокаченный внедорожник (которые несомненно встречаются).
А в качестве горного и внедорожного у электрического есть большой минус - он тяжёлый, что очень плохо для маневренности и отработки неровностей. Единственное известное мне применение - полный привод для грязи и снега. Сам хотел поставить передний привод для глубокого снега зимой.
Запрещено. В силу требований потоковой безопасности в первую очередь. Вот только не всем она нужна, особенно с учётом её цены. Такой же пример - std::shared_ptr, его атомарный счётчик слишком уж дорог для многих применений. Имхо, это нарушение базового принципа "не платить за то, что не используешь". Поэтому мы отказались от этих довольно слабых гарантий (класс в целом всё равно не thread-safe) в пользу производительности в одном потоке.
P.S. Струкутуру проекта поправили, ссылка изменилась panda::string
Сложно утвержать сразу про все реализации std, но скорее нет, чем да. На 64-битной архитектуре sizeof(panda::string) == 40. Стандартная у меня 32 (Debian 11, GCC 10.2). То есть просто так передавать по значению тоже может быть чуть-чуть дороговато, лучше бы по ссылке. Но скопировать себе для хранения - ни о чём на фоне аллокации и копии в std.
Шёл 2023 год, а в статьях GCC 6.3. Не удивительно при оригинале статьи из 2017 года. При этом ни про устройство, ни про гарантии и потенциальный UB от повисших указателей. `string_view` - замечательная вещь, но хоть какие-нибудь размышления и сравнения с char* не помешали бы.
Ну и воспользуюсь случаем и порекламмирую panda::string. CopyOnWrite(CoW), все те же substr тоже без копирований и аллокаций, но с полной гарантией безопасности. Тот же SSO на 23 байта. Цена полной безопасности дешёвого subbstr - CoW не лучшим образом дружит с потоками. Но если не шарить стейт и передавать копии данных аккуратно, ну или как мы вообще не использовать потоки, то это совсем не цена.
Меня тоже не порадовал этот момент. Самокат тем и отличается от скутера или мотоцикла, что его легко занести домой. Где ещё его заряжать?
Я так понял, что в векторе вы взяли magic_get (который нынче Boost.PFR) и развернули массив структур в структуру массивов. Интересное упражнение.
А что насчёт индексов и выборок? Для ECS же важно уметь выбирать наборы компонент. Типа для всех, содержащих компоненту Health и Collision, запустить систему нанесения урона при столкновении.
Вот так, например? Да, французы ещё не сделали, но явно не в вакууме решение принимали.
Я не C, а C++ программист и может быть поэтому не понимаю, но как использовать сигналы вместо исключений? Для взаимодействия с другими процессами - понятно, но что толку слать сигнал самому себе? Стек после хэндлера будет тем же, выполнение продолжится со следующей после kill строки. Зачем?
Я действительно не специалист, но разве доказательство теоремы Белла не опровергает наличие скрытых параметров? Ок, остаются версии типа возможности путешествия во времени, но мы серьёзно будем их рассматривать?
Как-то слегка нелепо даже упоминать, не то что продвигать, теорию скрытых параметров, когда в этом году за практическое её низвержение дали нобелевку. Как минимум в том, что там честный рандом в связанных частицах, сомневаться уже давно не приходится. Алогритм в посте разобран интересно, но не надо так смеяться над теоретиками.
Есть и другое решение вопроса производительности - кэш. Мы реализовали банальный map по typeid и это стало тоже в разы быстрее. Да, всё ещё требует rtti, зато работает с любыми наследованиями (множественным виртуальным), не требует модификации базового класса и тд. https://github.com/CrazyPandaLimited/panda-lib/blob/master/clib/src/panda/cast.h