Графики красивые: Онлайн-редактор графиков — Создавайте свои графики и диаграммы

Давайте уже установим seaborn и, конечно же, также пакет notebook, чтобы получить доступ к песочнице с данными.

pipenv install seaborn notebook

Помимо этого, перед началом работы давайте импортируем несколько модулей.

import seaborn as sns
import pandas as pd
import numpy as np
import matplotlib

Строим первые графики

Перед тем, как мы начнем строить графики, нам нужны данные. Прелесть

Давайте посмотрим, как это работает на наборе данных о рейсах самолетов.

flights_data = sns.load_dataset("flights")
flights_data.head()

Вся магия происходит при вызове функции load_dataset, которая ожидает имя загружаемых данных и возвращает dataframe. Все эти наборы данных доступны в репозитории на Github.

Диаграмма рассеяния — Scatter Plot

Диаграмма рассеяния — это диаграмма, которая отображает точки на основе двух измерений набора данных. Создать диаграмму рассеяния в seaborn очень просто, ведь для этого нужна всего одна строчка кода.

sns.scatterplot(data=flights_data, x="year", y="passengers")

Легко, не правда ли? Функция scatterplot принимает в себя набор данных, который нужно визуализировать, и столбцы, которые будут выступать как оси x и y.

Линейный график — Line Plot

Этот график рисует линию, которая представляет собой развитие непрерывных или категориальных данных. Этот вид графиков популярен и известен, и его легко создать. Как и раньше, мы воспользуемся функцией lineplot с набором данных и столбцами, представляющими оси x и y. Остальное за нас сделает seaborn.

sns.lineplot(data=flights_data, x="year", y="passengers")

Столбчатая диаграмма — Bar Plot

Наверное, это самый известный тип диаграммы, и, как вы уже догадались, мы можем построить этот тип диаграмм с помощью seaborn, также, как мы сделали это для линейного графика и диаграммы рассеяния, с помощью функции barplot.

sns.barplot(data=flights_data, x="year", y="passengers")

Она очень красочная, знаю. Позже мы научимся кастомизировать ее.

Расширение функционала с matplotlib

Seaborn основывается на matplotlib, расширяя ее функциональные возможности и абстрагируя сложность. При этом seaborn не теряет в своей мощности. Любая диаграмма seaborn может быть кастомизирована с помощью функций из библиотеки matplotlib. Эта механика может пригодиться в определенных случаях и позволяет seaborn использовать возможности matplotlib без необходимости переписывать все ее функции.

Допустим, вы хотите построить несколько диаграмм одновременно с помощью seaborn, в этом случае вы можете воспользоваться функцией subplot из matplotlib.

diamonds_data = sns.load_dataset('diamonds')
plt.subplot(1, 2, 1)
sns.countplot(x='carat', data=diamonds_data)
plt.subplot(1, 2, 2)
sns.countplot(x='depth', data=diamonds_data)

С помощью функции subplot на одном графике можно построить несколько диаграмм. Функция принимает в себя три параметра: первый – количество строк, второй – количество столбцов, третий – количество диаграмм.

Мы визуализируем по одной диаграмме seaborn на каждой части графика, смешивая функционал matplotlib и seaborn.

Seaborn и Pandas

Мы уже говорили о том, что seaborn любит pandas до такой степени, что все ее функции строятся на структуре dataframe. До этого момента мы использовали seaborn с предварительно загруженными данными, но что, если мы хотим визуализировать данные, которые уже загрузили с помощью pandas?

drinks_df = pd.read_csv("data/drinks.csv")
sns.barplot(x="country", y="beer_servings", data=drinks_df)

Создание красивых графиков с помощью стилей

Seaborn дает возможность менять интерфейс ваших графиков. Для этого из коробки у нас в распоряжении есть пять стилей: darkgrid, whitegrid, dark, white и ticks.

sns.set_style("darkgrid")
sns.lineplot(data = data, x = "year", y = "passengers")

А вот другой пример.

sns.set_style("whitegrid")
sns.lineplot(data=flights_data, x="year", y="passengers")

Крутые варианты использования

Мы познакомились с основами seaborn, а теперь давайте применим знания на практике и построим несколько диаграмм с одним и тем же набором данных. В нашем случае вы используем набор данных «tips», который можно скачать непосредственно с помощью seaborn.

Сначала загрузим набор данных.

tips_df = sns.load_dataset('tips')
tips_df.head()

Мне нравится выводить первые несколько строк набора данных, чтобы получить представление о столбцах и самих данных. Обычно я пользуюсь несколькими функциями pandas, чтобы уладить проблемы с данными, такие как значения null, или добавить в набор данных информацию, которая может быть полезной. Подробнее об этом вы можете прочитать в руководстве к pandas.

Давайте добавим еще один столбец, в котором будет процентное отношение чаевых ко всему счету. 

tips_df["tip_percentage"] = tips_df["tip"] / tips_df["total_bill"]
tips_df.head()

Теперь данные выглядят так:

А теперь мы начнем строить графики.

Процент чаевых

