@buckbeak > python plotting
Ты правда считаешь, что эта поебулька не будет обсираться на тех объемах данных, на которых у меня сейчас gnuplot обсирается?
да и нахуй тебе ПЛОТТИТЬ дохуя данных, ты хочешь рендер дохуя? типичные трюки для графика «многоданных» — это сабсемплинг, оверплоттинг и аппроксимация, всё из этого доступно в ggplot
@corpse > ParaView was developed to analyze extremely large datasets using distributed memory computing resources. It can be run on supercomputers to analyze datasets of petascale as well as on laptops for smaller data. ParaView is an application framework as well as a turn-key application.
@buckbeak ну а что касается многоданных на R (это вообще никак не относится к графикам — на A5 графике при 200 DPI и 24-битном цвете можно теоретически передать МАКСИМУМ 5.5 мебибайт (= 148 × 210 mm² × (200/25.4 mm¯¹)² * 3 byte) информации, многоданные нужно вручную ужимать на графике трюками) — мы гоняли вычисления в R на многогигабайтных массивах на amazon ec2, и заебись было
@ulidtko Я тебе могу на баше написать скрипт, который будет данные в потоке ужимать. Я не хочу его писать. Я хочу взять хуйню и сказать ей «рисуй». Со скриптом на баше я и на гнуплоте остаться могу.
@ulidtko Видишь ли, я не вижу большой трудности в задаче «нахуярить пикселей на картинку 1000x1000 из файла поточно». Если ни одна модная косожопая хуйня этого не умеет, то придется мне ее изобретать.
Выдирание High/Low-значений для заданных промежутков — это как раз то, чем я сейчас спасаюсь. Это нахуй мне не нужно. Мне нужно только чтобы gnuplot не сваливался в OOM хотя бы при заданных явно границах графика.
Хули ты раскукарекался?
назначение графика — не столько представление данных, сколько визуализация определённых фич, особенностей этих данных, их характеристик.
и тем более никто не станет читать ПОЛГИГАБАЙТА осмысленных данных с картинки. Это бессмысленно. Ты не сможешь за вразумительное время прочитать даже полмегабайта данных (в тысячу раз меньше!), из-за уёбищности глаз как системы ввода. // анимации не в счёт
ПОЭТОМУ к многоданных перед плоттингом применяются сжимающие (моделирующие, абстрагирующие) преобразования и аппроксимации. Когда тебе важно увидеть фичи распределения данных, и ты знаешь, что вся выборка сделана в одних и тех же условиях (т.е. представляет одно и то же распределение) — тебе нахуй не надо видеть все миллионы датапоинтов одновременно; небольшая рандомная подвыборка (subsample) из нескольких тысяч/десятков тысяч измерений даст тебе полное понимание всего распределения, и не засрёт к хуям дерьмом всё поле графика. Понимаешь? Из предположения гомогенности выборки получается приём сабсемплирования, приём обоснованного отбрасывания излишних (не несущих новой информации) данных.
Другой пример, выше из plplot твоего. Там точно тот же трюк выполнен, только ещё и несколько раз из-за неуверенности в каждом исходном предположении. Предполагаем, что модель из кубических сплайнов достаточно хорошо фиттит наши данные? (момент абстракции здесь) Ок, тогда фиттим модель и плоттим её. Заебись, всё видно. Предполагаешь, что твои, скажем, логи посещения периодичны? Значит, неплохо подойдёт суперпозиция суточной и недельной синусоид + аномалии. Плоттишь тоненько эти синусоиды, и жирно — аномалии; сразу становится видно, когда всё идёт по плану vs когда что-то пошло не так (причём как аномальный рост, так и аномальный спад будет одинаково хорошо видно).
Применяя такое моделирование, ты попросту выбрасываешь уже известные/предсказуемые/неинтересные фичи данных, оставляя место на графике для действительно важных характеристик. Это далеко за пределами говноскриптов на баше; это анализ и моделирование данных. И тебе его придётся делать — потому что ты физически не сможешь видеть полгига данных на одном графике одновременно.
@ulidtko Если это критично, очевидно, что "сжиманием" займусь я сам. А раз уж мне похуй -- я хочу просто сказать "построй график из этих данных вот такого размера", и пусть он за меня ебется, подгоняя данные под размер. И вообще, у некоторых этот размер может быть зависим от размера окна, например. Собственно, у меня так и было, и тупая js-библиотека реально пыталась нарисовать больше точек чем пикселей.
Кароч "just works" требует немного большего со стороны рисовальщика.
@ulidtko другой часто используемый приём: плоттить модель + outliers («выбросы» за пределами полутора-двух-трех сигм распределения), а «обычные» данные внутри одной сигмы не плоттить вообще. Они ничего нового всё равно не приносят, только засирают визуально график модели. Для лучшей уверенности в модели можно параллельно (в бэкграунде либо отдельной вертикальной панелью) делать barplot количества этих «стандартных» нерисуемых данных, а ещё лучше — вместе с количеством рисуемых аутлаеров (столбики другого цвета поверх базовых столбиков) для сравнения соотношения первых со вторыми. // по статистическим законам, одна сигма нормального распределения будет составлять 67% выборки (столбцы будут 2:1 по высоте), две — 95%, три — 99.7%
@ulidtko Улиточка, мне нахуй не надо «считывать информацию» из графика. Я не настолько наркоман. График мне нужен для того, что окинуть взглядом данные и понять, на что они похожи.
@kb а, так если ты об этом — то да, ggplot многое делает сам. Ну размеры окна само собой, всё автоматически выбирается (и обычно вполне удачно к тому же). Мне он нравится исключительно красивой декларативностью описания трансформов данных и самого графика. Никакой тебе еботни с пикселями и длинами массивов, как в том же ебаном матплотлибе (← говно). График в ggplot описывается как сумма своих логических компонентов: например, гистограмма + line plot; каждый из компонентов имеет набор «эстетик» (визуально видимых крутилочек), которые просто декларативно мапятся из полей твоих данных, функций, моделей («формулы» они там называются) над данными.
— и оно строит график по датасету movies (в R искоробки включены некоторые public domain датасеты для демонстраций), с рейтингом на оси x (rating — колонка в датасете), с гистограммой и линией какой-то там плотности (не могу проверить ща чо ето @ лень лукапить), вот такой:
— само выбирает шкалу, само делает легенду, само делает всё; ты просто добавил маппинг эстетики «цвет» на фичу данных.
Красиво дохуя, короче; очень быстро получается экспериментировать и смотреть разные-разные проекции данных, моделировать на ходу. Прям аж хочу реимплементнуть тот же интерфейс на js.
@ckorzhik обычно вполне норм, они там прикомпиливают всякие фортрановые хуйни для етих дел.
Важно только не лохануться с векторизацией; как и в матлабе/octave (как и в numpy, да как и в произвольном скриптоговне, тащемта), код на ручных циклах работает в разы медленнее, чем векторизированный. Ну типа, вместо
for i in range(len(X)): X[i] = c * Y[i] + Z[i]
будет существенно быстрее просто X = c * Y + Z. // здесь надо понимать, как определены операции на массивах
То есть, вычисляющий код лущ писать в терминах свёрток, векторных сложений/умножений, матричных операций, и т.д. — чем в терминах индексов и циклов. Опять же, они вполне могут уже в своей свёртке воткнуть SIMD, задрочить кеш локалити, контролировать поинтер альясинг, и всё вот это ускоряющее говно. Это реально любого скриптоязыка касается.
R + ggplot2.
@buckbeak на самом деле нормально
да и нахуй тебе ПЛОТТИТЬ дохуя данных, ты хочешь рендер дохуя?
типичные трюки для графика «многоданных» — это сабсемплинг, оверплоттинг и аппроксимация, всё из этого доступно в ggplot
@buckbeak комар дурак, и опять носится не с теми проблемами, с которыми стоило бы
@buckbeak ну а что касается многоданных на R (это вообще никак не относится к графикам — на A5 графике при 200 DPI и 24-битном цвете можно теоретически передать МАКСИМУМ 5.5 мебибайт (= 148 × 210 mm² × (200/25.4 mm¯¹)² * 3 byte) информации, многоданные нужно вручную ужимать на графике трюками) — мы гоняли вычисления в R на многогигабайтных массивах на amazon ec2, и заебись было
@komar
help(sample)в R.@corpse
@komar у тебя полгига говна даже теоретически не влезет на твой график (с использованием всех возможных цветов и хорошего DPI), попробуй САБСЕМПЛИНГ
@failman два позитрона етому учёному
@komar ебать ты дурак
ему говорят — применяй субсемплирование — нет, говорит, не хочу субсемплирование, хочу жрать говно
@komar ты в курсе вообще, сколько данных генерируют эксперименты на LHC? там вам вебскейл даже рядом не валялся.
@komar ты идиот, я тебе повторю ответ на твой вопрос ещё раз: СУБСЕМПЛИРУЙ
@komar топ перд
@failman
да иди-ка ты нахуй, комар, тебе что-то советовать — себя не жалеть. Жри дерьмо дальше с полгига данных на графике™, удачи.
@komar и что ты увидишь в этих пикселях?..
назначение графика — не столько представление данных, сколько визуализация определённых фич, особенностей этих данных, их характеристик.
и тем более никто не станет читать ПОЛГИГАБАЙТА осмысленных данных с картинки. Это бессмысленно. Ты не сможешь за вразумительное время прочитать даже полмегабайта данных (в тысячу раз меньше!), из-за уёбищности глаз как системы ввода. // анимации не в счёт
ПОЭТОМУ к многоданных перед плоттингом применяются сжимающие (моделирующие, абстрагирующие) преобразования и аппроксимации. Когда тебе важно увидеть фичи распределения данных, и ты знаешь, что вся выборка сделана в одних и тех же условиях (т.е. представляет одно и то же распределение) — тебе нахуй не надо видеть все миллионы датапоинтов одновременно; небольшая рандомная подвыборка (subsample) из нескольких тысяч/десятков тысяч измерений даст тебе полное понимание всего распределения, и не засрёт к хуям дерьмом всё поле графика. Понимаешь? Из предположения гомогенности выборки получается приём сабсемплирования, приём обоснованного отбрасывания излишних (не несущих новой информации) данных.
Другой пример, выше из plplot твоего. Там точно тот же трюк выполнен, только ещё и несколько раз из-за неуверенности в каждом исходном предположении. Предполагаем, что модель из кубических сплайнов достаточно хорошо фиттит наши данные? (момент абстракции здесь) Ок, тогда фиттим модель и плоттим её. Заебись, всё видно. Предполагаешь, что твои, скажем, логи посещения периодичны? Значит, неплохо подойдёт суперпозиция суточной и недельной синусоид + аномалии. Плоттишь тоненько эти синусоиды, и жирно — аномалии; сразу становится видно, когда всё идёт по плану vs когда что-то пошло не так (причём как аномальный рост, так и аномальный спад будет одинаково хорошо видно).
Применяя такое моделирование, ты попросту выбрасываешь уже известные/предсказуемые/неинтересные фичи данных, оставляя место на графике для действительно важных характеристик. Это далеко за пределами говноскриптов на баше; это анализ и моделирование данных. И тебе его придётся делать — потому что ты физически не сможешь видеть полгига данных на одном графике одновременно.
@komar ты до сих пор не допёр, что график данных в любом случае теряет информацию? // кроме тривиальных случаев из десятка плоских датапоинтов
@l29ah нахуй пойди, я на это не собираюсь отвечать.
@anonymous ето
@kb ggplot иногда делает.
@kb проблема в том, что принцип «сжимания» зависит от твоего понимания данных. Поэтому оно почти всегда делается эксплицитно.
@anonymous http://ну-да-ну-да.jpg.to
@ulidtko другой часто используемый приём: плоттить модель + outliers («выбросы» за пределами полутора-двух-трех сигм распределения), а «обычные» данные внутри одной сигмы не плоттить вообще. Они ничего нового всё равно не приносят, только засирают визуально график модели. Для лучшей уверенности в модели можно параллельно (в бэкграунде либо отдельной вертикальной панелью) делать barplot количества этих «стандартных» нерисуемых данных, а ещё лучше — вместе с количеством рисуемых аутлаеров (столбики другого цвета поверх базовых столбиков) для сравнения соотношения первых со вторыми. // по статистическим законам, одна сигма нормального распределения будет составлять 67% выборки (столбцы будут 2:1 по высоте), две — 95%, три — 99.7%
Всё это делается в ggplot декларативно.
@kb а, так если ты об этом — то да, ggplot многое делает сам. Ну размеры окна само собой, всё автоматически выбирается (и обычно вполне удачно к тому же). Мне он нравится исключительно красивой декларативностью описания трансформов данных и самого графика. Никакой тебе еботни с пикселями и длинами массивов, как в том же ебаном матплотлибе (← говно). График в ggplot описывается как сумма своих логических компонентов: например, гистограмма + line plot; каждый из компонентов имеет набор «эстетик» (визуально видимых крутилочек), которые просто декларативно мапятся из полей твоих данных, функций, моделей («формулы» они там называются) над данными.
Снова пример, прямо из доков ggplot, пишешь:
— и оно строит график по датасету
movies(в R искоробки включены некоторые public domain датасеты для демонстраций), с рейтингом на осиx(rating— колонка в датасете), с гистограммой и линией какой-то там плотности (не могу проверить ща чо ето @ лень лукапить), вот такой:http://docs.ggplot2.org/current/geom_histogram-21.png
... Добавляешь маппинг цвета на количество оценок,
... + geom_histogram(aes(fill = ..count..)):http://docs.ggplot2.org/current/geom_histogram-40.png
— само выбирает шкалу, само делает легенду, само делает всё; ты просто добавил маппинг эстетики «цвет» на фичу данных.
Красиво дохуя, короче; очень быстро получается экспериментировать и смотреть разные-разные проекции данных, моделировать на ходу. Прям аж хочу реимплементнуть тот же интерфейс на js.
@komar ЭТО И ЕСТЬ считывание информации, ты тупой штоле?
@komar пёс твой гуманитарий
@komar не нужен
TL;DR треда
комар считает, что его безрациональные (rationale-less) требования, на которые всем похуй, на самом деле кому-то не похуй.
@komar и сколько этот твой «график мечты» на полгигабайте данных займёт в ширину? пару миллионов пикселей?..
агрегацию по периодам ggplot тоже умеет, и тоже декларативно; но я таким не занимался — разбирайся сам.
@komar охуенная шутка. В глаза долбишься? Результаты работы плоттера не замечаешь?
@komar ты не обосновал нужность, не предоставил rationale. Следовательно — не нужно.
@komar Спасибо!
@komar facepalm.pdf
карочи, ебись как хочешь со своими пикселями — у меня больше нет времени на этот тред.
@komar на хуец-то
imagemagick + bash
cast @lexszero
@ckorzhik обычно вполне норм, они там прикомпиливают всякие фортрановые хуйни для етих дел.
Важно только не лохануться с векторизацией; как и в матлабе/octave (как и в numpy, да как и в произвольном скриптоговне, тащемта), код на ручных циклах работает в разы медленнее, чем векторизированный.
Ну типа, вместо
будет существенно быстрее просто
X = c * Y + Z. // здесь надо понимать, как определены операции на массивахТо есть, вычисляющий код лущ писать в терминах свёрток, векторных сложений/умножений, матричных операций, и т.д. — чем в терминах индексов и циклов. Опять же, они вполне могут уже в своей свёртке воткнуть SIMD, задрочить кеш локалити, контролировать поинтер альясинг, и всё вот это ускоряющее говно. Это реально любого скриптоязыка касается.
@ckorzhik тащемта, считали и скользящую среднюю, и фильтр Калмана на ГИГАБАЙТАХ — вполне приемлемо было на R
@komar но у тебя требования как у бабы
@komar алсо, у Антонины тоже хуй
@kb да вот надо дудку дропнуть на время, да и написать взять
@krkm дропнул булки, теперь не раздвигаются, как починить?
@krkm дропнул тебе на рыло
@krkm не помогает. может ли проблема быть в геометрии швабры?
@kb на самом деле не только ради js // ради хаскеля
@kb во вымя