Просто они активно используют кодировку SHIFT_JIS, в которой под кодом бэкслеша (5C) скрывается символ ¥. На линукс это по понятным причинам не распространяется.
Не должно быть удивительным, поскольку в однобайтовых кириллических кодировках ASCII-таблица тоже активно перекраивается.
Попробовал найти ту интерпретацию числа Пи. Нашёл ппц. Видео было удалено по жалобе на нарушение авторских прав.
Lars Erickson, composer of the «Pi Symphony» is suing me because he believes he owns the melody you get when you convert the digits of Pi to music. What he thinks he's going to gain from suing a broke musician is beyond me, but his misguided notions of justice will be put in their place sooner or later. My legal team is presently working on my defense of this ludicrous claim, but the fact that this little song I made is now a federal case is just so stupid.
Хм, я имел в виду абсолютно не скорость работы аллокатора. Обычно память выделяется до начала ресурсоёмких операций и время выделения ничтожно мало по сравнению с временем основного вычисления.
Есть такое свойство локальности ссылок — свойство программ повторно/часто обращаться к одним и тем же объектам; и имеет место временная (temporal) локализация и пространственная (spatial) локализация. Кэширование идет с упреждением, и на этом основании есть смысл обращаться по последовательным адресам, чтобы избежать промахов по кэшу.
Это раз. На пятом правиле советую не зацикливаться, поскольку современные компиляторы достаточно неплохо векторизуют работу с блоками по 4 числа, но со стороны программиста необходимо, чтобы эти блоки лежали в памяти последовательно. Это два.
2) На уровне пользовательской логики программы — std::vector (например, как член класса MainWindow). Производительность тут не нужна, зато в результате избавляемся от необходимости контроля за выделением памяти и получаем ряд полезных функций типа push_back.
А на уровне ресурсозатратных функций работаем с голым массивом и не имеем никаких непредвиденных расходов (например, на v.size(), которая в варианте STL от SGI считается как разность указателей на начало и конец).
1) Надеюсь, вы выделяете память для обычных прямоугольных массивов с помощью цикла new для каждой строки исключительно для тестирования и никогда не будете этого делать в реальных приложениях.
2) При работе с одномерным std::vector можно всегда передать в ресурсоёмкую функцию указатель &a[0] и там работать, как с обычным массивом. Так что вывод про std::vector неправилен. Обобщение на std::vector<std::vector <...> > недопустимо.
Посмотрел скриншоты в комментариях и понял, что лучший рендер тот, который на своём компьютере, в самостоятельно выбранном браузере и операционной системе.
274 гигабайта весит только дамп в tar.bz2 истории страниц английской википедии, который в 15 частях они периодически выкладывают на dumps.wikimedia.org/. Разархивирование по описанию может увеличить объём в ~20 раз. Там же они выкладывают версию в 7z (31.2, увеличение объёма на несколько порядков).
О размере викислада можно только строить предположения, но насколько мне известно, проблем с дисковым пространством у них нет.
И в тени Википедии все бы рассуждали: — «Мы не Википедия, у нас нет миллионов в год на поддержку и расширение инфраструктуры, нет возможности делать открытый API на выгрузку кусочков карт и открытый код».
Поддержка одних открытых проектов со стороны других значительно более крупных — показатель конструктивного развития обоих проектов и ничто иное.
Не должно быть удивительным, поскольку в однобайтовых кириллических кодировках ASCII-таблица тоже активно перекраивается.
Я говорю про то, что описано в habrahabr.ru/blogs/hi/111021/, четвёртое правило. Позволю себе процитировать:
Это раз. На пятом правиле советую не зацикливаться, поскольку современные компиляторы достаточно неплохо векторизуют работу с блоками по 4 числа, но со стороны программиста необходимо, чтобы эти блоки лежали в памяти последовательно. Это два.
2) На уровне пользовательской логики программы — std::vector (например, как член класса MainWindow). Производительность тут не нужна, зато в результате избавляемся от необходимости контроля за выделением памяти и получаем ряд полезных функций типа push_back.
А на уровне ресурсозатратных функций работаем с голым массивом и не имеем никаких непредвиденных расходов (например, на v.size(), которая в варианте STL от SGI считается как разность указателей на начало и конец).
А по-моему это никуда не годится. Вот что получилось у вас с нейросетью, обученной на абсолютно целом исходном изображении:
А вот что получается простым наложением известных цветов на произвольные места холста:
2) При работе с одномерным std::vector можно всегда передать в ресурсоёмкую функцию указатель &a[0] и там работать, как с обычным массивом. Так что вывод про std::vector неправилен. Обобщение на std::vector<std::vector <...> > недопустимо.
О размере викислада можно только строить предположения, но насколько мне известно, проблем с дисковым пространством у них нет.
Поддержка одних открытых проектов со стороны других значительно более крупных — показатель конструктивного развития обоих проектов и ничто иное.
Насчёт остальных я практически уверен, что они работают с extensions.checkCompatibility.5.0 = true