Давайте попробуем разобраться с процентным соотношением чаевых и счета. Для этого воспользуемся функцией histplot, которая сгенерирует гистограмму.

sns.histplot(tips_df["tip_percentage"], binwidth=0.05)

Чтобы все хорошо читалось, нам пришлось настроить свойство binwidth, зато теперь мы быстрее можем понять и оценить данные. Большинство клиентов оставляют чаевые в размере от 15 до 20% от счета, но есть несколько случаев, когда чаевые превышают 70%. Эти значения называются аномалиями или выбросами, и на них всегда стоит обращать внимание, чтобы понять являются ли эти значения ошибочными.

Также мне было интересно, меняется ли процент чаевых в зависимости от времени дня.

sns.histplot(data=tips_df, x="tip_percentage", binwidth=0.05, hue="time")

На этот раз мы создали диаграмму с помощью всего набора данных, а не одного столбца, и установили свойство hue на столбец time. Так в диаграмме будут использоваться разные цвета для каждого значения времени, и к ней добавится легенда.

Общее количество чаевых за определенный день недели

Еще одна интересная метрика — это количество чаевых, которые получает персонал в зависимости от дня недели.

sns.barplot(data=tips_df, x="day", y="tip", estimator=np.sum)

Кажется, пятница — хороший день, чтобы остаться дома.

Влияние размера столика и дня недели на чаевые

Иногда нужно понять, как несколько переменных влияют на конечный результат. Например, как день недели и размер столика влияют на процент чаевых?

Чтобы построить следующую диаграмму, мы объединим функцию pivot из pandas для предварительной обработки, а затем нарисуем тепловую карту.

pivot = tips_df.pivot_table(
    index=["day"],
    columns=["size"],
    values="tip_percentage",
    aggfunc=np.average)
sns.heatmap(pivot)

Заключение

Конечно, есть еще множество штук, которые мы можем сделать с seaborn, про них вы можете узнать в официальной документации.

Надеюсь, вам понравилась эта статья так же, как и мне. Спасибо за прочтение!

Узнать подробнее о курсе «Python Developer. Professional».

Зарегистрироваться на вебинар по теме «Фреймворкирование и метаклассы».

Лучшие красивые игры с нереалистичной графикой

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

СВЯЗАННЫЕ: Лучшие игры с рисованной графикой

Это может означать 3D-графику уровня Pixar, 2D-анимацию, вдохновленную Флейшером, или что-то совершенно другое. Например, вы видели Гарольда Палтуса? Когда разработчики стремятся к нереалистичному виду, единственным ограничением является их воображение. Ниже приведены некоторые из самых лучших примеров.

Обновлено Лукасом Олахом 27 января 2023 г.: Со временем в этот список попадает все больше и больше игр. Отсутствие реализма очень нравится публике, а также разработчикам, которые могут делать невозможные вещи со своей работой. Пришло время пополнить этот список новыми играми, которые отодвинули реализм в сторону, чтобы делать то, что у них получается лучше всего: дать волю воображению в своем мире и способах, которыми они его визуализируют.

16 Spyro Reignited Trilogy

Spyro the Dragon существует уже довольно давно, и его красивая графика в основном была качеством серии, несмотря на ее взлеты и падения.

С учетом сказанного, оригинальная трилогия была поднята на новый уровень теперь, когда у нас есть лучшее оборудование для таких вещей, добавлен уникальный дизайн даже для второстепенных персонажей и создано множество миров, которые одновременно увлекательны и живы, как никогда. .

15 Unravel

Unravel дает нам прекрасное сочетание реализма и фантазии. Его человеческие персонажи действительно имеют реалистичные черты, и они даже используют настоящие фотографии для таких вещей, как рамки, но все это смешано с нашими Wolderful главный герой (извините за него).

И, если вы хотите добавить кого-то еще в свое приключение, продолжение Unravel Two предлагает совместную многопользовательскую игру.

14 It Takes Two

Еще одна игра, которая играет на грани между реализмом и фантазией. It Takes Two по-прежнему предлагает совсем другой вид приключений, с трехмерным исследованием и интегрированным многопользовательским режимом. до A Way Out от тех же разработчиков.

Это также интересный вариант для тех, кто ищет сюжетные приключения в своих играх, с разбросанными по ним хорошими темами — но, эй, никаких спойлеров.

13 Overcooked 2

Кажется, между нереализмом и многопользовательской игрой существует связь. Overcooked 2 — а точнее, вся серия Overcooked — столь же прекрасна, сколь и безумна. Ваша задача состоит в том, чтобы приготовить как можно больше блюд, а также убедиться, что вы ничего не сожгли в процессе.

Это довольно просто, но качество везде. Вам это понравится так же, как вы будете ненавидеть человека, с которым вы играете, поскольку вы все пытаетесь синхронизировать вещи как можно лучше.

12 MediEvil

Еще одна старая жемчужина, переделанная для нынешних поколений, и на этот раз довольно культовая классика. MediEvil включает в себя множество различных областей, в которых вам предстоит спасти королевство Гэллоумир в роли нежити-неудачника сэра Дэниела Фортескью.

СВЯЗАННЫЕ: MediEvil: Вещи, которых вы не знали о сериале

