LINUX.ORG.RU

jupyter и matplotlib для «больших» векторов? Как не сливать Matlab-у?

 , , ,


0

4

Цель: применить jupyter/python/matplotlib/<ещё что-то?> к задаче радиотехники.

Дано: 3276799 комплексных числа. Необходимо визуально оценить спектр.

Вот такой тестовый код вешает (!!!) kernel в jupyter-е (попробовал на двух машинах):

%matplotlib inline

import numpy as np
import matplotlib.pyplot as plt

fig, axis = plt.subplots(nrows=1, figsize=(16, 8))

n = 3276799

t = np.arange(n)
x_t = np.random.random(n) + 1j * np.random.random(n) + np.sin(2 * np.pi * .05 * t)
x_t -= x_t.mean()
x_f = np.fft.fft(x_t)

axis.plot(np.abs(x_f))

Для сравнения вот такой matlab-овский код:

n = 3276799;
t = 1 : n;
x_t = rand(n, 1) + 1j * rand(n, 1) + sin(2 * pi * .05 * t');
x_t = x_t - mean(x_t);
x_f = fft(x_t);
plot(abs(x_f));

отрабатывает и отрисовывает график за доли секунды.

Раунд спора с научруком на тему Matlab vs Jupyter/python/matplotlib был эпично проигран! :'-(

Вопрос: что не так в python-ом коде? Как решить такую задачу в jupyter?

P.S. Только, пожалуйста, не надо говорить, что визуально оценивать 3М точек, это не по фэншую. Если matplotlib для этого не предназначен, то порекомендуйте альтернативу. Решать такую задачу можно и нужно и Matlab её решает успешно.

Я пробовал разное несколько лет назад. И все что я пробовал сливало Matlab-у.

Я сдался и купил персональную версию Matlab-а, и ни сколько об этом не жалею.

alexru ★★★★
()

Неудачное число точек (простое). FFTPACK, на котором базируются и numpy.fft.fft, и scipy.fftpack.fft, не любят простые числа точек. 3276800 взять не вариант?

TeopeTuK ★★★★
()
Последнее исправление: TeopeTuK (всего исправлений: 1)

визуально оценивать 3М точек, это не по фэншую
Решать такую задачу можно и нужно

Но это действительно так! Как проанализируешь на экране эти миллионы точек? У тебя на экране число пикселей такого порядка. Вместо scatter plot лучше уж использовать heatmap, иначе разницу в плотности не увидишь. В случае line plot всегда можно и нужно уменьшать количество звеньев.

По теме: матплотлиб по умолчанию рисует полностью всё, поэтому тормозит. Про ускорение построения графичков есть информация в документации. Хотя вот непонятно, что будет, если включить ускорялки, а потом сильно увеличить масштаб, наверное не покажутся скрытые ранее узлы. А так матплотлиб сам по себе знатный тормоз, да и рисует коряво (до последних версий не было более-менее надежного метода автоматически выровнять поля для составного графика с несколькими заголовками, сейчас хоть constrained-layout появился).

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

lu4nik ★★★
()
Ответ на: комментарий от TeopeTuK

OMG!!! Сейчас уже голова не варит, окончательно протестирую завтра утром, но, кажется, проблема действительно в fft, а не в matplotlib-е!!! Если так, то огромное Вам спасибо за решение!!! У меня даже мысли не возникло дебажить и подозревать fft! Откуда?! Откуда простому человеку было знать про нелюбовь fft к простым числам..... O_O

omegatype ★★★
() автор топика

Но ведь твой код нифига не падает. Тестировал с jupyter и matplotlib из анаконды

%%time
%matplotlib inline
import numpy as np
import matplotlib.pyplot as plt

fig, axis = plt.subplots(nrows=1, figsize=(16, 8))
n = 3276799
t = np.arange(n)
x_t = np.random.random(n) + 1j * np.random.random(n) + np.sin(2 * np.pi * .05 * t)
x_t -= x_t.mean()
x_f = np.fft.fft(x_t)
axis.plot(np.abs(x_f))
CPU times: user 2.68 s, sys: 516 ms, total: 3.2 s
Wall time: 5.14 s
anonymous
()
Ответ на: комментарий от omegatype

Да, TeopeTuK абсолютно прав. На моей машине с n = 3276799 больше двух минут крутился, а с n = 3276800 за 0.62 с прошел (это без построения графика). Кстати, про эту особенность сказано в документации к scipy.fftpack.fft: «This function is most efficient when n is a power of two, and least efficient when n is prime.»

lu4nik ★★★
()
Ответ на: комментарий от omegatype

1. Чаще всего FFT делают рекурсивным алгоритмом Кули-Тьюки. С его помощью FFT сигнала длиной N = N1*N2 сводится к FFT более коротких сигналов длиной N1 и N2. Чем дольше можно так разбивать число на множители, тем быстрее будет работать. N = 2^k — наилучший случай, N = простое — наихудший. Это вам, как радиотехнику, знать полезно.

2. Есть и другие алгоритмы, в том числе для простых N. Вполне может быть, что numpy их делать не умеет, а Matlab — умеет. Вы можете поискать другую библиотеку специально для FFT.

3. Элементарный профайлинг кода путём удаления (комментирования) тех или иных строчек делать всё равно нужно уметь. Это чтобы вы не приходили на форум со скриптом на пять строчек, не зная, какая именно из них тормозит.

Crocodoom ★★★★★
()
Последнее исправление: Crocodoom (всего исправлений: 1)
Ответ на: комментарий от Crocodoom

Я не говорил, что numpy НЕ будет сливать матлабу (сам сравнить не могу, в досягаемости матлаба нет). Опять же, совсем не факт, что матлаб использует FFTPACK с его особенностями. А про спор ТСа — пустое всё это дело, здесь в любом случае компромисс получается, либо типа опенсорс питона с нумпаем (и использование языка общего назначения), либо производительность и либы закрытого матлаба (ну и наличие денег в кошельке).

lu4nik ★★★
()
Ответ на: комментарий от Crocodoom

Надо только помнить, что pyfftw под GPL, в отличие от numpy/scipy. А так да, будет точно быстрее.

lu4nik ★★★
()
Ответ на: комментарий от Crocodoom

1. Да, вы совершенно правы во всём, однако, если мы говорим о радиотехнике, в которой matlab распространён достаточно широко, то говорить «наиболее часто fft так-то и так-то, хотя в matlab-е не так», ну... не совсем корректно.
2. Ну, _теперь_-то понятно.
3. Ну если вы читали тред, то не ясно, откуда вы сделали вывод, что я _не умею_ делать профилирование. В этом примере я его умышленно не делал (и да, прилагаемый фрагмент кода, это уже результат дебага довольно большого скрипта).

Но все-равно благодарю за пояснение!

omegatype ★★★
() автор топика
Ответ на: комментарий от lu4nik

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

omegatype ★★★
() автор топика
Ответ на: комментарий от omegatype

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

lu4nik ★★★
()
Ответ на: комментарий от Deleted

вангую направление в сторону магистратуры.

t184256 ★★★★★
()
Ответ на: комментарий от Mike_RM

Чем не устроил octave?

Значительная часть того, что я делаю включает в себя визуальное исследование графиков и octave для этого использует (или использовал) gnuplot или похожую поделку. И этого достаточно, чтобы мне не тратить нервы.

Рисовалка графиков в Matlab не идеальна, но она самое лучшее из того, что я пробовал. По скорости и удобству навигации.

alexru ★★★★
()
Ответ на: комментарий от omegatype

Откуда простому человеку было знать про нелюбовь fft к простым числам

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

curufinwe ★★★★★
()
Ответ на: комментарий от Crocodoom

ну насчет прям уж залетает

позвольте не согласиться. У меня массивы типа 4k x 4k, т.е. 16М точек и нужно делать большое количество преобразований (десятки тысяч). Приходится делать fortran+fftw+mpi. Если на кластере и ~200 ядер, то минут на 20 делов. Если комп попроще (20 ядер), то уже часы :)

