К текущему моменту протокол и реализация суть едины. Единственная де-факто реализация огромна, сложна и полна десятилетий различных нюансов, на которые явно или косвенно опираются всевозможные приложения или фреймворки. Никто уже не будет писать альтернативную реализацию X, все давно махнули рукой и теперь только два варианта: текущий X11, уж какой есть, и Wayland, который все равно неизбежен.
Это у Samyang только автомат экспозиции? =) Да они делают автофокусные объективы уже лет десять, если не больше. Причем с качеством на уровне родных (я не шучу, несколько их объективов выйди под маркой Sony/Fuji, никто бы и не удивился). У них недавно автофокусный зум вышел, а это вам не фунт изюму.
Viltrox делает автофокусные уже пару лет и отзывы о них тоже очень хорошие.
Первый автофокусный объектив Laowa уже продается. Meike и Brighting Star недавно выпустили анонс, но до магазинов их объективы ещё вроде не доехали.
У многих моделей есть честное кольцо апертуры, переключатели с кликом или без, авто и ручной фокус, настраиваемые (в камере!) функциональные кнопки. Вы в каких-то непонятных временах застряли, если думаете, что сторонние производители в чем-то заметно уступают.
Вот чего сторонние производители не могут, это автофокус выше определенного количества кадров в секунду (например родной объектив может бурст до 30 кадров в секунду, а сторонний только 15) и поддержку телеконверторов. Sony такое запрещает и чтобы продавать, приходится искусственно ограничивать.
А ну и ещё до автофокуса на магнитном подвесе (как в последних моделях Sony G и GM) пока китайские производители не дошли, но это дело времени.
А ещё Samyang, Tokina, Viltrox, Meike, Laowa и Brightin Star. Объективы, работающие в автоматическом режиме, нынче делают все китайцы, кому хоть сколько-нибудь не лень.
Но только для тех байонетов, владельцы которых не против, как например Sony, Nikon и Fujifilm. Потому что объективы ещё продавать надо.
Так HBM это просто быстрее. Один черт и у Apple, и у Intel со встроенным GPU память физически одна на все. Но в случае Intel до сих пор по каким-то причинам GPU не может пользоваться той же областью памяти, что и пользовательское приложение. В итоге данные передаются какими-то крюками, в разы медленнее, чем то же самое но внутри приложения или внутри GPU. Хотя память физически одна.
Интересно, что мешает остальным производителям сделать так же? Имею опыт работы с аппаратным ускорением обработки видео на CPU Intel и копирование кадра из "обычной" памяти приложения в GPU и обратно это не очень быстро. Они же все равно в одних и тех же чипах на одних и тех же плашках памяти в итоге хранятся!
В QR кодах обычно закодирована какая-то ссылка, что делает их бесполезными без возможности открыть эту ссылку.
В QR коде может быть спрятан код ошибки или пароль, но это единичные и довольно странные сценарии, одно-два слова намного проще написать прямо так. QR код всё-таки обычно для того, чтобы нажал, ещё раз нажал и оно само. Без интернета это не работает.
Механика -- это только ради кастомизации? Довольно широкое обобщение.
Я купил механическую клавиатуру потому, что мембранных с такими же ощущениями от работы (длинный ход, тактильный отклик) просто не существует. Клавиатуру не кастомизировал и не собираюсь. Максимум, кейкап Escape поменяю на красненький, просто потому что могу.
Бонусом у механических клавиатур как правило идёт большая прочность. Можно будучи раздраженным давить на клавиши со всей дури и клавиатура даже не скрипнет.
Библиотека языка это совсем базовые кирпичики. Знание алгоритмов в данном случае подразумевает понимание какие кирпичики в каком порядке надо составить, чтобы построить надёжный фундамент для дальнейшей логики программы.
Только вот таких систем, похоже, в мире просто не осталось. Еще в 2012 году на StackOverflow на вопрос а остались ли на практике такие системы смогли лишь найти один чрезвычайно частный случай со своим собственным компилятором и отметить, что системы не на дополнительном коде скорее всего успели выйти из активного употребления еще до стандартизации С.
Похоже что с практической точки зрения ничего кроме двоично-дополнительного кода для представления отрицательных чисел не существует.
Edit: хм, а какая разница какого цвета шапка D, если C знает, что у него и B разного? Он же видит B, значит у него противоположного и на этом все.
В условиях указано: шапок четыре, белых и черных поровну, то есть по две штуки. D видит две. Если они одинаковые, значит остались (в том числе у него) только противоположного цвета и он сразу говорит какого. Так как он молчит, значит те, что он видит (B и C) — не одного цвета. Если B и C не одного цвета, то C вполне достаточно цвета шапки B, чтобы сказать какого у него.
Обмен фальшивой купюры на мелкие настоящие и покупка это два независимых события. Сначала произошла замена подделки на настоящие деньги, а потом уже покупка и сдача выполнялись целиком настоящими деньгами. В задаче справедливо отмечено, что покупка вообще ни при чем, с тем же успехом покупатель мог просто попросить разменять купюру.
Потери несет только тот, у кого последнего на руках осталась фальшивая купюра и ровно в объеме фальшивой купюры.
А почему так получается, что несколько разработчиков одновременно меняют один и тот же код? В ситуации «мало ли кто-то уже это все поправил и сделал» что-то очень сильно пошло не так.
Если все скопом набросились на одну проблему в одном и том же месте, то либо распределение задач и коммуникация хромают, либо людей на проект многовато. Обычно все ровно наоборот, задач и кода намного больше чем разработчиков. Какое там пересекаться в изменениях кода, максимум git pull с fast-forward перед своим коммитом и все.
Вас же не смущает, что 5 и '5', var и &var, var и *var — это разные типы и/или сущности? Почему же вызывает удивление, что var и (var) тоже разные? =___=
Bazel, в отличие от cmake не основывается на командах, а позволяет декларативно описывать зависимости через правила. По сути, правила связывают несколько артефактов с определенной операцией. С помощью них bazel строит граф команд, который затем кэширует и исполняет.
Справедливости ради, современный CMake тоже склоняется к декларативному описанию проекта, пусть и командами: перечисляются таргеты, у них заполняются свойства, настраивается граф зависимостей, все. Описание сборки проекта, так сказать, в императивном стиле к нынешнему моменту считается дурным тоном. Хотя наличие такой возможности, увы, нередко провоцирует. Большое количество устаревшей документации тоже не помогает.
А что конкретно (время каких действий в рамках сборки) экономится в предложенном подходе?
Ведь все, что должно быть (пере)собрано, как ни крути придется собрать, в том или ином порядке. При сборке в несколько потоков CPU оказывается загружен на 100% и не сможет выполнить больше работы независимо от ее порядка.
Не какая ли тогда разница, соберутся ли две библиотеки за одну минуту параллельно (каждая за минуту) или последовательно (каждая за полминуты)?
Я уже настолько привык к цифровому отображению, что цифры считываются как единое число, 0852. Немного в другой системе счисления, конечно, после 59 не идет 60, но это тоже как-то само работает, «08 уже почти всё». Немного похоже на цены в магазине, где 899 воспринимается как «800 с чем-то там» разве что в фантазиях маркетолога.
К текущему моменту протокол и реализация суть едины. Единственная де-факто реализация огромна, сложна и полна десятилетий различных нюансов, на которые явно или косвенно опираются всевозможные приложения или фреймворки. Никто уже не будет писать альтернативную реализацию X, все давно махнули рукой и теперь только два варианта: текущий X11, уж какой есть, и Wayland, который все равно неизбежен.
Это у Samyang только автомат экспозиции? =) Да они делают автофокусные объективы уже лет десять, если не больше. Причем с качеством на уровне родных (я не шучу, несколько их объективов выйди под маркой Sony/Fuji, никто бы и не удивился). У них недавно автофокусный зум вышел, а это вам не фунт изюму.
Viltrox делает автофокусные уже пару лет и отзывы о них тоже очень хорошие.
Первый автофокусный объектив Laowa уже продается. Meike и Brighting Star недавно выпустили анонс, но до магазинов их объективы ещё вроде не доехали.
У многих моделей есть честное кольцо апертуры, переключатели с кликом или без, авто и ручной фокус, настраиваемые (в камере!) функциональные кнопки. Вы в каких-то непонятных временах застряли, если думаете, что сторонние производители в чем-то заметно уступают.
Вот чего сторонние производители не могут, это автофокус выше определенного количества кадров в секунду (например родной объектив может бурст до 30 кадров в секунду, а сторонний только 15) и поддержку телеконверторов. Sony такое запрещает и чтобы продавать, приходится искусственно ограничивать.
А ну и ещё до автофокуса на магнитном подвесе (как в последних моделях Sony G и GM) пока китайские производители не дошли, но это дело времени.
А ещё Samyang, Tokina, Viltrox, Meike, Laowa и Brightin Star. Объективы, работающие в автоматическом режиме, нынче делают все китайцы, кому хоть сколько-нибудь не лень.
Но только для тех байонетов, владельцы которых не против, как например Sony, Nikon и Fujifilm. Потому что объективы ещё продавать надо.
Например, павильоне на Луне. Там и гравитация натуральная, удобно будет.
Так HBM это просто быстрее. Один черт и у Apple, и у Intel со встроенным GPU память физически одна на все. Но в случае Intel до сих пор по каким-то причинам GPU не может пользоваться той же областью памяти, что и пользовательское приложение. В итоге данные передаются какими-то крюками, в разы медленнее, чем то же самое но внутри приложения или внутри GPU. Хотя память физически одна.
Интересно, что мешает остальным производителям сделать так же? Имею опыт работы с аппаратным ускорением обработки видео на CPU Intel и копирование кадра из "обычной" памяти приложения в GPU и обратно это не очень быстро. Они же все равно в одних и тех же чипах на одних и тех же плашках памяти в итоге хранятся!
Надо ещё немного увеличить количество светодиодов, чтобы каждый пиксель подсвечивался своим светодиодом... так, падажжи...
В QR кодах обычно закодирована какая-то ссылка, что делает их бесполезными без возможности открыть эту ссылку.
В QR коде может быть спрятан код ошибки или пароль, но это единичные и довольно странные сценарии, одно-два слова намного проще написать прямо так. QR код всё-таки обычно для того, чтобы нажал, ещё раз нажал и оно само. Без интернета это не работает.
Механика -- это только ради кастомизации? Довольно широкое обобщение.
Я купил механическую клавиатуру потому, что мембранных с такими же ощущениями от работы (длинный ход, тактильный отклик) просто не существует. Клавиатуру не кастомизировал и не собираюсь. Максимум, кейкап Escape поменяю на красненький, просто потому что могу.
Бонусом у механических клавиатур как правило идёт большая прочность. Можно будучи раздраженным давить на клавиши со всей дури и клавиатура даже не скрипнет.
Библиотека языка это совсем базовые кирпичики. Знание алгоритмов в данном случае подразумевает понимание какие кирпичики в каком порядке надо составить, чтобы построить надёжный фундамент для дальнейшей логики программы.
А какие, желательно кроссплатформенные, альтернативы вы могли бы привести в пример?
Похоже что с практической точки зрения ничего кроме двоично-дополнительного кода для представления отрицательных чисел не существует.
stackoverflow.com/questions/12276957/are-there-any-non-twos-complement-implementations-of-c
В условиях указано: шапок четыре, белых и черных поровну, то есть по две штуки. D видит две. Если они одинаковые, значит остались (в том числе у него) только противоположного цвета и он сразу говорит какого. Так как он молчит, значит те, что он видит (B и C) — не одного цвета. Если B и C не одного цвета, то C вполне достаточно цвета шапки B, чтобы сказать какого у него.
ЕМНИП в ответе ровно это и было написано.
Потери несет только тот, у кого последнего на руках осталась фальшивая купюра и ровно в объеме фальшивой купюры.
Если все скопом набросились на одну проблему в одном и том же месте, то либо распределение задач и коммуникация хромают, либо людей на проект многовато. Обычно все ровно наоборот, задач и кода намного больше чем разработчиков. Какое там пересекаться в изменениях кода, максимум git pull с fast-forward перед своим коммитом и все.
Вас же не смущает, что 5 и '5', var и &var, var и *var — это разные типы и/или сущности? Почему же вызывает удивление, что var и (var) тоже разные? =___=
Ведь все, что должно быть (пере)собрано, как ни крути придется собрать, в том или ином порядке. При сборке в несколько потоков CPU оказывается загружен на 100% и не сможет выполнить больше работы независимо от ее порядка.
Не какая ли тогда разница, соберутся ли две библиотеки за одну минуту параллельно (каждая за минуту) или последовательно (каждая за полминуты)?