Просто PCX это построчное одномерное сжатие RLE, а квадродерево позволит сжать сразу однородные двумерные блоки, да и массив реперных точек не нужен.
P.S. Формулировка "целиком загружается в память" слегка сбивает с толку, почему бы не написать "отображается в память", при таких размерах файлы же не читаются от и до, а только в тех местах, где надо.
Пост менеджера продукта о том, что профессия станет актуальной через пару лет, а ещё через 4 года работы (в 2027 наверное) можно будет говорить о 2000$. Но вообще поздравляю человека со вторым опубликованным постом, мой, например, удалили из песочницы без каких либо пояснений :)
Учитывая что там внутри xorshift — плохо что не дают явно выставить seed для контролируемой генерации. Из за этого генератор псевдослучайных чисел нужно писать руками, хотя он уже есть !?
Про сложение с плавающей точкой сильно круто сказано. Степень основания может сильно отличаться и мантиссу меньшего числа можно будет усечь или даже проигнорировать без потери точности результата. Это числа с фиксированной точкой при сложении как целые, и тоже могут переполняться.
Почему только 15 лет? IEEE 754 приняли ещё в 1985м. Это особенность формата чисел с плавающей точкой, который поддерживается железом. Об этом было прекрасно известно ещё до появления Javascript в том же C например. Не бывает бесконечной точности при фиксированном размере. Предложение хоронить язык на таком основании очень смелое. Какие языки тогда останутся, Python?
Это проблемно. Причем настолько, что даже в этой статье про блокчейн решили не писать. Вместо этого немножко про красивые хеш деревья, которые чуть ли не стандарт распределенных систем — того же torrent или git. Разрешение конфликтов по сути опустили, а там же самое интересное :)
Расширение файла это не всегда последние три символа, есть специальная функция для этого — os.path.splitext. Зачем нужно два прохода и пустые папки по месяцам — не ясно.
Можно ли считать ошибкой что любая каша из цифр и знаков плюс минус считается "валидным числом"?
Про строку из одних пробелов писали выше — по логике там вообще вылет будет.
Использование deflate в таких соревнованиях на мой взгляд неспортивно. Причем сам же автор отмечает, что замена одного символа на другой повлияла на размер. Это по факту меняет условие самого короткого кода на самый короткий код после сжатия, что всё же разные вещи.
Странно, что в примерах на поиск максимума в массивах не используется reduce. На мой взгляд это проще, чем map с… И вообще создавать дополнительные массивы для поиска максимума странно, если можно обойтись итераторами.
Почему автор считает что случайная генерация карт в шутерах это технически не сложно? На мой взгляд генерация карты в которую будет приятно и интересно играть довольно сложная задача. Есть весьма реальные риски что качество некоторых генерируемых карт будет отвратительным.
P.S. В том же CS Source была случайность в виде закрытых дверей/проходов, но популярности это особо не дало.
Sketch дешевле чем Photoshop, основная задача быстро и красиво делать наборы макетов, которые после нескольких итераций будут утверждены. Условно говоря заказчику понравился надцатый вариант, и только после этого можно верстать, разбивать на компоненты и т.д. Переделывать макет в дизайн проге, которая векторный и растровый редактор проще и быстрее, чем менять вёрстку.
Даже так — менять вёрстку и компоненты потом настолько накладно, что это нормально выкинуть несколько вариантов макета в корзину, но точно убедиться, что от заказчика потом правок больше не будет (ха-ха).
Кстати на этапе дизайна все может и закончиться, до вёрстки дело не дойдет.
В вашей непрерывной последовательной последовательности перевода пропущен абзац с числами 30 и 500 000 000 на который осталась ссылка. А там, между прочим, на оригинального автора снизошло озарение, что идентификатор и дата связаны. Поэтому можно использовать бинарный поиск, который далее в статье и расписывается.
Признаю что RTSR тут выглядит чётче, но насколько он стабилен? Например если сместить изображение от сетки на пиксель вправо/влево или вверх вниз. Артефактов нет?
Может просто неудачно подобрано, но местами выглядит хуже, чем стандартный фильтр Ланцоша. И вообще идея универсального увеличителя на мой взгляд обречена на провал, так как в низком разрешении дерево, обои, одежда или даже часть лица персонажа выглядят похоже, а при увеличении обладают абсолютно разными деталями. Соответственно сначала нужно корректно классифицировать объект, затем уже на основании выборки объектов заданного типа воссоздавать детали. А это довольно сложная задача.
Информация полезная, но почему это таблица? По сути несколько списков, связи по строкам нет.
Ну не совсем подряд, но должно быть около того, иначе MIPMAP плохо подобран и пиксели будут шуметь при движении.
Просто PCX это построчное одномерное сжатие RLE, а квадродерево позволит сжать сразу однородные двумерные блоки, да и массив реперных точек не нужен.
P.S. Формулировка "целиком загружается в память" слегка сбивает с толку, почему бы не написать "отображается в память", при таких размерах файлы же не читаются от и до, а только в тех местах, где надо.
А почему отказались от сжатого дерева квадрантов?
Пост менеджера продукта о том, что профессия станет актуальной через пару лет, а ещё через 4 года работы (в 2027 наверное) можно будет говорить о 2000$. Но вообще поздравляю человека со вторым опубликованным постом, мой, например, удалили из песочницы без каких либо пояснений :)
Учитывая что там внутри xorshift — плохо что не дают явно выставить seed для контролируемой генерации. Из за этого генератор псевдослучайных чисел нужно писать руками, хотя он уже есть !?
Про сложение с плавающей точкой сильно круто сказано. Степень основания может сильно отличаться и мантиссу меньшего числа можно будет усечь или даже проигнорировать без потери точности результата. Это числа с фиксированной точкой при сложении как целые, и тоже могут переполняться.
Почему только 15 лет? IEEE 754 приняли ещё в 1985м. Это особенность формата чисел с плавающей точкой, который поддерживается железом. Об этом было прекрасно известно ещё до появления Javascript в том же C например. Не бывает бесконечной точности при фиксированном размере. Предложение хоронить язык на таком основании очень смелое. Какие языки тогда останутся, Python?
Это проблемно. Причем настолько, что даже в этой статье про блокчейн решили не писать. Вместо этого немножко про красивые хеш деревья, которые чуть ли не стандарт распределенных систем — того же torrent или git. Разрешение конфликтов по сути опустили, а там же самое интересное :)
Знак, указывающий поворот налево, выглядит странно. Там же сама дорога поворачивает
Расширение файла это не всегда последние три символа, есть специальная функция для этого — os.path.splitext. Зачем нужно два прохода и пустые папки по месяцам — не ясно.
Можно ли считать ошибкой что любая каша из цифр и знаков плюс минус считается "валидным числом"?
Про строку из одних пробелов писали выше — по логике там вообще вылет будет.
Использование deflate в таких соревнованиях на мой взгляд неспортивно. Причем сам же автор отмечает, что замена одного символа на другой повлияла на размер. Это по факту меняет условие самого короткого кода на самый короткий код после сжатия, что всё же разные вещи.
Странно, что в примерах на поиск максимума в массивах не используется reduce. На мой взгляд это проще, чем map с… И вообще создавать дополнительные массивы для поиска максимума странно, если можно обойтись итераторами.
В продукте по логике есть русская локализация, даже документацию перевели https://www.acronis.com/ru-ru/support/documentation/ATI2021/index.html#41820.html
С продажами прошлой версии в РФ через Инфозащиту тоже не задалось, так что сейчас видимо уже традиции
Почему автор считает что случайная генерация карт в шутерах это технически не сложно? На мой взгляд генерация карты в которую будет приятно и интересно играть довольно сложная задача. Есть весьма реальные риски что качество некоторых генерируемых карт будет отвратительным.
P.S. В том же CS Source была случайность в виде закрытых дверей/проходов, но популярности это особо не дало.
Sketch дешевле чем Photoshop, основная задача быстро и красиво делать наборы макетов, которые после нескольких итераций будут утверждены. Условно говоря заказчику понравился надцатый вариант, и только после этого можно верстать, разбивать на компоненты и т.д. Переделывать макет в дизайн проге, которая векторный и растровый редактор проще и быстрее, чем менять вёрстку.
Даже так — менять вёрстку и компоненты потом настолько накладно, что это нормально выкинуть несколько вариантов макета в корзину, но точно убедиться, что от заказчика потом правок больше не будет (ха-ха).
Кстати на этапе дизайна все может и закончиться, до вёрстки дело не дойдет.
В вашей непрерывной последовательной последовательности перевода пропущен абзац с числами 30 и 500 000 000 на который осталась ссылка. А там, между прочим, на оригинального автора снизошло озарение, что идентификатор и дата связаны. Поэтому можно использовать бинарный поиск, который далее в статье и расписывается.
Признаю что RTSR тут выглядит чётче, но насколько он стабилен? Например если сместить изображение от сетки на пиксель вправо/влево или вверх вниз. Артефактов нет?
Может просто неудачно подобрано, но местами выглядит хуже, чем стандартный фильтр Ланцоша. И вообще идея универсального увеличителя на мой взгляд обречена на провал, так как в низком разрешении дерево, обои, одежда или даже часть лица персонажа выглядят похоже, а при увеличении обладают абсолютно разными деталями. Соответственно сначала нужно корректно классифицировать объект, затем уже на основании выборки объектов заданного типа воссоздавать детали. А это довольно сложная задача.