Хотя оригинал был лучше с точки зрения жуткости, в ремейке все выглядело потрясающе, с атмосферой Тима Бертона в эстетике и персонажах. Хороший выбор для тех, кто любит исследовать миры, в которые они отваживаются.

11 Terraria

Пиксельные игры — один из старейших и самых красивых художественных стилей для видеоигр. И, конечно же, у старых аппаратных средств не было большого выбора в этом вопросе, но теперь многие разработчики могут использовать этот стиль просто из страсти. Войдите в Террарию.

Здесь вас ждет великолепный двухмерный мир исследований, демонстрирующий культовый художественный стиль, сочетающийся с игровым процессом. Это уместно, и игра очень удобна для глаз, что делает ее довольно расслабляющей.

10 Оками

Художественный стиль Оками в стиле cel-shaded во многом основан на суми-э, стиле китайской живописи тушью, который мигрировал в Японию в 14 веке. Хотя игра изначально имела более реалистичный стиль, она приняла этот более экспрессионистский вид, чтобы лучше оптимизировать обработку для PS2.

Художественный стиль также проявляется в меню и пользовательском интерфейсе, а также в необходимости рисовать объекты, чтобы воссоздавать их в самой игре, что помогает вам в вашем путешествии. Самое главное, использование художественного стиля, который существует сотни лет назад в Японии, помогает создать гармонию с сюжетом игры, основанным на японской мифологии.

9 Ratchet And Clank: Rift Apart

Если вы когда-нибудь хотели сыграть в фильм Pixar, то эта игра — самая близкая к вам. Ну, на самом деле, не являясь собственностью Pixar, то есть. Начиная с PlayStation 2, Ratchet & Clank — это популярная серия шутеров с элементами платформера.

Команда разработчиков Insomniac всегда отдавала приоритет графической отделке, не делая акцента на графическом реализме. Внешний вид персонажей Ratchet & Clank потрясающий, и в некоторых случаях они выглядят так, как вы могли бы представить себе реалистичного инопланетянина. Мультяшный стиль также отлично подходит для творческого оружия сериала.

8 Cuphead

Вдохновленный ранним золотым веком анимации, Cuphead известен своим художественным стилем (и сложностью, но это другой разговор). Искусство было сделано вручную, как и старые мультфильмы, и самоотверженность окупилась.

СВЯЗАННЫЕ: Cuphead: все боссы, ранговые (и как их победить!)

От обычных врагов, с которыми вы сталкиваетесь во время бега и стрельбы, до сложных боев с боссами, которые часто проходят через два или даже три этапа, прежде чем завершатся , создание этой сложной игры было долгим процессом для разработчиков из студии MDHR. Художественный стиль был настолько захватывающим, что даже вдохновил на создание побочного мультфильма, возвращаясь к среде, которая изначально вдохновляла разработчиков.

7 Crash Bandicoot 4: It’s About Time

Хотя вся серия могла бы занять место в этом списке, ее «четвертая» часть заслуживает дополнительных похвал, когда дело доходит до ее внешнего вида. Благодаря обновленному художественному стилю, изменениям в дизайне персонажей и эстетике, которая в значительной степени опирается на стилизованный мультяшный вид, Crash смешивает старый стиль Looney Tunes с современным 3D-моделированием.

Не говоря уже о том, что каждый уровень предлагает разные шейдеры, которые применяются, когда вы решаете более сложную зеркальную версию.

6 Kena: Bridge Of Spirits

Еще одна игра с потрясающим художественным стилем (и сложностью, кстати). В Kena настолько хорошо проработаны персонажи, что ее кат-сцены достойны кино. Действительно легко вообразить экранизацию во многих случаях на протяжении всей игры.

СВЯЗАННЫЕ: Games To Play If You Like Kena: Bridge Of Spirits

Если этого недостаточно, области полностью меняются, когда вы восстанавливаете их от порчи, делая переходы просто великолепными. Вы можете идти в ногу со своим прогрессом, просто анализируя окружающую среду и то, насколько она остается поврежденной.

5 Hades

Еще одна замечательная демонстрация того, как адаптировать греческие мифы в игре. Hades предлагает великолепное искусство в сочетании с безумным и красивым игровым процессом. С множеством сценариев, которые меняются при каждом прохождении, вам есть на что посмотреть, если вы готовы рискнуть и уделять больше внимания окружающей среде, чем своим врагам.

У вас даже есть собственная комната, которую можно настроить. Персонажи также представлены в красивом стиле, напоминающем искусство комиксов.

4 The Legend Of Zelda: Breath Of The Wild

Еще одна игра, вся серия которой могла бы быть в этом списке. Breath of the Wild на шаг впереди других игр Zelda благодаря своему уникальному стилю. Красивая окружающая среда идеально подходит для игрового процесса, ориентированного на исследование, и побуждает игрока продолжать идти, просто чтобы увидеть больше мира.

СВЯЗАННЫЕ: Вещи, которые каждый делает в «Дыхании дикой природы»

