Не могу согласиться с тем, что его анализ беспристрастный — у автора определенно есть свой взгляд на текущую ситуацию и своим письмом и, в частности, итоговыми вопросами он подталкивает её разрешение в определенном направлении. Не то чтобы это было плохо, но все же это попытка манипуляции, по моему мнению.
А текст, безусловно, хорош! )
Согласен с наблюдением автора, хотя тезис про запоминание сумм дву/трех-значных чисел надо бы проверить отдельно )
Наблюдая за развитием детей, можно вообще много разных параллелей провести с другими явлениями, в уже не детском возрасте.
Например, многие дети проходят стадию «вот это мое, делиться не хочу, наоборот, хочу ещё себе что-то взять». Это нормально, что с появлением концепции «вещь может быть твоей и поэтому тебе решать, что с ней делать» ребенок начинает ею активно пользоваться, и так же нормально, что потом новые концепции, типа «делиться своими игрушками выгодно, т.к. улучшает социальные связи» затмевают первую. Правда, немногие индивидуумы в своем развитии остаются на уровне «только мое, ..» или другой детской (неразвитой) мировоззренческой концепции.
В целом, уровень развития общества тоже проходит те же стадии, что ребенок, с другой скоростью, конечно. Примеры приводить лучше не буду )
Самый вежливый человек — это тот, кто обижается на каждый чих.
Потому что люди ожидают от других такой же реакции, как от себя.
Сергей подобную критику воспринял бы логически, а не эмоционально, и принял бы к сведению, вместо обижаться, потому что ему важен результат, а не ЧСВ.
Так что все вполне жизненно, я бы сказал )
В Вашем случае берется остаток от деления позиции валкодера (может быть отрицательныс числом) на кол-во пунктов меню (всегда положительное) — остаток от деления на отрицательное число не берется.
Отрицательная координата ещё куда ни шло, но речь идет о взятии остатка от деления на отрицательное число, а не отрицательного на положительное.
Конечно, Ваша ситуация вполне подошла бы, если бы размер чанка был отрицательным )
Если следовать этой логике, то -100 минут будет -2ч+20м, вместо -1ч40м.
Хотя стрелка будет указывать на 20м (если отсчитывать -100 минут от 0:00), да…
В общем, и так и так можно нарваться на неприятности, поэтому случаи с отрицательными числами при взятии остатка лучше обрабатывать отдельной логикой, а не полагаться на реализацию в компиляторе или cpu.
В статье описано, почему так не сделали — это сломает совместимость с существующими материнскими платами. Вариант, когда у каждого кристала есть по 2 личных канала используется в серверных EPYC процессорах (опять же, в статье это упоминается).
Так что в AMD поступили вполне логично — кому надо ядер — держите, кому надо каналы памяти — используйте EPYC 7601
Тем не менее, в афинном шифровании (да и в остальных мне известных криптографических методах) взятие остатка от деления на отрицательное число не используется.
Генерация псевдо-случайных чисел оперирует либо битами, либо беззнаковыми числами. Операция деления и взятия остатка, в отличие от умножения, не дешевая, и на практике в генерации псевдо-случайных чисел не используется.
Ок, если не трудно, подскажите пожалуйста, в каком именно алгоритме шифрования используются отрицательные числа, по которым нужно брать остаток деления. Мне просто интересно, собственно, я таких не знаю и нагуглить сходу не получается.
Лучше рассказал бы, зачем вообще кому-то может понадобиться брать остаток от деления на отрицательное число. Ну, кроме как на собеседовании или позанудствовать, конечно…
Работа то возможна, но не думаю, что дизайн nginx-а предусматривает асинхронный процессинг конфига, блокировать на чтении файла весь воркер с оставшимися в очереди необработанными запросами никому не надо.
Другое дело обработчик запроса (а не установка переменной конфига), там проще сделать асинхронную обработку блокирующих операций, но все равно внедрять в nginx тяжелую логику не есть здравая идея — для этого есть лучшие инструменты.
А внедрить простую логику в обработчик запроса nginx-а иногда бывает очень полезно — убираются накладные расходы на проксирование, уменьшается задержка обработки запроса… Но для этого обычно и встроенного перла хватает )
Я вовсе не противник njs, но пока что он не предоставляет принципиальных преимуществ перед perl-модулем.
Я имел ввиду, собственно, js_set — управлять переменными конфига, используя блокирующие операции на файлах, базе или сети, нельзя.
js_content другое дело, если получится сделать блокирующие операции асинхронными, то это позволит писать уже вполне продвинутые обработчики запросов и сделать из nginx фактически полноценный app-сервер.
Думаю, полноценность js-модуля будет ровно такой же как и у перла — парсить строки, выставлять хидеры, регекспы, md5 какой-нибудь посчитать…
Работа с файлами, базами, сетью на уровне конфига не предполагается.
Кстати, у этого js-модуля есть общая память хотя бы для процесса (а ещё лучше для всех воркеров)? У перла глобальные переменные общие для процесса, а возможно и заработает какой-то модуль shared memory для разных процессов, не пробовал.
Почитал спеки на формат CD — проблема в том, что данные на поверхности не представлены непосредственно битами — они представлены питами (выжженые лазером участки) и промежутками между ними (лендами), причем и питы и ленды кодируют последовательности нулей, а вот переходы между ними (с пита на ленд и наоборот) — одну единичку. Кодирование 8 <-> 14 нужно, чтобы между каждой единичкой было от 2 до 10 нулей. И вот тут да, возникают проблемы синхронизации — длина пита или ленда может считываться по разному и это будет влиять на декодирование последующих бит, пока не встретится синхронизирующая последовательность… Технически, можно было бы построить модель и восстанавливать структуру питов и лендов на поверности и находить проблемные участки, но это не так просто, как посчитать кол-во нулей и единичек, да.
Алгоритм приведения известен? Эти 14 бит прочитать сто раз можно? Тогда можно восстановить корректные 14 сырых бит и из них получить корректные 8 бит данных.
Что-то я не совсем понял, почему при сотне рипов просто не посчитать для проблемных бит сколько раз какое значение встретится?
Если на 95 нулей 5 раз всплыла единица (при отключенной коррекции, разумеется), то результат очевиден. Ладно там на 60 нулей было 40 единиц, ещё можно посомневаться, но я не думаю, что такие случаи вообще были.
Кадры размером 8000×6000 пикселей при размере сенсора 6,4×4,8 мм — это 1250 пикселей на милиметр (625 пар линий на миллиметр). Где они возьмут объективы с хотя бы близкой разрешающей способностью — я не знаю.
А текст, безусловно, хорош! )
Наблюдая за развитием детей, можно вообще много разных параллелей провести с другими явлениями, в уже не детском возрасте.
Например, многие дети проходят стадию «вот это мое, делиться не хочу, наоборот, хочу ещё себе что-то взять». Это нормально, что с появлением концепции «вещь может быть твоей и поэтому тебе решать, что с ней делать» ребенок начинает ею активно пользоваться, и так же нормально, что потом новые концепции, типа «делиться своими игрушками выгодно, т.к. улучшает социальные связи» затмевают первую. Правда, немногие индивидуумы в своем развитии остаются на уровне «только мое, ..» или другой детской (неразвитой) мировоззренческой концепции.
В целом, уровень развития общества тоже проходит те же стадии, что ребенок, с другой скоростью, конечно. Примеры приводить лучше не буду )
Потому что люди ожидают от других такой же реакции, как от себя.
Сергей подобную критику воспринял бы логически, а не эмоционально, и принял бы к сведению, вместо обижаться, потому что ему важен результат, а не ЧСВ.
Так что все вполне жизненно, я бы сказал )
Конечно, Ваша ситуация вполне подошла бы, если бы размер чанка был отрицательным )
Хотя стрелка будет указывать на 20м (если отсчитывать -100 минут от 0:00), да…
В общем, и так и так можно нарваться на неприятности, поэтому случаи с отрицательными числами при взятии остатка лучше обрабатывать отдельной логикой, а не полагаться на реализацию в компиляторе или cpu.
Так что в AMD поступили вполне логично — кому надо ядер — держите, кому надо каналы памяти — используйте EPYC 7601
Генерация псевдо-случайных чисел оперирует либо битами, либо беззнаковыми числами. Операция деления и взятия остатка, в отличие от умножения, не дешевая, и на практике в генерации псевдо-случайных чисел не используется.
Другое дело обработчик запроса (а не установка переменной конфига), там проще сделать асинхронную обработку блокирующих операций, но все равно внедрять в nginx тяжелую логику не есть здравая идея — для этого есть лучшие инструменты.
А внедрить простую логику в обработчик запроса nginx-а иногда бывает очень полезно — убираются накладные расходы на проксирование, уменьшается задержка обработки запроса… Но для этого обычно и встроенного перла хватает )
Я вовсе не противник njs, но пока что он не предоставляет принципиальных преимуществ перед perl-модулем.
js_content другое дело, если получится сделать блокирующие операции асинхронными, то это позволит писать уже вполне продвинутые обработчики запросов и сделать из nginx фактически полноценный app-сервер.
Работа с файлами, базами, сетью на уровне конфига не предполагается.
Кстати, у этого js-модуля есть общая память хотя бы для процесса (а ещё лучше для всех воркеров)? У перла глобальные переменные общие для процесса, а возможно и заработает какой-то модуль shared memory для разных процессов, не пробовал.
Если на 95 нулей 5 раз всплыла единица (при отключенной коррекции, разумеется), то результат очевиден. Ладно там на 60 нулей было 40 единиц, ещё можно посомневаться, но я не думаю, что такие случаи вообще были.