Ну, OUTER в принципе избыточно, т.к. LEFT подразумевает OUTER. Но ваш вопрос вполне актуален для случаев, когда нам надо написать LEFT MERGE JOIN или INNER HASH JOIN, например.
Лично мне вариант с коридорами неудобен тем, что от замены одного оператора может поползти верстка большого куска запроса (в пределе - запроса целиком). Заменил один LEFT на INNER - и либо нарушил аккуратное форматирование ("ад перфекциониста"), либо получил diff на 200 строк.
Не оспаривая написанного вами, всё же отмечу, что человек, способный стройно сформулировать мысль в режиме реального времени, без тщательного рефакторинга, - и в написании кода может оказаться более продуктивным, т.к. он будет получаться логичным с первого раза, без многократных переделок.
Как вариант - делать выгрузки такого же размера примерно каждый день, чтобы а) создать впечатление, что это нормальный рабочий процесс, а не разовая аномалия, б) затереть следы утекшей выгрузки, в) убедиться, что не привлёк внимания СБ. А базу продавать через год, когда следов уже не найти. В идеале - после списания АРМ2 с регламентным уничтожением HDD, но это можно и не дождаться.
И ещё, чтобы тепловая карта показывала объективный результат, величина ячеек должна быть одинаковой на всей площади. Иначе даже абсолютно равномерное распределение точек будет визуализировано как имеющее бОльшую плотность в той части, где ячейки крупнее. Поэтому проекцию стоит выбирать равновеликую.
Как зарядка для ума - неплохое упражнение. С практической точки зрения - вариант не очень универсальный.
Думаю, проблемы с подсчётом расстояний между между точками с использованием geography были вызваны тем, что вы считали расстояния от каждой точки до каждой, что, очевидно, слишком ресурсозатратно. Правильнее было бы спроецировать географические координаты в целевую СК (в ту, в которой будет происходить отображение), а в ней уже кластеризовать по квадратной сетке нужного размера. В вашем же случае сделать сетку квадратной, а не прямоугольной или трапецевидной - задача нетривиальная.
Но мне непонятно, что мешает извлечь коммит 5-летней давности, провести проверку, зафиксировать ошибки, извлечь последний коммит и провести повторную проверку.
Статья называется "Представляем Q# Formatter", а по факту её содержимое больше напоминает release notes очередной версии продукта, который уже хорошо знаком читателям.
Поэтому в этот раз я проделал довольно много дополнительной работы, чтобы исключить из отчёта ранее найденные ошибки.
Как-то это плохо стыкуется с утверждениями из статей про внедрение PVS Studio на больших проектах, о том, что можно запустить анализ, пометить всё ошибки как "базовый уровень", и в последующих анализах видеть только новые ошибки. Я думал, это делается в несколько кликов.
Так это просто для иллюстрации того, сколько раз выполняется сравнение. Когда коллекция большая, а сравнение медленное, могут возникнуть проблемы, там где их не ждёшь. А захват тут не при чем.
Кроме того, это никак р-не противоречит моему доводы о том, что "простая мнемоника никогда не делайте multiple enumeration по enumerable" снимает не все проблемы.
Речь про беглый анализ кода, при котором легко ошибочно заключить что x.Last(predicate) и x.Where(predicate).Last() эквивалентны. И то, что несколько человек на этом попались, опровергает тезис "нельзя".
Увы не полностью. С единственным вызовом Last() можно ожидать, что сравнение будет одно, т.к. обход будет идти с конца, но легко упустить, что после Where мы имеем дело не с массивом (как вы уже написали ниже), и обход будет полным. Так что пусть пример несколько синтетический, но полезная информация в нём определённо есть, чтобы не попадаться на таких ловушках.
цинк-65, чья радиоактивность будет гораздо выше на начальном этапе и, соответственно, спадет быстрее. Но этот изотоп составляет лишь примерно половину природного цинка, поэтому для военного применения его пришлось бы обогащать.
Вряд ли его стали бы обогащать, если бы решили использовать в качестве оружия. Просто смирились бы с КПД 1/2 от теоретического (если конечно можно назвать такое "действие" "полезным")
Так ведь есть исследования, что будучи изолированным от внешней среды (например, в пещере), организм имеет тенденцию переходить на удлинённый цикл сна/бодрствования. Там, конечно, много факторов оказывают влияние, но в межзвёздных странствиях нет объективных предпосылок против установления размера цикла в 100 Кс (27:46 на наши деньги). Жаль в СИ не предусмотрено стандартной приставки для 100 000
Проблемы с календарями во многом вызваны стремлением сохранить привязку к природным циклам - т.е. приравнять год к периоду обращения Земли вокруг Солнца, а сутки - к периоду оборота вокруг оси. В, условно, стандартном галактическом времени это не имело бы смысла, там логичнее было бы измерять время кило-, мега-, гигасекундами. Например, в течение одной Мс рабочему предоставляется 300Кс выходных, кроме того ему полагается оплачиваемый отпуск в 1Мс один раз в 20Мс... Операции с датами станут тривиальными, а вот перевод в архаичные земные единицы останется всё таким же заморочным.
(Удивляет, что во всякой космической фантастике продолжают считать время земными единицами; впрочем, я тут не очень начитан)
My wife says: if you keep being so pedantic you'll have less and less friends!
I say: no way! Because I'll be having fewer and fewer of them.
Вот тут я что-то сомневаюсь. It это subject, me - object. Вот и получается it's me. Аналогично - it's him, it's her и т.п., а не it's he, it's she.
Ну, OUTER в принципе избыточно, т.к. LEFT подразумевает OUTER. Но ваш вопрос вполне актуален для случаев, когда нам надо написать LEFT MERGE JOIN или INNER HASH JOIN, например.
Лично мне вариант с коридорами неудобен тем, что от замены одного оператора может поползти верстка большого куска запроса (в пределе - запроса целиком). Заменил один LEFT на INNER - и либо нарушил аккуратное форматирование ("ад перфекциониста"), либо получил diff на 200 строк.
Не оспаривая написанного вами, всё же отмечу, что человек, способный стройно сформулировать мысль в режиме реального времени, без тщательного рефакторинга, - и в написании кода может оказаться более продуктивным, т.к. он будет получаться логичным с первого раза, без многократных переделок.
Как вариант - делать выгрузки такого же размера примерно каждый день, чтобы а) создать впечатление, что это нормальный рабочий процесс, а не разовая аномалия, б) затереть следы утекшей выгрузки, в) убедиться, что не привлёк внимания СБ. А базу продавать через год, когда следов уже не найти. В идеале - после списания АРМ2 с регламентным уничтожением HDD, но это можно и не дождаться.
И ещё, чтобы тепловая карта показывала объективный результат, величина ячеек должна быть одинаковой на всей площади. Иначе даже абсолютно равномерное распределение точек будет визуализировано как имеющее бОльшую плотность в той части, где ячейки крупнее. Поэтому проекцию стоит выбирать равновеликую.
Как зарядка для ума - неплохое упражнение. С практической точки зрения - вариант не очень универсальный.
Думаю, проблемы с подсчётом расстояний между между точками с использованием geography были вызваны тем, что вы считали расстояния от каждой точки до каждой, что, очевидно, слишком ресурсозатратно. Правильнее было бы спроецировать географические координаты в целевую СК (в ту, в которой будет происходить отображение), а в ней уже кластеризовать по квадратной сетке нужного размера. В вашем же случае сделать сетку квадратной, а не прямоугольной или трапецевидной - задача нетривиальная.
Не может, т.к. в английском idiot ударение на первый слог, а настолько недослышать - это надо очень постараться.
Мне стоило бы обновить комменты перед отправкой...
Но мне непонятно, что мешает извлечь коммит 5-летней давности, провести проверку, зафиксировать ошибки, извлечь последний коммит и провести повторную проверку.
Статья называется "Представляем Q# Formatter", а по факту её содержимое больше напоминает release notes очередной версии продукта, который уже хорошо знаком читателям.
Как-то это плохо стыкуется с утверждениями из статей про внедрение PVS Studio на больших проектах, о том, что можно запустить анализ, пометить всё ошибки как "базовый уровень", и в последующих анализах видеть только новые ошибки. Я думал, это делается в несколько кликов.
А мне персонаж Сутеева представлялся
Собственно, данная статья и работает в пользу приведения ожиданий людей к реальности.
Так это просто для иллюстрации того, сколько раз выполняется сравнение. Когда коллекция большая, а сравнение медленное, могут возникнуть проблемы, там где их не ждёшь. А захват тут не при чем.
Кроме того, это никак р-не противоречит моему доводы о том, что "простая мнемоника никогда не делайте multiple enumeration по enumerable" снимает не все проблемы.
Речь про беглый анализ кода, при котором легко ошибочно заключить что x.Last(predicate) и x.Where(predicate).Last() эквивалентны. И то, что несколько человек на этом попались, опровергает тезис "нельзя".
Увы не полностью. С единственным вызовом Last() можно ожидать, что сравнение будет одно, т.к. обход будет идти с конца, но легко упустить, что после Where мы имеем дело не с массивом (как вы уже написали ниже), и обход будет полным. Так что пусть пример несколько синтетический, но полезная информация в нём определённо есть, чтобы не попадаться на таких ловушках.
Вряд ли его стали бы обогащать, если бы решили использовать в качестве оружия. Просто смирились бы с КПД 1/2 от теоретического (если конечно можно назвать такое "действие" "полезным")
Так ведь есть исследования, что будучи изолированным от внешней среды (например, в пещере), организм имеет тенденцию переходить на удлинённый цикл сна/бодрствования. Там, конечно, много факторов оказывают влияние, но в межзвёздных странствиях нет объективных предпосылок против установления размера цикла в 100 Кс (27:46 на наши деньги). Жаль в СИ не предусмотрено стандартной приставки для 100 000
Проблемы с календарями во многом вызваны стремлением сохранить привязку к природным циклам - т.е. приравнять год к периоду обращения Земли вокруг Солнца, а сутки - к периоду оборота вокруг оси. В, условно, стандартном галактическом времени это не имело бы смысла, там логичнее было бы измерять время кило-, мега-, гигасекундами. Например, в течение одной Мс рабочему предоставляется 300Кс выходных, кроме того ему полагается оплачиваемый отпуск в 1Мс один раз в 20Мс... Операции с датами станут тривиальными, а вот перевод в архаичные земные единицы останется всё таким же заморочным.
(Удивляет, что во всякой космической фантастике продолжают считать время земными единицами; впрочем, я тут не очень начитан)