Кроме того, огромное количество различных наборов доспехов побуждают игроков настраивать свой внешний вид, пока у них не будет идеального Линка для них. Персонажи как всегда очаровательны, даже те, с которыми вам предстоит сражаться.

3 Stardew Valley

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

Stardew Valley также предлагает большое разнообразие: очаровательные персонажи, с которыми можно подружиться или завязать романтические отношения, животные, о которых нужно заботиться, и монстры, с которыми нужно сражаться.

2 Concrete Genie

У нас есть не только еще одна игра с красивой 3D-графикой, но и Concrete Genie также имеет красивую и живую 2D-работу в рисунках главного героя Эша, которые оживают.

Оба художественных стиля хорошо сочетаются друг с другом, и вы даже можете делать входные данные для рисунков, доставляя вам удовольствие от того, что вы вносите свой вклад в искусство игры. Если вам нужна игра с действительно уникальным художественным стилем, это отличный выбор.

1 Persona 5

Многие игры имеют эстетику аниме, и мы также видели немало попыток создания игр в стиле аниме в 3D. Хотя многим это удается, никто из них не делает это с таким же талантом, как в Persona 5.

Благодаря великолепной графике и стилизованному пользовательскому интерфейсу, а также эпизодическим эпизодам из аниме, Persona достигла нового графического уровня в Persona 5, подняв ставки на совершенно новый уровень.

СЛЕДУЮЩАЯ: самые требовательные к графике игры для Android и мобильных устройств

Что делает (графику) системный документ красивым

Что делает (графический) системный документ красивым

Кайвон Фатахалян, Стэнфордский университет

Приложение: я добавил несколько дополнительных советов для руководителей конференций, членов комитетов по работе с документами и сортировщиков бумаг.

«SIGGRAPH ненавидит документы по системам», — говорят разочарованные исследователи.

Во время совещания SIGGRAPH PC я услышал пренебрежительный комментарий члена комитета: «Я не верю, что здесь есть что-то новое, может быть, это хороший системный документ».

И из недавнего обсуждения SIGGRAPH после опровержения: «Это явно системный документ, а не исследовательский вклад».

Вопрос не в том, есть ли место системным исследованиям в графическом сообществе. (Да!) Скорее, эти комментарии предполагают, что и авторы графических статей, и рецензенты неправильно понимают интеллектуальную ценность исследований графических систем. Понимание ключевых принципов и ценностей системного исследовательского мышления важно для разработчиков систем, которые хотят сообщить о своих выводах, и для рецензентов, оценивающих эти результаты. Улучшение этого понимания позволит графическому сообществу лучше подготовиться к оценке и распространению своих ценных системных результатов.

В этой статье я надеюсь внести свой вклад в наше общее понимание принципов (графических) системных исследований. Я подозреваю, что большинству исследователей компьютерной графики, даже тем, кто явно не стремится создавать новые системы, может быть полезно применять в своей работе принципы системного мышления.

Эта статья не является попыткой дать исчерпывающее руководство по написанию статей по системам, для которых есть много отличных вариантов. Например, я рекомендую «Советы Дженнифер Видом по написанию технических статей» [Widom 2006] или «Как (и как не надо) писать хорошую статью о системах» [Levin and Redell 1983].

Исследования графических систем важны для SIGGRAPH.

Достижения в графических системах уже давно играют важную роль в SIGGRAPH. На самом деле системная работа исторически оказывала несоразмерное влияние не только на развитие компьютерной графики, но и на широкий спектр технических областей. Легко составить впечатляющий список примеров.

• В статье Рейеса [Cook 84] представлены ключевые идеи системы рендеринга, которая более двух десятилетий генерировала изображения для большинства художественных фильмов.
• Reality Engine Graphics [Akeley 93] описал методы, которые продолжают лежать в основе современного графического конвейера с ускорением на GPU, который сейчас есть в каждом ноутбуке и смартфоне в мире (рынок на 100 миллиардов долларов). Помимо игр, сегодняшние многофункциональные пользовательские интерфейсы не существовали бы без ускорения GPU.
• Программируемый вершинный процессор [Lindholm 01] в конечном итоге превратился в обычные программируемые ядра современных графических процессоров. Эволюция этой архитектуры ускорила приложения во многих областях помимо графики (физика, молекулярная биология, медицинская визуализация, вычислительные финансы и многие другие). Современные программируемые ядра GPU в настоящее время являются основными вычислительными механизмами для глубокого обучения и для многих из самых быстрых суперкомпьютеров в мире.
• Идеи языка шейдинга RenderMan [Hanrahan 90] и Cg [Mark 04] сформировали дизайн современных языков шейдинга, которые сегодня сохраняются как в онлайновых, так и в оффлайновых графических системах.
• Brook [Buck 04] был прямым предшественником CUDA, языка, который стал центральным для популяризации параллельных вычислений и теперь используется широким кругом областей для программирования графических процессоров.
• Фототуризм [Snavely 06] предоставил новый способ организации и просмотра растущего массива онлайн-коллекций фотографий, а также открыл двери для новых приложений и продуктов, использующих большие визуальные данные.
• Системы Direct3D 10 [Blythe 06] и OptiX [Parker 10] описывают архитектуры, которые сегодня составляют основу практически всех систем растеризации в реальном времени и трассировки лучей с ускорением на графическом процессоре (включая новейшее оборудование для трассировки лучей на графических процессорах).
• Идеи во Франкенкамере [Адамс 10] можно ясно увидеть в текущих версиях API камеры Android от Google, который используется в качестве аппаратной абстракции для программирования одной из самых популярных и самых передовых камер в мире.
• Halide [Ragan-Kelley 12] сейчас используется в производстве в Google для обработки большинства изображений, снятых на телефоны Android, а также в Photoshop и Instagram. Хотя Halide был разработан для графических приложений, его идеи непосредственно вдохновили новые системы генерации кода для глубокого обучения, такие как TVM, которые лежат в основе таких сред, как Apache MX.Net.