sshestov
()
Ответ на: ну насчет прям уж залетает от sshestov

позвольте не согласиться. У меня массивы типа 4k x 4k, т.е. 16М точек и нужно делать большое количество преобразований (десятки тысяч). Приходится делать fortran+fftw+mpi. Если на кластере и ~200 ядер, то минут на 20 делов. Если комп попроще (20 ядер), то уже часы :)

Попробуйте использовать GPU. Карточка типа GTX 1070 на вашем массиве в 16М будет выдавать около 10 FFT в секунду, то есть десять тысяч преобразований за полчаса — это как ваш кластер на 200 ядер, только существенно дешевле.

Crocodoom ★★★★★
()
Последнее исправление: Crocodoom (всего исправлений: 1)
Ответ на: комментарий от Crocodoom

а как её использовать то?

Библиотека есть какая, или в какую сторону копать?

Кодов-числодробилок всяких дофига, только их же нужно еще как-то на ГПУ перевсти...

sshestov
()
Ответ на: комментарий от Crocodoom

Карточка типа GTX 1070 на вашем массиве в 16М будет выдавать около 10 FFT в секунду,..

С float легко перегнать процессор за ту же цену. Но с double да ещё и nvidia?

gag ★★★★★
()
Ответ на: а как её использовать то? от sshestov

CUDA Toolkit и библиотека cuFFT.

А ещё у библиотеки есть интерфейс, совместимый с FFTW, что должно сильно облегчить портирование

NVIDIA provides FFTW3 interfaces to the cuFFT library. This allows applications using FFTW to use NVIDIA GPUs with minimal modifications to program source code.

Документация и прочее по адресу https://developer.nvidia.com/cufft

Crocodoom ★★★★★
()
Ответ на: комментарий от gag

С float легко перегнать процессор за ту же цену. Но с double да ещё и nvidia?

В потребительском сегменте карточек вы правы, ну а вообще есть карточки Tesla.

Crocodoom ★★★★★
()
4 июля 2019 г.
Ответ на: комментарий от alexru

Я сдался и купил персональную версию Matlab-а

А профит от покупки Toolbox’ов имеется, или можно обойтись и без них (сфера интересов совпадает с названиями нескольких тулбоксов)?

the_real_kinik ★★
()
Ответ на: комментарий от the_real_kinik

А профит от покупки Toolbox’ов имеется, или можно обойтись и без них (сфера интересов совпадает с названиями нескольких тулбоксов)?

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

Лично мне было достаточно Signal Processing Toolbox, но я знал об этом по опыту с пиратской версии.

alexru ★★★★
()
Ответ на: комментарий от alexru

но я знал об этом по опыту с пиратской версии

Точно, можно же пиратку скачать для ознакомления. Хотя, может мне и Octave хватит.

the_real_kinik ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.