"Что может быть разрушено истиной, не заслуживает спасения" (c)
Что касается пропаганды, то, конечно, бывают ложные срабатывания, неумышленные следования известным подходам, но мозг-то натренирован распознавать типичные методы и идеи даже через заход издалека. Обрывок новостей на ТВ вот недавно случайно услышал: говорили, что РФ вышла на первое место в Европе по экономике: в частности, по отношению ВВП к ППС. Но это ж как заявлять о победе в автомобильной гонке на основе суммарного количества оборотов двигателя. Умышленно или нет, но методы работы с информацией, выводы, полученные из недостаточно полной и объективной информации, и выгодоприобретатели (в случае успеха) показались в какой-то мере похожими. В статье автор расставил предупреждения о неточностях и допущениях, в комментах вроде адекватно реагирует на критику, но все равно подозрительно.
Кстати, вот в комменте чуть выше из всей статьи как раз идею разглядели и развили, мол, везде плохо, да еще и хуже, чем у нас, нечего и суетиться, сиди дома - ну прям классический прием, разве что линчевание негров заменили на протесты. Тот посыл вам по душе? Улыбнулись и мимо прошли? :)
email - очевидный пример Web 3.0 (децентрализация - DNS, SMTP и локальное хранение данных - POP3, IMAP).
Что-то не так, а то и фидонет тогда придется назвать web 3.0: там тоже не было централизации и данные хранились локально. Каким образом DNS и SMTP - децентрализация email? DNS - маппинг домена на айпишники, SMTP - вовсе протокол one-to-one общения для отправки письма. Чтобы отправить письмо кому-то, мне и так надо обратиться его почтовому серверу. Имхо скорее наоборот, при отсутствии DNS письма бы отправлялись по независимым IP-адресам, а DNS-сервер централизует эту систему. POP3 и IMAP подразумевают, что почтовый сервер поднят на какой-то другой машине, что возвращает все максимум к web 2.0; для децентрализации либо почтовый сервер должен быть поднят непосредственно у вас на мобилке/компе и быть доступен 24/7, что недостижимо и чревато утратой данных, либо, как это обычно предполагается, письмо должно доставляться в какой-то общий ресурс вроде блокчейна, распределенный по устройствам других пользователей. Блокчейн вполне может содержать и шифрованные данные, а не только открытые - встречал уже "email будущего" на таком подходе. Кстати, если у каждого есть только свои собственные уникальные данные, хранящиеся только на устройстве и принципиально недоступные извне, то это вообще на web-то не особо похоже: просто оффлайн-хранилище с возможностью ручной p2p-отправки в другое хранилище.
<zanuda_mode>Ммм да нет в вашем случае парадокса, это всего лишь каламбур: смешались термины, обозначающие перманентное кровное родство и... назовем это динамической семейной ролью. Даже в более запутанных и непривычных кровных связях это вопрос терминологии, а не логики.</zanuda_mode> Хотя да, это забавно :)
Я бы тогда посоветовал проделать еще две вещи: во-первых, объяснить, что делает команда, а то иначе это заклинание :) в идеале еще и дать команду, отменяющую эффект первой; во-вторых, хотя бы в двух словах описать информацию по ссылкам. Знаете, как обидно бывает, когда ищешь решение какой-нибудь нетривиальной проблемы, находишь на старых форумах, вероятно, единственную во всем интернете ветку с ее обсуждением, которая заканчивается словами "вот по ссылке решение, мне помогло", а ссылка уже нерабочая? Или что-то на скриншотах, которые тоже уже не грузятся.
Во втором варианте выяснили, что избавление от "%" дает прирост, но в последующих сделано по-старому. Выкинута распечатка собственно чисел. Из оригинальной статьи не взята куча идей - например, разворачивание цикла в 15 элементов в одну общую склейку строки. В Java есть аналоги reserve() для строк/контейнеров, чтобы избегать реаллокации? Частый вызов функций для числодробилок может оказаться заметно затратным - возможно, стоит сравнить функциональный стиль с императивным. Аллокации в памяти внутри функций тоже прилично съедают, даже если компилитор соптимизировал переменные внутри циклов.
Влезу и на всякий случай прорекламирую еще раз связку Singlefile + Importer - пока лучшее, что пробовал. Первое есть в виде плагина для браузера - скачает всю страницу одним файлом, даже картинки вошьет через data:... в тело документа. Затем этот файл перекладываю в обсидиан и запускаю его плагин Importer, который html умеет конвертить в md, причем сохраняя вшитые картинки. Так у меня получается и md статья, и исходный html-вариант, что полезно, т.к. md-разметка не всегда хорошо читаемая получается. Может быть, вам тоже так больше понравится.
UPD: В хром версии MarkDownload - Markdown Web Clipper нет настроек скачивания картинок?
Поддерживаю, мы же не медициной занимаемся, их термины не должны нас путать. Но слово "пациент" уж слишком намекает на медицину, лучше что-то более нейтральное. У нас же паттерны и объекты? Возьмем, например, меридиан - начало отчета, а тут это тоже как бы отправная точка в паттерне. Null все так же переведем как "нулевой" - итого предлагаю "нулевой меридиан", хороший запоминающийся термин. Если не нравится меридиан, ну можно взять, например, стакан - в него ж можно объекты складывать. Такой термин даже на финансовых биржах есть для совокупности позиций - похоже на хранилище, как и тут. А null переведем как "пустой" - итого будет "пустой стакан", тоже неплохо.
Реализация классов шаблоны проектирования также производится с использованием общего абстрактного класса проектирования Принципы объектно-ориентированного программирования, реализованного по паттерну 4.7. Нулевой пациент.
А что сейчас для веб-клипинга используете? Тоже ищу решение получше. Сейчас пробую связку из браузерного плагина для SingleFile, который подсмотрел среди экспортеров в Archivebox, и Obsidian-плагинов HTML Reader и Importer. Действий, конечно, получается больше, чем хотелось бы - "сохранить страницу", "перенести в папку", опционально "конвертнуть html -> md", зато надежно. Еще, если руки дойдут, попробую накрутить хуки на Archivebox и включить его экспорт в синхронизацию; мб даже закидывание на скачивание сделаю через watch папки обсидиана как альтернативу браузерному плагину
Вообще интересная тема, редко с таким сталкиваешься - вот нагуглилась работа, где авторы утверждают, что разработали алгоритм внешней сортировки с O(n log n) по времени, константной RAM-памятью и, похоже, вообще без дополнительного места на диске: надо будет потом попристальнее изучить.
Я тоже засомневался, поэтому полез проверить: можно O(n log n) с константной памятью, просто придется пожертвовать устойчивостью и, возможно, лучшим временем, но, кажется, здесь ни первое не пригодится, ни на втором все равно не выиграть.
Ммм а почему вы игнорируете последнее решение из статьи с двумя указателями? В нем данные предварительно отсортированы по пользователю и странице, поэтому для устранения дубликатов в ответе достаточно при обходе каждого из двух списков пропускать идущие подряд одинаковые записи, а при перекрестном поиске не нужно искать по всему второму файлу, а достаточно просто двигать второй указатель, пока не найдется элемент с userID равным искомому или больше. Сложность получается O(n log n) на предварительную сортировку и всего лишь O(n) на обработку, т.к. каждый из двух списков обходится однократно; итоговая будет O(n log n + n) = O(n log n) при константной памяти.
Какие IO операции? Какие другие машины? Опять что-то выдумываете. Это может быть обход генератора или чтение канала данных в том же процессе, просто другим модулем. Вы сами придумали это ограничение, что список должен быть передан полностью законченным, и теперь пытаетесь всех убедить, что автор сам себя не понял и вообще профнепригоден. С точки зрения ABI задача вообще не описана, поэтому отвечать на рассуждения о компиляторах и теории типов не стану. Мне кажется вполне реальной ситуация, когда я реализовал этот механизм, собирающий полный список, а в памяти не помещается даже готовый список-ответ, поэтому пришлось, например, потратиться на вертикальное масштабирование. Затем приходит заказчик этой ерунды и спрашивает, почему так долго и дорого, и нельзя ли по частям, мол, ему так было бы проще. А единственным оправданием будет "вы же сказали список, а я это понял так".
Хочу пару цитат из статьи привести:
В реальности инженеры постоянно сталкиваются с неоднозначностью, и корень большинства программных проблем можно найти в плохо определённых требованиях.
Наиболее грамотные кандидаты, прежде чем переходить к написанию кода, должны задавать уточняющие вопросы. Я рассчитываю увидеть в соискателях проявление рассудительности, так как в описанных условиях задачи присутствует двусмысленность.
С чего вы взяли, что есть какая-то запись на диск? Механизм может частью пайпа и по мере нахождения новых пользователей их сразу куда-то дальше переправлять, не дожидаясь конца обработки.
Что бы сделать например обобщённую функцию для sqlx нужно описать портянку из параметров шаблонов [...] Но ведь в Go например есть GORM, который без всяких шаблонов делает это.
И он это делает с помощью рефлексии в рантайме, когда шаблоны разворачиваются в куда более простой и прямолинейный код при компиляции. Разница в производительности просто гигантская. Впрочем, гошные дженерики реализованы не так, как многие надеялись: без полной мономорфизации, чтобы сохранить быструю компиляцию, так что в рантайме все же довольно много всего происходит.
А в реальных проектах с кучей библиотек будут огромные строки указания параметров шаблона.
Дженерики в go не полные по Тьюрингу, так что творить на них какую-то чудовищую магию, как это возможно, например, в плюсах, попросту не получится. Их введение прошло с очень длительными и обстоятельными обсуждениями, главный мотив в которых был "не переусложнить язык". На мой взгляд, получилось неплохо: все дженерики, которые я писал или видел, были очень простыми и всего лишь способствовали универсальности функций или контейнеров при сохранении типизации, так что область их применения невелика; никакого SFINAE тут нет, к счастью. К тому же, экосистема уже достаточно крупная и устоявшаяся, чтобы появление дженериков не перевернуло все с ног на голову. Собственно, такого и не происходит, хотя дженерикам уже полтора года.
Как же обходились без шаблонов в Go 13 лет?
Иногда с недовольством недостаточной выразительностью языка и необходимостью вручную писать одни и те же вещи из раза в раз вроде общих алгоритмов для массивов, которые теперь появились в пакете slices; кодогенерация как предлагаемая альтернатива не особо помогала. Собственные контейнеры всегда приходилось затачивать под конкретные типы, их толком не вынести было в библиотеки. Часто для обобщения приходилось уничтожать информацию о типе через пустой интерфейс, а потом ее восстанавливать через попытки приведения: уж лучше дженерики.
Раз теперь код в Go будет выглядеть как в Rust, то зачем продолжать использовать Go?
А зачем нужен был раст, если в нем есть такие же шаблоны, как в уже существующих плюсах? Языки все же отличаются не только синтаксисом, да и обобщение уж слишком натянутое. Go все так же будет иметь намного более низкий порог входа и простоту поддержки легаси, все так же будет управлять сбором мусора, все так же будет хорош легковесными горутинами и т.д.
Интерпретация ответов тоже важна: исследователь все-таки не машина, которая просто проверяет галочки в тесте, на составлении опросника умственная работа не заканчивается. Вопрос "выберите лишний предмет из списка [x, y, z, &]" без критерия объединения имеет смысл, т.к. оставляет подопытному возможность придумать несколько собственных вариантов с разными критериями и таки лучше продемонстрировать способности, хотя некоторым и будет сложнее с таким справиться, нежели с прямолинейным вопросом. Не все так просто. А конкретно описанный случай выглядит некорректно проведенным, т.к. подопытные явно зафиксировались на формулировке "лишний", а исследователь будто этого не заметил и продолжал настаивать, в итоге из-за этого тест "найди что-то общее ровно для 3 из 4 объектов" был воспринят как вызов "докажи, что лишнего нет и исследователь неправ, найдя применимость всех 4 объектов и связи между ними", с которым подопытные в итоге блестяще справились.
tl;dr «Низкая производительность» — это когда выполняется мало задач. Проблемы - это плохо. Что с этим делать - пока неизвестно, надо искать. Надо сделать так, чтобы было хорошо.
Проблема «Низкая ПИТ» — это, когда делается мало задач в интеллектуальной сфере в заданные сроки имеющимися ресурсами. Когда делается мало задач, то получаются скудные результаты Отсюда, проблема «Низкая ПИТ» — это, когда выполняется мало интеллектуальных задач. сделано маленькое количество работы в интеллектуальной сфере – это значит выполнено мало интеллектуальных задач Проблема «Низкая ПИТ» имеет негативный (отрицательный) характер «Низкая ПИТ» вызывает у нас недовольство (дискомфорт). Мы пока не знаем, что нужно сделать, чтобы преодолеть проблему «Низкая ПИТ». у нас есть лишь потребность в преодолении этой проблемы отсутствует понимание, на что воздействовать Пока мы не знаем, на что воздействовать. нужно искать причины появления проблемы «Низкой ПИТ» Надо так настроить её [системы] работу, чтобы все интеллектуальные задачи выполнялись своевременно, ритмично и воспроизводимо. проблема будет считаться преодолённой, если все интеллектуальные задачи в организации начнут выполняться воспроизводимо
Умножение двух чисел x и y имеет линейную сложность, так как требуется выполнить x умножений
Что, простите? Даже если вы имели в виду "умножение на N = N сложений", то это все равно далеко от реальности, иначе перемножение/деление больших чисел занимало бы вечность. Деление, кстати, более сложная для процессора операция, чем умножение.
У нас есть запись вида x = y % z , которая будет эквивалентна x = x - y * (x / y)
А у вас спина белая переменные перепутались.
Обратите внимание, что на практике сложность операции взятия остатка может быть оптимизирована в зависимости от аппаратной архитектуры и используемого компилятора
Так может быть, расскажете, как на практике, а не как у вас в голове на основе мат. модели уровня 5 класса? Ведь задан контекст: браузерный JS, а иначе в этой информации не просто нет смысла, а она еще и вредит, т.к. создает ложные представления.
Если злоумышленник уже захватил машину разработчика, как поможет подпись коммитов, отправленных с этой же машины? Или с любой другой, куда утянули сертификат. Сертификат уже скомпрометирован и точно так же надо сверять историю действий. Имхо единственный сценарий из ваших трех, который закрывает этот механизм, это третий: когда злоумышленник все так же находится уже внутри периметра, все так же смог получить учетку гитлаба, но не смог получить доступ к машине с сертификатом.
"Что может быть разрушено истиной, не заслуживает спасения" (c)
Что касается пропаганды, то, конечно, бывают ложные срабатывания, неумышленные следования известным подходам, но мозг-то натренирован распознавать типичные методы и идеи даже через заход издалека. Обрывок новостей на ТВ вот недавно случайно услышал: говорили, что РФ вышла на первое место в Европе по экономике: в частности, по отношению ВВП к ППС. Но это ж как заявлять о победе в автомобильной гонке на основе суммарного количества оборотов двигателя. Умышленно или нет, но методы работы с информацией, выводы, полученные из недостаточно полной и объективной информации, и выгодоприобретатели (в случае успеха) показались в какой-то мере похожими. В статье автор расставил предупреждения о неточностях и допущениях, в комментах вроде адекватно реагирует на критику, но все равно подозрительно.
Кстати, вот в комменте чуть выше из всей статьи как раз идею разглядели и развили, мол, везде плохо, да еще и хуже, чем у нас, нечего и суетиться, сиди дома - ну прям классический прием, разве что линчевание негров заменили на протесты. Тот посыл вам по душе? Улыбнулись и мимо прошли? :)
Что-то не так, а то и фидонет тогда придется назвать web 3.0: там тоже не было централизации и данные хранились локально.
Каким образом DNS и SMTP - децентрализация email? DNS - маппинг домена на айпишники, SMTP - вовсе протокол one-to-one общения для отправки письма. Чтобы отправить письмо кому-то, мне и так надо обратиться его почтовому серверу. Имхо скорее наоборот, при отсутствии DNS письма бы отправлялись по независимым IP-адресам, а DNS-сервер централизует эту систему.
POP3 и IMAP подразумевают, что почтовый сервер поднят на какой-то другой машине, что возвращает все максимум к web 2.0; для децентрализации либо почтовый сервер должен быть поднят непосредственно у вас на мобилке/компе и быть доступен 24/7, что недостижимо и чревато утратой данных, либо, как это обычно предполагается, письмо должно доставляться в какой-то общий ресурс вроде блокчейна, распределенный по устройствам других пользователей. Блокчейн вполне может содержать и шифрованные данные, а не только открытые - встречал уже "email будущего" на таком подходе.
Кстати, если у каждого есть только свои собственные уникальные данные, хранящиеся только на устройстве и принципиально недоступные извне, то это вообще на web-то не особо похоже: просто оффлайн-хранилище с возможностью ручной p2p-отправки в другое хранилище.
<zanuda_mode>Ммм да нет в вашем случае парадокса, это всего лишь каламбур: смешались термины, обозначающие перманентное кровное родство и... назовем это динамической семейной ролью. Даже в более запутанных и непривычных кровных связях это вопрос терминологии, а не логики.</zanuda_mode>
Хотя да, это забавно :)
Я бы тогда посоветовал проделать еще две вещи: во-первых, объяснить, что делает команда, а то иначе это заклинание :) в идеале еще и дать команду, отменяющую эффект первой; во-вторых, хотя бы в двух словах описать информацию по ссылкам. Знаете, как обидно бывает, когда ищешь решение какой-нибудь нетривиальной проблемы, находишь на старых форумах, вероятно, единственную во всем интернете ветку с ее обсуждением, которая заканчивается словами "вот по ссылке решение, мне помогло", а ссылка уже нерабочая? Или что-то на скриншотах, которые тоже уже не грузятся.
Во втором варианте выяснили, что избавление от "%" дает прирост, но в последующих сделано по-старому. Выкинута распечатка собственно чисел. Из оригинальной статьи не взята куча идей - например, разворачивание цикла в 15 элементов в одну общую склейку строки. В Java есть аналоги reserve() для строк/контейнеров, чтобы избегать реаллокации? Частый вызов функций для числодробилок может оказаться заметно затратным - возможно, стоит сравнить функциональный стиль с императивным. Аллокации в памяти внутри функций тоже прилично съедают, даже если компилитор соптимизировал переменные внутри циклов.
Влезу и на всякий случай прорекламирую еще раз связку Singlefile + Importer - пока лучшее, что пробовал. Первое есть в виде плагина для браузера - скачает всю страницу одним файлом, даже картинки вошьет через
data:...в тело документа. Затем этот файл перекладываю в обсидиан и запускаю его плагин Importer, который html умеет конвертить в md, причем сохраняя вшитые картинки. Так у меня получается и md статья, и исходный html-вариант, что полезно, т.к. md-разметка не всегда хорошо читаемая получается. Может быть, вам тоже так больше понравится.UPD: В хром версии MarkDownload - Markdown Web Clipper нет настроек скачивания картинок?
*thinking_face* Видимо, надо было добавить тег <sarcasm>
Поддерживаю, мы же не медициной занимаемся, их термины не должны нас путать. Но слово "пациент" уж слишком намекает на медицину, лучше что-то более нейтральное. У нас же паттерны и объекты? Возьмем, например, меридиан - начало отчета, а тут это тоже как бы отправная точка в паттерне. Null все так же переведем как "нулевой" - итого предлагаю "нулевой меридиан", хороший запоминающийся термин. Если не нравится меридиан, ну можно взять, например, стакан - в него ж можно объекты складывать. Такой термин даже на финансовых биржах есть для совокупности позиций - похоже на хранилище, как и тут. А null переведем как "пустой" - итого будет "пустой стакан", тоже неплохо.
Словы вроде русски, но смысл идею ускользать.
А что сейчас для веб-клипинга используете? Тоже ищу решение получше. Сейчас пробую связку из браузерного плагина для SingleFile, который подсмотрел среди экспортеров в Archivebox, и Obsidian-плагинов HTML Reader и Importer. Действий, конечно, получается больше, чем хотелось бы - "сохранить страницу", "перенести в папку", опционально "конвертнуть html -> md", зато надежно. Еще, если руки дойдут, попробую накрутить хуки на Archivebox и включить его экспорт в синхронизацию; мб даже закидывание на скачивание сделаю через watch папки обсидиана как альтернативу браузерному плагину
Вообще интересная тема, редко с таким сталкиваешься - вот нагуглилась работа, где авторы утверждают, что разработали алгоритм внешней сортировки с O(n log n) по времени, константной RAM-памятью и, похоже, вообще без дополнительного места на диске: надо будет потом попристальнее изучить.
Я тоже засомневался, поэтому полез проверить: можно O(n log n) с константной памятью, просто придется пожертвовать устойчивостью и, возможно, лучшим временем, но, кажется, здесь ни первое не пригодится, ни на втором все равно не выиграть.
Ммм а почему вы игнорируете последнее решение из статьи с двумя указателями? В нем данные предварительно отсортированы по пользователю и странице, поэтому для устранения дубликатов в ответе достаточно при обходе каждого из двух списков пропускать идущие подряд одинаковые записи, а при перекрестном поиске не нужно искать по всему второму файлу, а достаточно просто двигать второй указатель, пока не найдется элемент с userID равным искомому или больше. Сложность получается O(n log n) на предварительную сортировку и всего лишь O(n) на обработку, т.к. каждый из двух списков обходится однократно; итоговая будет O(n log n + n) = O(n log n) при константной памяти.
Какие IO операции? Какие другие машины? Опять что-то выдумываете. Это может быть обход генератора или чтение канала данных в том же процессе, просто другим модулем. Вы сами придумали это ограничение, что список должен быть передан полностью законченным, и теперь пытаетесь всех убедить, что автор сам себя не понял и вообще профнепригоден.
С точки зрения ABI задача вообще не описана, поэтому отвечать на рассуждения о компиляторах и теории типов не стану.
Мне кажется вполне реальной ситуация, когда я реализовал этот механизм, собирающий полный список, а в памяти не помещается даже готовый список-ответ, поэтому пришлось, например, потратиться на вертикальное масштабирование. Затем приходит заказчик этой ерунды и спрашивает, почему так долго и дорого, и нельзя ли по частям, мол, ему так было бы проще. А единственным оправданием будет "вы же сказали список, а я это понял так".
Хочу пару цитат из статьи привести:
С чего вы взяли, что есть какая-то запись на диск? Механизм может частью пайпа и по мере нахождения новых пользователей их сразу куда-то дальше переправлять, не дожидаясь конца обработки.
Не разделяю опасения.
Читаемость можно ухудшить множеством способов. Как вам, например, описание цепочки функций высшего порядка?
func MyfuncA(param1, param2 string) (func (param3 string, param4 func (param5 *interface{}, param6 int64) func () int64) func (param5 *interface{}) int64, error)И он это делает с помощью рефлексии в рантайме, когда шаблоны разворачиваются в куда более простой и прямолинейный код при компиляции. Разница в производительности просто гигантская. Впрочем, гошные дженерики реализованы не так, как многие надеялись: без полной мономорфизации, чтобы сохранить быструю компиляцию, так что в рантайме все же довольно много всего происходит.
Дженерики в go не полные по Тьюрингу, так что творить на них какую-то чудовищую магию, как это возможно, например, в плюсах, попросту не получится. Их введение прошло с очень длительными и обстоятельными обсуждениями, главный мотив в которых был "не переусложнить язык". На мой взгляд, получилось неплохо: все дженерики, которые я писал или видел, были очень простыми и всего лишь способствовали универсальности функций или контейнеров при сохранении типизации, так что область их применения невелика; никакого SFINAE тут нет, к счастью. К тому же, экосистема уже достаточно крупная и устоявшаяся, чтобы появление дженериков не перевернуло все с ног на голову. Собственно, такого и не происходит, хотя дженерикам уже полтора года.
Иногда с недовольством недостаточной выразительностью языка и необходимостью вручную писать одни и те же вещи из раза в раз вроде общих алгоритмов для массивов, которые теперь появились в пакете slices; кодогенерация как предлагаемая альтернатива не особо помогала. Собственные контейнеры всегда приходилось затачивать под конкретные типы, их толком не вынести было в библиотеки. Часто для обобщения приходилось уничтожать информацию о типе через пустой интерфейс, а потом ее восстанавливать через попытки приведения: уж лучше дженерики.
А зачем нужен был раст, если в нем есть такие же шаблоны, как в уже существующих плюсах? Языки все же отличаются не только синтаксисом, да и обобщение уж слишком натянутое. Go все так же будет иметь намного более низкий порог входа и простоту поддержки легаси, все так же будет управлять сбором мусора, все так же будет хорош легковесными горутинами и т.д.
Интерпретация ответов тоже важна: исследователь все-таки не машина, которая просто проверяет галочки в тесте, на составлении опросника умственная работа не заканчивается. Вопрос "выберите лишний предмет из списка [x, y, z, &]" без критерия объединения имеет смысл, т.к. оставляет подопытному возможность придумать несколько собственных вариантов с разными критериями и таки лучше продемонстрировать способности, хотя некоторым и будет сложнее с таким справиться, нежели с прямолинейным вопросом. Не все так просто.
А конкретно описанный случай выглядит некорректно проведенным, т.к. подопытные явно зафиксировались на формулировке "лишний", а исследователь будто этого не заметил и продолжал настаивать, в итоге из-за этого тест "найди что-то общее ровно для 3 из 4 объектов" был воспринят как вызов "докажи, что лишнего нет и исследователь неправ, найдя применимость всех 4 объектов и связи между ними", с которым подопытные в итоге блестяще справились.
tl;dr «Низкая производительность» — это когда выполняется мало задач. Проблемы - это плохо. Что с этим делать - пока неизвестно, надо искать. Надо сделать так, чтобы было хорошо.
Что, простите? Даже если вы имели в виду "умножение на N = N сложений", то это все равно далеко от реальности, иначе перемножение/деление больших чисел занимало бы вечность. Деление, кстати, более сложная для процессора операция, чем умножение.
А у вас
спина белаяпеременные перепутались.Так может быть, расскажете, как на практике, а не как у вас в голове на основе мат. модели уровня 5 класса? Ведь задан контекст: браузерный JS, а иначе в этой информации не просто нет смысла, а она еще и вредит, т.к. создает ложные представления.
Если злоумышленник уже захватил машину разработчика, как поможет подпись коммитов, отправленных с этой же машины? Или с любой другой, куда утянули сертификат. Сертификат уже скомпрометирован и точно так же надо сверять историю действий. Имхо единственный сценарий из ваших трех, который закрывает этот механизм, это третий: когда злоумышленник все так же находится уже внутри периметра, все так же смог получить учетку гитлаба, но не смог получить доступ к машине с сертификатом.