В последние годы мы видели статьи на SIGGRAPH, в которых описывался конвейер обработки HDR-фотографий в современных камерах смартфонов [Hasinoff 16][Wadhwa 18], практические конвейеры генерации VR-видео [Andersen 16], дизайнерские решения, лежащие в основе реализации широко используемая библиотека OpenVDB [Museph 13] и систем для крупномасштабной обработки видео [Poms 18]. На SIGGRAPH 2016 была целая сессия технических документов по предметно-ориентированным языкам (DSL) для графики и моделирования, а в 2018 году целый специальный выпуск TOG был посвящен проектированию современных систем производственного рендеринга.

Статьи, посвященные вкладу систем, составляют меньшинство на SIGGRAPH, но они часто публикуются. Без сомнения, эти усилия заняли важное место в графическом сообществе, а также в более широком технологическом мире.

Что представляет собой исследовательский вклад?

Попросите исследователей компьютерной графики назвать определяющие характеристики их любимых бумаг. Независимо от области, я подозреваю, что списки будут похожими. Отличные статьи учат нас чему-то, чего мы не знали о нашей области: либо они содержат идею, о которой мы никогда не думали, либо заставляют нас думать по-другому (или более ясно) о понятии, которое, как мы думали, мы знаем, либо вводят труднодоступную информацию. создать артефакт (или инструмент), который будет полезен для будущего прогресса. Мы склонны называть это «вкладом» — термин, который я все больше ценю, поскольку он воплощает в себе то, что хорошая статья делает для области. Например:

Читатель узнал что-то новое:

• Новый способ формализации задачи (например, применение к задаче нового математического аппарата)
• Лучший алгоритм (быстрее, стабильнее, проще, меньше параметров) или аппроксимация, которая работает потрясающе хорошо.
• Доказательство, устанавливающее ранее неизвестное свойство или связь между двумя понятиями.
• Идентификация примитивов, раскрывающих структуру предметной области.
• Заставил читателя подумать: «Я не понимал, что это возможно» или «Я никогда не думал об этой проблеме таким образом».
• Представляет новое классное приложение.

Возможно, менее удивительный, но в целом полезный для прогресса других:

• Эксперимент, дающий базовый результат для нового типа задач.
• Новый набор данных, позволяющий решать новые задачи в полевых условиях.

Исследование графических систем, как и любое хорошее исследование, не освобождает от интеллектуального вклада.

Как и в случае со всеми хорошими исследовательскими работами, интеллектуальный вклад статьи по системам гораздо больше заключается в идеях и мудрости, содержащихся в статье, и гораздо меньше в конкретном артефакте (реализации), который она описывает.

Тем не менее, те, кто не привык оценивать системные исследования, могут с трудом определить их интеллектуальный вклад, потому что они часто не записаны явно в форме алгоритма или уравнения. И наоборот, авторы статей, потратившие значительное время на внедрение и проектирование системы (и, возможно, даже на ее успешное развертывание для пользователей), часто ошибочно полагают, что простое описание возможностей системы и ее реализации представляет собой «хорошую» системную статью.

Определение проблемы: хороший системный документ описывает требования к системе с точки зрения целей, нецелей и ограничений.

В некоторых областях компьютерной графики входные и выходные данные задачи обычно четко определены. Проблема в том, что сама проблема трудно решить! Напротив, формулирование и определение правильной проблемы, которую необходимо решить, является важной частью системного исследования — часто это самая трудная часть. Хорошее системное мышление требует, чтобы архитектор усвоил сложный набор (потенциально противоречащих друг другу) целей проектирования, проектных ограничений и потенциальных стратегий решения. Поэтому, чтобы оценить вклад системного документа, важно четко понимать эти требования к проблеме.

Характеристика проблемы требует от системного архитектора значительного времени на изучение предметной области и приобретение знаний об аппаратном и программном обеспечении, человеческом факторе и алгоритмических методах. Таким образом, работа по четкому установлению и формулировке системных требований сама по себе является частью интеллектуального вклада статьи о графических системах.

Другими словами, в хороших системных работах часто выдвигается аргумент из ряда вон выходящий:

Мы стремимся достичь целей А, В, С при ограничениях X, Y, Z. изложены в наших усилиях (иначе мы, вероятно, использовали бы это!), поэтому, исходя из нашего опыта создания систем в этой области, мы можем преобразовать этот опыт в определенный набор системных требований. Эти требования могут быть неочевидны для читателей, которые не тратили много времени на обдумывание или создание приложений в этой области.

Эта установка важна по нескольким причинам:

• Она определяет требования к «хорошему» решению, сообщая о ключевых проблемах проблемной области. Поскольку неожиданные ограничения и требования проявляются только при построении реальных комплексных систем, хорошие системные документы выполняют эту работу для сообщества.
• Он обеспечивает основу для оценки качества решений по проектированию системы, принятых авторами. Оценка качества предлагаемого решения предполагает постановку вопроса: являются ли проектные решения, принятые авторами, причиной того, что система достигла заявленных целей?
• Он обеспечивает контекст, который ведет к более обобщаемым знаниям. Поскольку читатели, вероятно, не имеют тех же целей и ограничений, что и авторы статьи, понимание целей и ограничений автора помогает читателям понять, какие проектные решения применимы к их собственным проблемам и какие аспекты предлагаемой системы, возможно, потребуется изменить или игнорировать.

Давайте рассмотрим несколько примеров.

Пример 1: В разделе 1 статьи Рейеса целый столбец текста посвящен потребности Pixar обрабатывать сцены неограниченной сложности, которые они определили с точки зрения геометрии сцены и данных текстуры. В этой колонке глобальные световые эффекты также были отмечены как важная нецелевая задача, поскольку опыт авторов в Pixar показал, что глобальные эффекты часто можно разумно аппроксимировать локальными вычислениями с использованием текстурного наложения.

Пример 2: Десять лет спустя Билл Марк сформулировал сложный набор целей дизайна для Cg. Чтобы повысить производительность разработчиков, необходимо было повысить уровень абстракции для программирования раннего оборудования GPU. Сделать это было сложно, поскольку разработчики ожидали прозрачности производительности низкоуровневых абстракций (причиной использования графических процессоров была производительность!), а поставщики графических процессоров хотели гибкости для быстрого развития аппаратных реализаций графических процессоров. Эти цели сильно отличались от тех, которые стояли перед создателями предыдущих языков шейдинга для автономных средств визуализации, и в конечном итоге были решены с помощью подхода, который был в основном «C для графического оборудования», а не язык шейдинга для графики, такой как RSL.

Пример 3. В недавнем документе Google HDR+ системные требования представлены в виде набора руководящих принципов для определения того, какие алгоритмы являются кандидатами на включение в современное приложение для камеры смартфона: они должны работать достаточно быстро, чтобы обеспечить немедленную обратную связь, не требуют вмешательства человека и никогда не производят результат, который выглядит хуже, чем традиционная фотография.

Пример 4. В недавней работе Йонг Хе о языке программирования шейдеров Slang требования к проблеме были установлены в подробном справочном разделе (раздел 2), в котором описывается, как цель поддержки модульного кода шейдера расходилась с целью написания высокопроизводительных шейдеров на языке программирования Slang. современные игровые движки. Этот раздел служил для формулирования целей, а также для обсуждения альтернатив дизайна.

Примечание для рецензентов: работая на ПК SIGGRAPH, я заметил, что рецензенты просили сократить изложение описания проблемы на том основании, что в тексте не описывается непосредственно предлагаемая система. Хотя все письменные работы должны быть максимально краткими, в этих предложениях не учитывалась техническая ценность точного описания решаемой проблемы. Эта обратная связь, по сути, просила авторов удалить изложение, касающееся ключевого интеллектуального вклада, чтобы освободить место для дополнительных деталей реализации системы.

Ключевой вывод: во многих хороших статьях по системам выдвигается новое организующее наблюдение о структуре проблемы.

Учитывая установленные цели и ограничения, системный документ часто предлагает формулировку проблемы, которая облегчает выполнение этих требований. Другими словами, во многих системных статьях приводится аргумент:

Полезно думать о проблеме с точки зрения этих структур (например, используя эти абстракции, эти представления или разлагая проблему на эти модули), потому что, когда , есть неоспоримые преимущества.

Преимущества могут принимать форму: улучшенной производительности системы (или масштабирования), повышенной производительности программиста, большей расширяемости/универсальности системы или возможности предоставления новых возможностей на уровне приложений, которые раньше были невозможны.

Определение полезной структуры проблемы часто формирует центральную интеллектуальную идею системной статьи. Как и в других областях компьютерной графики, элегантные концептуальные идеи можно изложить в нескольких предложениях. Например:

• Система рендеринга Рейеса: микрополигон — это простое объединяющее представление, которое служит общим интерфейсом между многими типами поверхности и многими методами затенения поверхности. Разбиение поверхностей на микрополигоны одновременно отвечает целям поддержки произвольной геометрической сложности (поскольку сложные поверхности всегда можно разбить на микрополигоны) и избегания артефактов наложения.
• Язык затенения Renderman: учитывая разнообразие материалов и источников света в сценах, желательно определить интерфейс для расширения возможностей средства визуализации, предоставив язык программирования для выражения этих вычислений. Для производительности и производительности этот язык программирования должен предоставлять абстракции высокого уровня, соответствующие условиям уравнения рендеринга.
• Cg: язык программирования для новых программируемых графических процессоров не должен быть языком затенения, специфичным для предметной области, а должен быть языком относительно общего назначения, предназначенным для обеспечения прозрачности производительности при нацеливании на графические процессоры.
• Frankencamera: аппаратные интерфейсы современных камер несовместимы с потребностями многокадровой фотографии, но простой абстракции временной шкалы достаточно для описания поведения камеры для многокадровых последовательностей.
• Halide: сочетание шести простых директив планирования (разделить, переупорядочить, вычислить_в, сохранить_в, векторизовать, распараллелить) достаточно для принятия основных «высокоуровневых» решений по оптимизации кода для широкого спектра современных приложений обработки изображений.
• Сленг: специальные стратегии, используемые современными играми для достижения модульности кода шейдера и специализации кода (взлом препроцессора, вставка строк и пользовательские DSL), можно было бы выразить гораздо элегантнее, если бы HLSL был расширен небольшим набором хорошо известных функций из популярные современные языки программирования.
• Компоненты шейдеров: чтобы одновременно получить преимущества специализации кода и модульности при создании библиотеки шейдеров, необходимо согласовать границы декомпозиции кода для специализации кода с границами для передачи параметров CPU-GPU.
• Ebb: абстракции реляционной алгебры могут использоваться для выражения различных алгоритмов физического моделирования в независимой от представления манере.

Хорошие системные документы освещают ключевые проектные решения (и обсуждают альтернативы этим решениям).

Учитывая набор требований, системный архитектор обычно сталкивается с различными стратегиями решения. Например, требование к производительности может быть решено с помощью алгоритмических инноваций, разработки нового специализированного оборудования или того и другого (модификация существующего алгоритма для лучшего сопоставления с существующим параллельным оборудованием). В качестве альтернативы, путь к повышению производительности может лучше всего идти через сужение области действия системы до меньшей области задач. Цель производительности может быть достигнута за счет разработки новых абстракций программирования, которые могут быть реализованы как новый предметно-ориентированный язык или через библиотеку, реализованную в существующей системе.

В результате автор системной статьи должен определить ключевые варианты, сделанные при архитектуре своей системы, и разработать обоснование этих проектных решений. Это обычно включает в себя обсуждение палитры потенциальных альтернатив и предоставление аргументов в пользу того, почему сделанный выбор является предпочтительным способом удовлетворения заявленных требований и целей проектирования. Недостаточно просто описать пройденный путь, не говоря, почему он считается хорошим.

Обсуждение ключевых проектных решений дает мудрость и рекомендации для будущих разработчиков системы. Поняв обоснование выбора системного разработчика, читатель сможет лучше определить, какие решения, сделанные в документе, могут быть применимы к их собственным требованиям.

Размышляя о своих дизайнерских решениях, исследователи должны учитывать следующее:

Отличать ключевые решения от деталей реализации. Системный архитектор должен четко указать, какие решения он считает тщательно продуманными решениями, имеющими центральное значение для дизайна системы (вклад статьи, за которую он хочет получить признание), и какие решения были приняты «просто для того, чтобы что-то заработало». Когда для полноты изложения необходимо упомянуть менее важные решения, полезно уточнить, что «алгоритм X использовался, но решение не считалось фундаментальным, и, вероятно, возможны многие другие не менее хорошие варианты».

Аргументируйте, что «должно» быть сделано, а не что «можно» сделать. Другими словами, хорошие системные архитекторы стремятся аргументировать, почему принятые решения являются предпочтительными решениями для достижения определенных системных целей. Одним из общих свойств предпочтительного решения является то, что оно простое. Поэтому частым вопросом при оценке качества проектных решений является то, являются ли предписанные решения максимально простым подходом к достижению желаемых целей. Представление более сложного метода часто может быть заманчивым для студентов, но хорошо спроектированная система будет избегать сложности, которая не является фундаментальной для достижения целей.

Выявление сквозных проблем. Многие важные проектные решения основаны на рассмотрении сквозных вопросов, которые проявляются только при построении сквозной системы. Например, если рассматривалась только одна цель проектирования или один аспект системы, может быть несколько жизнеспособных решений. Однако часто бывает так, что проектные решения системного архитектора мотивированы комплексным взглядом на проблему. Например:

• Алгоритм X может производить выходные данные более низкого качества, чем алгоритм Y, но X может быть быстрее и проще, а ошибки, создаваемые X, могут быть приемлемыми, поскольку они покрываются операцией более поздней стадии обработки.
• Запуск более дорогого алгоритма на этапе 1 системы может быть предпочтительнее, поскольку он генерирует более однородные выходные данные, которые лучше распараллеливаются на этапе 2.
• Конкретная глобальная оптимизация может быть возможна на определенном этапе обработки, но эта оптимизация будет препятствовать объединению этапа с другими модулями системы, что ограничивает расширяемость системы.

