All streams
Search
Write a publication
Pull to refresh
-1
0

User

Send message

Неплохой способ решения проблемы глобального потепления.

Можете какой срок на подачу иска к банку после пропажи денег? Не могу понять нужно ли это искать в ГК или в 161-ФЗ. Жалобу подавал в течение недели и счет блокировал, но банк отказал во всем.

Есть ли у вас скриптах возможность настроить фильтрацию по городу?

В Азиатском кино будет альтернативное решение

В том, что вы нагуглили, есть ссылка на стандарт - вроде не так плохо.

В целом, лучше всего помогает представление как устроен соответствующий контейнер. Если вы представляете, что map - какое-то дерево, то легко представить, что модификация элементов не меняет итераторы. Это же относится и к сложности и к требованиям по памяти.

Но простор для реализации всегда остается. Самый классический пример: list::size vs list::splice - что из этого делать за константу. Тут надо и стандарт знать и версию компилятора.

map не будет перемещать свои элементы. Проблема будет, если вдруг поменяете на unordered.

Формально некорректно, что код считает, что может быть ошибка в обращении к sqlite, но при этом collatingFunctions может уже изменить свое состояние.

Задача не очень удачно сформулирована: лучше было сказать, что после каждого нового элемента мы хотим знать медиану. Тогда понятно, зачем хипы, а не просто сортировка/quick-select

Про производительность deque очень сомнительный совет: источников света вряд ли очень много, а движущихся (aMovingLight) и того меньше. Если размер бакета deque большой, то ничего не выиграется, а если маленький (как в MSVC — 16 байт), то получится много аллокаций — сомнительно, что это лучше компактного вектора. Опять же остается поиск каждого aMovingLight — с полным перепроходом всего списка источников. В целом, полезность всего этого кода сомнительная с учетом дальнейшего отбора по расстоянию.
Рекомендация про deque создает ложную иллюзию исправления. Лучше, наверное, предлагать пересмотреть весь цикл с вставкой в начало, чем пытаться угадать решение.
Например, если нижние инклуды будут влиять на верхние, будет еще более печально, чем сейчас

"Можно увольнять" звучит смело. Обычно нужно взять объяснительную. Есть какие-то особенности по объяснительным удаленных работников?

Предположу, что менять картинки в скане — не подделка, а все остальное сложно предъявить

Всё-таки неясно, в чем отличие от обычной ситуации с библиотеками: например, в debian часто в рамках одного дистрибутива бывает несколько версий одной библиотеки. Понятно, что если слинковаться с несколькими одновременно и передавать объекты, то будут проблемы.
Почему здесь, если поступить также и сделать две stdc++, то ожидаются непреодолимые трудности?

После первого прогона у вас весь файл дисковом кэше в оперативной памяти, поэтому скоростью диска вы не ограничены. Можете ориентироваться на скорость оперативной памяти
Старому clang (6.0) очень помогло вынести в отдельную функцию внутренний цикл и написать __restrict. Что-то типа:
void calc_line(const char c1, const std::string &s2, const int64_t *__restrict v0, int64_t *__restrict v1, size_t n);

Сразу sse появляются и прочие удовольствия
Функция Вейерштрасса — непрерывная, но не имеет производной в каждой точке.
Прерывная(разрывная) в каждой точке — Функция Дирихле
Короче говоря, если бы космические лучи сверхвысоких энергий могли двигаться быстрее света, тогда мы не могли бы наблюдать никаких космических лучей с такой энергией, ибо они должны были бы растерять всю свою энергию до того, как достигнут Земли. Но мы их наблюдаем.


Странная логика. Сначала говорится, что мы можем видеть лучи только медленные скорости света. Потом делается вывод, что раз мы не видим быстрых, то их и нет.
В subversion для того, чтобы посмотреть, кто написал строчку кода, есть команда svn annotate. У нее есть синонимы svn praise (похвалить) и svn blame (обвинить). С кем ни общался, все эту команду называют blame — никто не полезет не то, что хвалить, а просто посмотреть.
Про svn — отчасти шутка, конечно, но нет ли и у вас проблемы, что обвинения на ревью господствуют над похвалами?
Интуитивно кажется, что кроме ROI нужно еще учитывать как часто модель решает ставить, то есть насколько часто бывает, что p_better>p_implied. Иначе может оказаться, что такого почти не бывает.
Кроме того, под этим углом можно рассмотреть вопрос про 30% у отдельных людей: допустим, человек ставит не на все подряд, а только когда очень уверен, что обыграет букмейкера. Если же сделать, чтобы модель ставила только p_better>2*p_implied, возможно у нее тоже ROI приподнимется, но ставить будет очень редко
2

Information

Rating
Does not participate
Registered
Activity