Извиняюсь, что не очень в тему... Ищу удобное выражение для представления вектора вида y = [exp(0 j x), exp(1 j x), ..., exp(N j x)]. Матричная экспонента определяется обычно не как поэлементная операция. То есть y ≠ exp(j x)^[0, 1, 2, ..., N]. Может известен, так сказать, элегантный способ записи? Возможно, с использованием вектора натуральных степеней и тензорных операторов?
Не пришло в голову, что я должен думать о демократии, когда писал сообщение. Исправляюсь. Хотелось бы чтобы в РБ пришёл к власти пророссийский политик именно демократическим путём. Было бы странно хотеть определённых политиков не избранных народом, разве нет?
А я не понимаю желания приписать мне странные предпочтения. Это касается и другой части текста, где я якобы отрекаюсь от воевавших предков. С = Софизм.
усатой мрази, Лука является тем дерьмом
Похоже на тонкий анализ.
Лучше уж революция
Соседи. 2014 год.
На ваш эмоциональный пост возражать не стану. Мне жаль, если вы не счастливы со своим президентом. Желаю белорусам только лучшего. Собрался летом съездить в Гомель, очень ухоженный и красивый город.
Пробовал и через комментарии. Тратил очень много времени на корректный перевод технических терминов и правильное именование (это мне впоследствии помогло хорошо ориентироваться в импортной литературе, так что не зря). Проблема такого подхода в необходимости постоянно "подглядывать" в комментарии чтобы вспомнить имя какого-нибудь поля с нераспространённым или уникальным названием. В то время как русскоязычная аббривиатура постоянно наслуху. Другая проблема в отличии понятийных баз. Резюмируя, признаюсь, что конкретно в этом случае я не ругаюсь на коллег за транслитерации. Если вам будет интересно - пишите в личку - дам примеры, которые лучше пояснят глубину проблемы(?) в одной конкретной отрасли.
Нет, речь идёт не о способе передачи информации (TCP/UDP и т.д.), а о составе передаваемой информации. Например, о составе передаваемых данных между автоматизированными изделиями некоторого программно-аппаратного комплекса.
Я всегда интересуюсь из интереса :) Ни в РФ, ни в РБ я не хочу революцию. Также не хочу чтобы главой РБ стал западенец, т.к. это плохо для экономики и безопасности РФ. Поэтому рад, что фильтранули часть прозападных кандидатов. Если фильтранули пророссийских кандидатов - то я не рад.
Тут такое дело... Есть протокол, который определяет структуры сетевого обмена. Все поля этих структур (а их сотни) являются аббривиатурами рускоязычных терминов в одной узкоспециализированной области. Шах и мат. Только транслитерация.
Да. При этом ptrdiff_t = ssize_t. Оставляя знаковый бит, авторы не погнались за тем "чтобы было достаточно", ограничившись 2^31 на 32-битных платформах (или 2^63 на 64-битных). Это похоже не компромисс между аргументом в пользу адресной арифметики и в пользу организации знаковых циклов for.
Туплы совсем нечитабельно будут выглядеть, на мой взгляд. Против голого класса я бы не поморщился, хотя и предпочёл бы
int process(int arg, int *res1 = nullptr, int *res2 = nullptr)
в случае, если результаты не всем и не всегда нужны. Пример из qt:
QString::toFloat(bool *ok = nullptr)
Но мой подход не эталонный, у меня сишная деформация.
А в случае класса как же быть с фэншуйностью? Найдётся программист, который скажет: фу, богомерзкие голые поля класса, а сам класс не в отдельном модуле!
unsigned int / int может как-бы быть недостаточно…
Смотря для чего. В моей практике MAX_INT в 99,9% случаев заведомо достаточно (если забыть о существовании некоторых платформ с разрядностью < 32 бит).
Могу привести такой контраргумент на тему достаточности. Если Вы допускаете, что у вас, предположим, длина вектора может быть size_t (то есть на 32-битных платформах не 2^31, а 2^32 элементов), то я ожидаю, что ваш код адаптирован к работе с большими массивами памяти (от 4 Гб и выше). На самом деле почти всегда это не так. Подобная адаптация - это очень серьёзный и очень частный для конкретной задачи вопрос. Чтобы это понять, попробуйте произвольный вектор в своей программе забить 2^32 элементами и расскажите что получится (желательно не vector<uint8_t>, а что-нибудь позабористей). Если программа не упадёт по нехватке памяти, то обратите внимание на производительность и проверьте загрузку винта, на который пишется SWAP. Потом выключите свапирование, т.к. полагаться на него не очень правильно.
Подозреваю, что коллеги предлагают написать класс TheProcessFunctionResults... Ну, и, конечно, определить для класса конструкторы, сеттеры, геттеры и, возможно, операторы. Ну а метод TheProcessFunctionResults::stringifyError(), как вишенка на торте, не оставит никаких сомнения у читателя в необходимости наличия этого класса.
Спасибо за статью. Про миф, признаться честно, удивлён. Поделюсь своими соображениями, поправьте меня, если ошибаюсь. Считаю, что нет большой технической сложности встроить закладку, предположим, выводящую чип из строя с активацией по воздуху или по наводкам шины питания. Если Baikal-S проектируется с полной передачей HDL кодов, то, конечно, вероятность наличия закладок ниже и определяется вероятностью её встраивания на "выпекающем" заводе. Было бы интересно ваше мнение и, тем более, почитать статью, если вы её оформите. Ещё вопрос - а все корки Байкала куплены с открытыми кодами? Например Ethernet и PCIe4 контроллеры.
Прочитал Ваши комментарии и могу с ними согласиться. Про возможность перерезать нам производство, про мотивы перетащить TSMC в США и про возможное желание "взорвать". Но считаю, что при всём желании бахнуть, ни одна сторона конфликта на это не пойдёт. Для виновного в мировом кризисе микроэлектроники будут слишком велики политические издержки. Поэтому предположу, что фабрики будут беречь.
Согласен с вами. Одно дело - строго математическое совмещение данных с привлечением большого числа априорной информации (разные углы, разные функции рассеяния точки, разные полосы) и другое дело - выбор ядра свёртки для восстановления изображения (предположительно). Если уж возникают сомнения касательно результатов некоторых астрономических работ (что они иногда CLEANят из нескольких пикселей), то тут и подавно.
По-хорошему, чтобы понять что мы видим, нужно брать несколько сырых кадров, строить трек, пытаться достичь субпиксельного разрешения, делать оценку достоверности.
Не буду спорить, поскольку считаю также. Пытаюсь лишь понять не ограничены ли мы в рассуждениях. И так ли это свойственно гипотетическому цифровому разуму. Всё таки критерий жив/мёртв там отличается от привычного нам. Отключение от питания на века при сохранности носителя - лишь перемотка времени вперёд.
Сфера Дайсона - вообще сомнительный концепт... Возможно, только человеку пришла в мозг столь бестолковая мысль. Будто бы цивилизации должны развиваться так как мы в последние пару столетий - по пути наращивания энергетических возможностей и масштабов инженерных сооружений. Не удивлюсь, если такие цивилизации живут до первого самоподрыва.
Про цифровизацию разума - интересная мысль. Точно не более тупиковая, чем перспективы кожаных видов. На эту тему интересно подумать про исполнительные механизмы таких существ. Чтобы минимизировать вероятность собственного исчезновения цифровые виды должны производить и распространять собственные цифровые копии. То есть производство должно быть побочной необходимостью их существования. А в случае экспансии производство, возможно, должно быть саморазворачивающимся.
Ещё интересно подумать на тему устремлений гипотетических цивилизаций. Человеческий мотив обеспечить собственную выживаемость, предположительно, стоит на инстинкте самосохранения, сохранения потомства и стайных паттернах поведения. На сколько это универсальное устремление?
Извиняюсь, что не очень в тему... Ищу удобное выражение для представления вектора вида
y = [exp(0 j x), exp(1 j x), ..., exp(N j x)].
Матричная экспонента определяется обычно не как поэлементная операция. То есть
y ≠ exp(j x)^[0, 1, 2, ..., N].
Может известен, так сказать, элегантный способ записи? Возможно, с использованием вектора натуральных степеней и тензорных операторов?
Не пришло в голову, что я должен думать о демократии, когда писал сообщение. Исправляюсь. Хотелось бы чтобы в РБ пришёл к власти пророссийский политик именно демократическим путём. Было бы странно хотеть определённых политиков не избранных народом, разве нет?
А я не понимаю желания приписать мне странные предпочтения. Это касается и другой части текста, где я якобы отрекаюсь от воевавших предков. С = Софизм.
Похоже на тонкий анализ.
Соседи. 2014 год.
На ваш эмоциональный пост возражать не стану. Мне жаль, если вы не счастливы со своим президентом. Желаю белорусам только лучшего. Собрался летом съездить в Гомель, очень ухоженный и красивый город.
Пробовал и через комментарии. Тратил очень много времени на корректный перевод технических терминов и правильное именование (это мне впоследствии помогло хорошо ориентироваться в импортной литературе, так что не зря). Проблема такого подхода в необходимости постоянно "подглядывать" в комментарии чтобы вспомнить имя какого-нибудь поля с нераспространённым или уникальным названием. В то время как русскоязычная аббривиатура постоянно наслуху. Другая проблема в отличии понятийных баз. Резюмируя, признаюсь, что конкретно в этом случае я не ругаюсь на коллег за транслитерации. Если вам будет интересно - пишите в личку - дам примеры, которые лучше пояснят глубину проблемы(?) в одной конкретной отрасли.
Нет, речь идёт не о способе передачи информации (TCP/UDP и т.д.), а о составе передаваемой информации. Например, о составе передаваемых данных между автоматизированными изделиями некоторого программно-аппаратного комплекса.
Я всегда интересуюсь из интереса :) Ни в РФ, ни в РБ я не хочу революцию. Также не хочу чтобы главой РБ стал западенец, т.к. это плохо для экономики и безопасности РФ. Поэтому рад, что фильтранули часть прозападных кандидатов. Если фильтранули пророссийских кандидатов - то я не рад.
Тут такое дело... Есть протокол, который определяет структуры сетевого обмена. Все поля этих структур (а их сотни) являются аббривиатурами рускоязычных терминов в одной узкоспециализированной области. Шах и мат. Только транслитерация.
Быть структурой для истинного эстета не является уважительной причиной не внедрять в неё методы ;)
Лечите ошибки линкера эффективно!
Не оставляйте неоднозначность!
gcc с флагом --std=c++17 почему-то ваш пример обругал ’has no member named ‘get’. Только так уговорил:
Не в пользу туплов здесь представляется несколько аргументов:
Получаем только 1 аргумент, либо все сразу
Указание аргумента по номеру, а не по имени
Код tuple<int,int,int> не самодокументирующий
Structured binding declarations пока некорректно воспринимается большинством редакторов (подчёркивает, код-комплит не работает)
Анархия вызовов при -O0, сложно делать отладку.
Не годится, если важен zero-overhead (копирований на стеке не избежать).
Обращение к самым последним стандартам (has no member)
С учётом сказанного, предпочёл бы выбор "паковать в класс" либо "писать по указателю".
Да. При этом ptrdiff_t = ssize_t. Оставляя знаковый бит, авторы не погнались за тем "чтобы было достаточно", ограничившись 2^31 на 32-битных платформах (или 2^63 на 64-битных). Это похоже не компромисс между аргументом в пользу адресной арифметики и в пользу организации знаковых циклов for.
Туплы совсем нечитабельно будут выглядеть, на мой взгляд. Против голого класса я бы не поморщился, хотя и предпочёл бы
в случае, если результаты не всем и не всегда нужны. Пример из qt:
Но мой подход не эталонный, у меня сишная деформация.
А в случае класса как же быть с фэншуйностью? Найдётся программист, который скажет: фу, богомерзкие голые поля класса, а сам класс не в отдельном модуле!
Также QT придерживается int-стиля.
Смотря для чего. В моей практике MAX_INT в 99,9% случаев заведомо достаточно (если забыть о существовании некоторых платформ с разрядностью < 32 бит).
Могу привести такой контраргумент на тему достаточности. Если Вы допускаете, что у вас, предположим, длина вектора может быть size_t (то есть на 32-битных платформах не 2^31, а 2^32 элементов), то я ожидаю, что ваш код адаптирован к работе с большими массивами памяти (от 4 Гб и выше). На самом деле почти всегда это не так. Подобная адаптация - это очень серьёзный и очень частный для конкретной задачи вопрос. Чтобы это понять, попробуйте произвольный вектор в своей программе забить 2^32 элементами и расскажите что получится (желательно не vector<uint8_t>, а что-нибудь позабористей). Если программа не упадёт по нехватке памяти, то обратите внимание на производительность и проверьте загрузку винта, на который пишется SWAP. Потом выключите свапирование, т.к. полагаться на него не очень правильно.
Подозреваю, что коллеги предлагают написать класс TheProcessFunctionResults... Ну, и, конечно, определить для класса конструкторы, сеттеры, геттеры и, возможно, операторы. Ну а метод TheProcessFunctionResults::stringifyError(), как вишенка на торте, не оставит никаких сомнения у читателя в необходимости наличия этого класса.
Извиняюсь. Сарказм от сишника.
Мда, измельчал нынче революционер. 15 суток и телега.
Вот Феликс Эдмундович, например. 11 лет каторг и туберкулёз.
Кстати, последний тоже из Польши наезжал, но результативней.
Спасибо за статью. Про миф, признаться честно, удивлён. Поделюсь своими соображениями, поправьте меня, если ошибаюсь. Считаю, что нет большой технической сложности встроить закладку, предположим, выводящую чип из строя с активацией по воздуху или по наводкам шины питания. Если Baikal-S проектируется с полной передачей HDL кодов, то, конечно, вероятность наличия закладок ниже и определяется вероятностью её встраивания на "выпекающем" заводе. Было бы интересно ваше мнение и, тем более, почитать статью, если вы её оформите. Ещё вопрос - а все корки Байкала куплены с открытыми кодами? Например Ethernet и PCIe4 контроллеры.
Прочитал Ваши комментарии и могу с ними согласиться. Про возможность перерезать нам производство, про мотивы перетащить TSMC в США и про возможное желание "взорвать". Но считаю, что при всём желании бахнуть, ни одна сторона конфликта на это не пойдёт. Для виновного в мировом кризисе микроэлектроники будут слишком велики политические издержки. Поэтому предположу, что фабрики будут беречь.
Согласен с вами. Одно дело - строго математическое совмещение данных с привлечением большого числа априорной информации (разные углы, разные функции рассеяния точки, разные полосы) и другое дело - выбор ядра свёртки для восстановления изображения (предположительно). Если уж возникают сомнения касательно результатов некоторых астрономических работ (что они иногда CLEANят из нескольких пикселей), то тут и подавно.
По-хорошему, чтобы понять что мы видим, нужно брать несколько сырых кадров, строить трек, пытаться достичь субпиксельного разрешения, делать оценку достоверности.
Не буду спорить, поскольку считаю также. Пытаюсь лишь понять не ограничены ли мы в рассуждениях. И так ли это свойственно гипотетическому цифровому разуму. Всё таки критерий жив/мёртв там отличается от привычного нам. Отключение от питания на века при сохранности носителя - лишь перемотка времени вперёд.
Сфера Дайсона - вообще сомнительный концепт... Возможно, только человеку пришла в мозг столь бестолковая мысль. Будто бы цивилизации должны развиваться так как мы в последние пару столетий - по пути наращивания энергетических возможностей и масштабов инженерных сооружений. Не удивлюсь, если такие цивилизации живут до первого самоподрыва.
Про цифровизацию разума - интересная мысль. Точно не более тупиковая, чем перспективы кожаных видов. На эту тему интересно подумать про исполнительные механизмы таких существ. Чтобы минимизировать вероятность собственного исчезновения цифровые виды должны производить и распространять собственные цифровые копии. То есть производство должно быть побочной необходимостью их существования. А в случае экспансии производство, возможно, должно быть саморазворачивающимся.
Ещё интересно подумать на тему устремлений гипотетических цивилизаций. Человеческий мотив обеспечить собственную выживаемость, предположительно, стоит на инстинкте самосохранения, сохранения потомства и стайных паттернах поведения. На сколько это универсальное устремление?