Проблема в том, что биткоины, конечно, виртуальны и анонимны, зато работа, товары и услуги — вполне реальны, осязаемы, а следовательно — легко контролируются, ограничиваются и пресекаются.
Так что, в теории, биткоины позволят сделать свободным только рынок интеллектуальной собственности, информации.
Я напишу тебе код, а потом на вырученные монетки закажу у других людей разработку дизайна или перевод текста, например. Но я не смогу (при должном государственном контроле, который конечно же появится) обналичить эти монетки и купить себе буханку хлеба. И непонятно, как с этим бороться иначе, кроме как устранив сам источник контроля.
Собственно, государство только и отличается тем, что отжимает бабло, иначе оно было бы обычной частной компанией.
Но, если в каких-то областях кто-то может попытаться оправдать это «защитой договорных обязательств» или «постройкой дорог», то попытка контролировать то, что уже проходит мимо — «и деньги отберет, да еще и в глаз ударит».
Так что предвижу неслабое негодование властей по мере всё большего распространения биткоинов и (попыток) их интеграции в экономику.
Такая защита делается установкой в заголовок AJAX запроса токена (как в django, например — X-CSRFToken) и соответствующей проверкой на стороне сервера перед отдачей JSON'a.
Стороннему сайту ни через <script> заголовок не передать, ни сам токен не извлечь. Или у гугла есть какие-то причины не использовать такой подход?
Интересно, будет ли работать такой подход — покрутить на разные углы и прокоррелировать с исходным изображением? Предположительно, наиболее закрученные изображения должны давать более высокие значения корреляции при одинаковых углах поворота.
Я чего-то не уловил? В Java, C++, Python, и т.д. есть очереди с приоритетами и фиксированные массивы, при чем реализованные наилучшим образом.
А вообще, от того, как устроена та или иная структура данных, зависит её применимость к конкретной задаче, только и всего. В какой-то задаче «более-менее быстро» может и удовлетворяет требованиям, но в общем случае это определенно не так.
Ну вы тут уже напридумывали условий, я тоже так могу — список на 100 млн элементов. Допустим, я собираю данные в реалтайме, и периодически их прореживаю.
То вы отрицаете всякую необходимость раздельных операций поиска и вставки, то отрицаете существование таких раздельных операций в Java, то вам задачи не те. Да, не всегда в ваших способах асимптотика выше, но остается множество совершенно лишних операций типа создания объектов, копирования списков и так далее.
Как это сделать за O(n+m) по вашему?
Я конечно предположу ваш ответ — взять кусок списка с 5 по 7, слить его со вставляемыми элементами, склеить кусок списка до 5 + полученный кусок + кусок списка после 7. Но нахрена так жить?
Существует отдельно операция поиска элемента и отдельно операция его удаления / вставки нового. Эти операции разные, и в разных ситуациях общая асимптотика времени будет отличаться от подхода в лоб «найти и вставить, повторить».
Пример, я согласен, привел не очень наглядный, вот лучше — проделать то же самое, но чередуя с элементами коллекции (т.е. вставить свой элемент, пропустить один существующий, вставить следующий свой элемент). Или другой пример — удалить m идущих подряд элементов, начиная с элемента A.
На самом деле, вы просто плохо осведомлены о рынке труда программистов вообще и в нашей стране в частности. Безусловно, знание лучше незнания, и где-то и кому-то даже ваши свежепрочитанные знания пригодятся, но не хочу вас расстраивать — это очень и очень узкий круг компаний. В 95% случаев подобное банально не нужно от сотрудника (а иногда даже и вредно для компании — возомнит себя спецом и начнет бабла требовать, а выгоды от этих знаний — никаких), так и живет индустрия.
И, опять же, разработка не на одних алгоритмах зиждется — очень часто важны умения грамотно проектировать систему и разрабатывать сложные архитектурные решения, потому не стоит так однобоко относиться к саморазвитию — можно неожиданно оказаться полным профаном в разработке реального софта.
Начнем с того, что все это происходит в вузах, которые можно конкретно пересчитать на пальцах одной руки — ВМК МГУ, МФТИ, СПбГУ, ИТМО, матмех УрФУ (который был УрГУ). Я мог что-то упустить, но во всех остальных даже и близко (т.е. хоть-сколько-нибудь-близко) ничего подобного нет. Ну вот нет и все. Грустно, да.
Вообще, в Java LinkedList очень даже можно вставлять и удалять элементы отдельно от их поиска.
Метод listIterator() вернет ListIterator, который поддерживает вставки и удаления элементов (add(T element) и remove() соответственно) в текущей позиции итератора, за константное время, естественно. При этом поиск позиции вставки / удаления является, очевидно, отдельной операцией.
Например, если мне надо вставить m элементов после элемента А в середине списка, я затрачу не O(mn) (если бы вставка была отделима от поиска), а O(n + m) (O(n) на поиск позиции для вставки, и O(m) на вставку всех m элементов).
Так что, в теории, биткоины позволят сделать свободным только рынок интеллектуальной собственности, информации.
Я напишу тебе код, а потом на вырученные монетки закажу у других людей разработку дизайна или перевод текста, например. Но я не смогу (при должном государственном контроле, который конечно же появится) обналичить эти монетки и купить себе буханку хлеба. И непонятно, как с этим бороться иначе, кроме как устранив сам источник контроля.
Но, если в каких-то областях кто-то может попытаться оправдать это «защитой договорных обязательств» или «постройкой дорог», то попытка контролировать то, что уже проходит мимо — «и деньги отберет, да еще и в глаз ударит».
Так что предвижу неслабое негодование властей по мере всё большего распространения биткоинов и (попыток) их интеграции в экономику.
Все попытки собрать налоги с каких-то «теневых» экономических процессов — банальный отжим бабла.
emerge -vuDN worldСтороннему сайту ни через
<script>заголовок не передать, ни сам токен не извлечь. Или у гугла есть какие-то причины не использовать такой подход?А вообще, от того, как устроена та или иная структура данных, зависит её применимость к конкретной задаче, только и всего. В какой-то задаче «более-менее быстро» может и удовлетворяет требованиям, но в общем случае это определенно не так.
Удалите все четные элементы in-place.
Вставляемые элементы: 10 11 12 — m элементов;
Хочу получить: 1 2 3 4 5 10 6 11 7 12 8 9.
Как это сделать за O(n+m) по вашему?
Я конечно предположу ваш ответ — взять кусок списка с 5 по 7, слить его со вставляемыми элементами, склеить кусок списка до 5 + полученный кусок + кусок списка после 7. Но нахрена так жить?
И почему же вы так боитесь итераторов?
Пример, я согласен, привел не очень наглядный, вот лучше — проделать то же самое, но чередуя с элементами коллекции (т.е. вставить свой элемент, пропустить один существующий, вставить следующий свой элемент). Или другой пример — удалить m идущих подряд элементов, начиная с элемента A.
И, опять же, разработка не на одних алгоритмах зиждется — очень часто важны умения грамотно проектировать систему и разрабатывать сложные архитектурные решения, потому не стоит так однобоко относиться к саморазвитию — можно неожиданно оказаться полным профаном в разработке реального софта.
Метод listIterator() вернет ListIterator, который поддерживает вставки и удаления элементов (add(T element) и remove() соответственно) в текущей позиции итератора, за константное время, естественно. При этом поиск позиции вставки / удаления является, очевидно, отдельной операцией.
Например, если мне надо вставить m элементов после элемента А в середине списка, я затрачу не O(mn) (если бы вставка была отделима от поиска), а O(n + m) (O(n) на поиск позиции для вставки, и O(m) на вставку всех m элементов).
Такие дела.