Обсуждение сквозных вопросов является важным аспектом системного мышления. (это менее распространено в методоцентрических исследованиях). Сквозные и сквозные проблемы часто являются причиной того, что более сложные методы исследовательского сообщества могут быть менее желательны для использования в эффективных системах. Часто новые методы (разумно) разрабатываются на основе упрощающих предположений, которые помогают облегчить изучение новых методов. Системное мышление должно учитывать полную картину контекста, в котором методы используются на практике.

Примечание для авторов статьи: Неспособность описать (и впоследствии оценить) проектные решения является наиболее распространенной ошибкой при написании системной статьи. Я видел материалы, описывающие интригующие системы, но справедливо отвергаемые, потому что изложение не отражало того, что было сделано и почему. Эти документы не смогли предоставить сообществу общие советы по построению систем и больше напоминали перечисление функций или системную документацию.

Оценка: отвечали ли ключевые проектные решения заявленным требованиям и целям?

Если документ четко описывает цели и ограничения системы, а также формулирует ключевые решения по проектированию системы, то стратегия оценки системы состоит в предоставлении доказательств того, что описанные решения способствовали достижению поставленных целей.

В частности, когда оценка системы сосредоточена на производительности, возникает соблазн сравнить сквозную производительность предлагаемой системы с производительностью конкурирующих альтернативных систем. Хотя такая оценка показывает, что цели по производительности были достигнуты, не менее (а иногда и более) важно проводить эксперименты, специально оценивающие преимущества ключевых оптимизаций и проектных решений. Оценка того, почему был достигнут успех, необходима для проверки правильности основных утверждений статьи. Неспособность выполнить эту оценку оставляет открытой возможность того, что успех системы обусловлен другими факторами. (например, разработка высококачественного программного обеспечения), чем предлагаемые ключевые идеи.

Оценка: привносит ли система новые возможности в поле?

Встречи SIGGRAPH PC часто начинаются с обсуждения важности продвижения «новых идей», и существует широкое согласие в том, что показатели для оценки меняются, когда они представляют новую тематическую область или открывают новые горизонты. Например, системы, которые вводят новый опыт или новые способы осмысления данных (например, Phototourism [Snavely 2006] или AverageExplorer [Zhu 2014]), не имеют очевидного численного сравнения с предыдущими системами. Оценка этого типа работы обычно включает в себя демонстрацию нового опыта или идей, которые теперь возможны с учетом новых возможностей. (В этих случаях выбор методов был «хорошим», поскольку они позволяли реализовать новую возможность.)

При оценке достоинств документа о системах рецензентам важно учитывать, в какой степени система вводит новые возможности в полевых условиях и каковы последствия этих новых возможностей. В то время как новые методы взаимодействия, такие как два приведенных выше примера, часто легче идентифицировать как обеспечивающие новые возможности, также может быть случай, когда резкое улучшение производительности, масштаба операций или производительности программиста переводит поле в «новые возможности». «режим. Например, возможность впервые обеспечить производительность в режиме реального времени (включение интерактивных приложений или взаимодействие с человеком в цикле) или возможность писать приложения, использующие все более крупные базы данных изображений, можно было бы считать новыми возможностями, если бы они Раньше программистам было сложно или невозможно выполнять эти задачи.

В этих случаях рецензенты должны помнить о ценности расширенного количественного сравнения с предшествующими системами или методами, поскольку предшествующие системы, отвечающие установленным ограничениям, могут не существовать. Точно так же «пользовательские исследования» могут быть менее ценными, чем понимание того, в какой степени система позволяет ее авторам (которые могут быть практикующими экспертами в какой-либо области) выполнять задачи, которые никогда раньше не выполнялись сообществом. Когда нереалистично дать однородные оценки, авторы статьи обязаны привести четкие аргументы в пользу того, почему предоставленная оценка достаточна для придания научной достоверности предлагаемым идеям, а рецензенты должны тщательно рассмотреть последствия предложенных идей. работа. Запросы на длинную числовую оценку не должны использоваться вместо размышлений и суждений автора/рецензента.

Заключительные мысли

Я надеюсь, что эта статья показала глубину мысли, необходимую для хороших системных исследований и написания хороших системных статей. Архитектура хороших систем — сложная, продуманная задача, которая включает в себя понимание сложного набора факторов, балансировку противоречивых целей и ограничений, оценку множества потенциальных решений для создания единой работающей системы и измерение результатов этих идей.

Подход «у нас есть результат, теперь просто запишите его» редко оказывается удачным при написании системной статьи. Поскольку, как правило, нет нового доказательства, уравнения или псевдокода алгоритма, на которые можно было бы указать как на явно идентифицируемый вклад, интеллектуальная ценность системной работы передается через тщательное изложение, которое документирует мудрость, полученную в процессе проектирования. Лично я нахожу акт письма ценным механизмом для достижения ясности в отношении того, чего достигла моя работа. По мере того, как я пытаюсь обосновать дизайн системы, на ум приходят новые альтернативы и оценочные вопросы. (Мы уверены, что не можем удалить эту функцию и получить тот же результат? Откуда мы знаем, что нам это действительно нужно?)

С другой стороны, рецензирование документа по системам требует серьезных размышлений и суждений.