N в четвёртой степени это как-то очень много.
На практике для маленьких размеров от исходного состояния невозможно уйти дальше фиксированного количества шагов. Для «пятнашки» 3х3 это всего 31 ход.
Можно проверить полным перебором 9! состояний.
По виду противников не понятно, что они вообще пользуются украшениями, возможно стоит их добавить к образу самих врагов.
Откуда у динозавра брошь или кольцо как-то совсем не понятно, а так можно догадаться что кольцо сняли с носа например :)
Идея прикольная, но четыре процессора с синхронизацией на мой взгляд сильно сложно.
По логике должно быть достаточно одного, но с «расширенной» разрядностью.
Условно говоря у каждого «настоящего» адреса памяти есть ещё несколько «альтернативных», значений, данные в которых могут отличаться, при этом операции для них делаются те же самые, но процессор принимает решения, например операции ветвления только по «настоящему» значению.
Помимо обычной эмуляции на «настоящих» данных можно будет «подкрасить» ещё несколько альтернативных данных, допустим ещё 4 варианта для 16 цветов.
При отображении учитывать не только «настоящие» данные, но и альтернативные.
Но объектная модель, необходимая для карт от этого никуда не пропадает, просто ей занимаются в JavaScript, отвязавшись от DOM, по сути дублируя часть функций.
И это проблема, поскольку сами производители браузеров не горят желанием оптимизировать SVG, переписав его на какой-нибудь Vulkan ввиду того, что производительность в SVG не критична — карточные движки же его не используют :)
Было бы очень круто, если бы Яндекс-картам не приходилось писать свой векторный движок на JavaScript/WebAssembly + WebGL, а браузер нормально работал с вектором из коробки. Но «обход» этой проблемы никак не приближает её решение.
Полная спецификация довольно сложна для оптимизации, но для некоторого подмножества SVG, например без кривых она возможна, статья тут яркий пример кстати.
Вот это как раз было наиболее интересно — сравнение производительности.
Раньше SVG никак не использовал GPU, поэтому WebGL был в явном выигрыше, но возможно сейчас ситуация изменилась в лучшую сторону.
Кроме того — у Яндекса есть свой браузер, на котором можно «оптимизировать» SVG для своих-же карт :)
А почему в Яндекс картах не используется SVG?
Браузер сам отлично справляется с прорисовкой/парсингом/обработкой контуров (возможно даже рисуется с аппаратным ускорением).
SVG лучше подходит для печати с высоким DPI, чем растровые картинки сейчас.
Похоже Ваше мнение о сложности std::list не популярно, как и моё :).
По сути «химера» это лишь дополнительное поле размера, которое создаёт линейную сложность лишь при вставке части от другого списка.
Однако при вставке другого списка целиком — сложность константна (т.к. размер вставляемого списка известен).
Исходя из структуры данных «двусвязный список», линейная сложность вставки куска из другого списка действительно «сюрприз». Но для универсальной библиотеки контейнеров это лучше, так как многие другие операции будут эффективнее. Это можно понять и простить :).
А почему люди должны быть с ним согласны?
Я, например, не согласен с тем что они «улучшили» сложность size() в std:list до константы за счёт других операций.
Стандарт можно только понять и простить :)
Название статьи на мой взгляд не отражает что сам чат во главе это Stream API. А Python, Django и React по сути лишь обвязка для рекламируемого сервиса.
В коде написаны явные вызовы size() и оператора индексирования [] для каждого элемента массива. Для такой простой операции как увеличить на 1 — это может быть довольно накладно.
Код работает даже лучше, чем написан. В чём извращение? :)
Без глубокого погружения в тему смарт-контрактов продуктивная дискуссия с обществом не представляется возможным, особенно по китайской документации :).
На мой взгляд — редактировать Main при добавлении каждой новой функции излишне, лучше чтобы сами функции там регистрировались, например, при помощи декоратора.
В частных распределённых бухгалтерских книгах смарт-контракты являются одним из тех терминов, которыми консультантами разбрасываются без особого внимания к чётким определениям или цели. Консультанты по корпоративному программному обеспечению обычно зарабатывают на двусмысленности, а смарт-контракты — апофеоз корпоративного мракобесия, потому что их можно определить буквально как что угодно.
Оно там и было, исходя из механики игры после прицеливания предмет должен был попадать без промаха.
Просто чемодан очень медленно передвигался, на других предметах не так заметно.
Какой-то не до конца асинхронный пример получился :)
Нужно как-то ближе к реальности.
Пока резал морковку — вода уже выкипела, нужно залить новую.
Не успел порезать лук — морковка переварилась.
Чтобы резать — нужен нож и доска… и прочие прелести асинхронности
У меня тупой вопрос:
Каким образом при добавлении морковки и лука мы знаем что они уже порезаны?
По куску кода явных await там нет, хотя это вроде как длительный процесс, первый кандидат на async.
Как «повар» я сразу могу начать кипятить воду, а также резать морковку и лук.
При этом когда готовы вода+морковка её можно добавить в воду и продолжать резать лук, который добавить потом, после того как морковка сварится.
Хорошая статья по ссылке для отрисовки фигур, но для небольшого размера шрифта в пикселах карта текстур (точнее даже атлас, как написали ниже) будет лучше и быстрее.
Софтварный растеризатор шрифта для малых размеров учитывает хинты / привязку к пикселям для хорошей читаемости. А текстура не требует многократной перерисовки одного и того же фрагмента.
Журналисты «Интернэшнл геральд трибюн» ну никак не могли подождать пока публикация романа завершится. Какое-то странное отношение к читателям Артура Кларка.
На мой взгляд стоило бы продолжить публикацию романа, хуже от этого вряд ли было бы.
А так перебои в публикации привлекли ненужное внимание читателей к этой теме.
Ну, это как-то сильно надмозгово для шейдера на мой взгляд.
Сам Wireframe рисовали ещё до того, как стали закрашивать треугольники одним цветом.
В OpenGL для этого есть glPolygonOffset, например, чтобы рисовать сетку поверх.
показать как и, главное, зачем это всё можно использовать
По-моему ответ был в прошлой статье — чтобы непосредственно кидаться по HTTP gzip или deflate из архива без распаковки для тех клиентов, что понимают.
Но меня интересует как, например, для 100МБ файла будут в таком случае обрабатываться Range запросы куска с середины.
Да ладно, это же писалось на одном дыхании — источник перлов :)
Я хотел бы добавить, что сейчас меня переполняют эмоции и чувства.
Мной что-то овладело и из меня вырывалось наружу вот это.
Я просто понял, что явно делаю что-то не так Я.
А не этому способствует невезение.
Но я не хочу сейчас об этом говорить.
P.S. «Оптимизировать SEO» аж затронуло мою постоянную реакцию при старте игры :)
Для указания языка страницы в HTML используются атрибуты hreflang или lang.
Что значит «или»? Они же не взаимоисключающие.
Атрибут lang используется для указания языка текущей страницы (в том числе отдельных частей, например в div, p, span если язык отличается)
hreflang же атрибут элемента link и указывает ссылки на локализованные версии этой же страницы
А если топику не выставили язык, или не все поддерживаемые языки выставили — клиент ничего не получит? А если клиент переключит язык — он снова получит те же самые уведомления?