LINUX.ORG.RU

Python в научных вычислениях

 ,


29

5

Доктор физико-математических наук Андрей Грозин прочитал цикл лекций об использовании Python в целях ликвидации безграмотности среди студентов, аспирантов и прочих. Презентации были приготовлены для представления в среде Jupyter. Видеоматериалы лекций с разрешения лектора доступны под свободной лицензией CC-BY-SA. Исходные видеофайлы будут выложены в торрентах позже.

Первая и третья лекция записаны не были. Остальные записаны, как записаны. Лекционные материалы выложены на страничке лектора.

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

  • Лекция 1. Jupiter. Числа. Строки. Списки. (html, ipynb)
  • Лекция 2. Кортежи. Множества. Словари. Функции.(html, YouTube, ipynb)
  • Лекция 3. Объектно-ориентированное программирование. Исключения. (html, ipynb)
  • Лекция 4. Модули. Ввод-вывод, файлы, директории. (html, YouTube, ipynb)
  • Лекция 5. numpy. Одномерные массивы. Операции над одномерными массивами. 2-мерные массивы. Линейная алгебра. Преобразование Фурье. Интегрирование. Дифференциальные уравнения.(html, YouTube, ipynb)
  • Лекция 6. matplotlib. Логарифмический масштаб. Полярные координаты. Экпериментальные данные. Гистограмма. Контурные графики. Images (пиксельные картинки). Трёхмерная линия. Поверхности. (html, YouTube, ipynb)
  • Лекция 7. SymPy (html, ipynb). Многочлены и рациональные функции. Элементарные функции. Структура выражений. Решение уравнений. Ряды. Производные. Интегралы. Суммирование рядов. Пределы. Дифференциальные уравнения. Линейная алгебра. Собственные значения и векторы. Нормальная жорданова форма. Графики. (html, YouTube, ipynb)
  • Лекция 8. iminuit (html, ipynb). cython. Функции. Интерфейс к библиотеке на C. Структуры. cdef классы. Интерфейс к библиотеке на C. (html, YouTube, ipynb)
  • Лекция 9. Интерфейс к библиотеке на C (продолжение). pandas (html, ipynb) — пакет для статистической обработки данных. Series. DataFrame. sh — простой вызов shell-комманд. rpyc — remote python call. pyroot — интерфейс к пакету анализа данных в том числе и данных очень большого объёма ROOT. (YouTube)

>>> YouTube

★★★★★

Проверено: splinter ()
Последнее исправление: Psych218 (всего исправлений: 5)

Ответ на: комментарий от anonymous

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

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

CUDA

Проприетарен, производительность вычислений с типом double, а именно этот тип необходим в подавляющем большинстве численных задач, где-то в 30 раз хуже производительности с типом float. Так что требуется спецоборудование от NVidia, обыкновенные массовые видеокарты дают на double примерно ту же производительность что и современные многоядерные обычные CPU.

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

Это да, но чтобы заиметь домашний суперкалькулятор за разумные деньги здесь и сейчас - это решение.

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

И да есть теслы с двойной точностью.

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

Aparapi тогда уж.

Ну и да, выбор оберток под cuda/opencl под яву приличный.

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

Зарезанные даблы это проблема железа и маркетинга. ЕМНИП у потребительских амдшек в этом плане все лучше, чем у потребительских нвидий - надо же как-то теслы продавать.

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

но чтобы заиметь домашний суперкалькулятор за разумные деньги здесь и сейчас - это решение.

Так вот и нет, за разумные деньги решением будет обыкновенный многоядерный CPU, поскольку спецкарты от NVidia дающие значительное преимущество перед таким CPU с типом double стоят на порядок больше этого самого обычного многоядерного CPU, а приемлемые по цене массовые видеокарты от NVidia дают примерно ту же производительность с типом double что и CPU, поэтому и удобнее выбрать CPU.

anonymous
()
Ответ на: комментарий от tailgunner

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

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

Те, кого я опрашивал на предмет реальных использований суперкалькуляторов в ближней окрестности, используют теслы, соответственно там CUDA. Nvidia с этой темой просто стартовала раньше и пока её догоняют.

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

Есть класс задач (диффуры численно решать, например), где требуется большое число ядер и на сегодня 1000 ядер теслы средней паршивости делает любой многоядерный CPU сравнимой стоимости (разрыв меньше чем в пару порядков, но где-то близко) при правильной (sic!) программной реализации алгоритмов естественно.

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

wxMaxima

Бя

Лучше взять emacs + imaxima, наярить slime:

(require 'asdf)

(progn
  (flet ((%gpath (p)
           (push (merge-pathnames p
                                  *default-pathname-defaults*)
                 asdf:*central-registry*))) 
    (let ((*default-pathname-defaults*
            #P"/usr/share/sbcl-source/contrib/"))
      (map nil #'%gpath
           '(#P"sb-cltl2/"
             #P"sb-introspect/")))
    (let ((*default-pathname-defaults* (user-homedir-pathname)))
      (%gpath #P".emacs.d/site-lisp/slime/")
      (asdf:initialize-output-translations
       `(:output-translations (t ,(merge-pathnames #P".cache/maxima/lisp/"))
         :ignore-inherited-configuration)))) 

  (asdf:oos 'asdf:load-op :swank))

(swank:create-server :dont-close nil
                     :port 23146)
 
(to-maxima)

Далее M-x slime-connect <RET> 127.0.0.1 <RET> 23146 <RET>

ados ★★★★★
()

А потом после вот таких лекций появляются CGH на жабе (на жабе, едрить! CGH!!!!) или алгоритмы CAM на пистоне.

Не, понятно, что на разок для теоретика сойдёт, чтоб за 3 часа работы скрипта таки получить proof-of-concept, но вообще за такое, конечно, надо розгами пороть. Да и вообще - аццкий матан теоретик осилил, а какой-нибудь ЯП c нормальной скоростью работы он не может. Сразу сомнения появляются в способности теоретика и в матан.

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

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

теслы средней паршивости делает любой многоядерный CPU сравнимой стоимости

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

anonymous
()
Ответ на: комментарий от Stanson

Правильный ответ важнее быстрого. Взяв «какой-нибудь ЯП c нормальной скоростью работы» вероятность напороться на гейзенбаги и прочие прелести повышается в разы.

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

Вообще-то речь была про это:

заиметь домашний суперкалькулятор за разумные деньги здесь и сейчас

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

Бюджетные же видеокарты, примерно одной ценовой категории с многоядерными CPU, не имеют преимущества в счёте перед CPU на типе double,...

Писал свою очень кривую реализацию БПФ на OpenCL, она работала на нормальной игровой видеокарте чуть быстрее, чем fftw на четырехъядерном процессоре. Только моя программа использовала double-double арифметику. Что я делаю не так?

Zeta_Gundam
()
Ответ на: комментарий от Stanson

Ты в курсе, что есть numpy? Что кроме аццкого матана есть довольно простые и стандартные задачи, которые реализованы в написанных на C и оптимизированных модулях питона? О каких проблемах со скоростью работы идет речь? Конечно если FFT например напрямую на чистом питоне сделать, оно будет тормозить. Но так же никто не делает.

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

Во-первых, непонятно что вы сравниваете? БПФ с ДПФ? Ну так на то БПФ и называется быстрым что требует меньшего числа операций.

Во-вторых, выше утверждалось что восьмиядерный процессор должен быть по производительности примерно на одном уровне с нормальной игровой картой на типе double, а поскольку они из одного ценового диапазона то выбирать GPU вместо CPU нет смысла.

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

Во-первых, непонятно что вы сравниваете? БПФ с ДПФ?

Скажи что ты шутишь. Какой алгоритм кроме БПФ имеет смысл обсуждать?

Во-вторых, выше утверждалось что восьмиядерный процессор

Это AMD теперь выпускает восьмиядерники? Я бы купил устройство с 16 нормальными ядрами по цене видеокарты, может быть и OpenCL не пришлось бы учить.

Zeta_Gundam
()
Ответ на: комментарий от hotpil

Приятель писал с использованем Numpy\scipy?

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

Правильный ответ важнее быстрого.

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

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

А можно узнать альтернативы, которые не сорта говна?

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

Ты в курсе, что есть numpy? Что кроме аццкого матана есть довольно простые и стандартные задачи, которые реализованы в написанных на C и оптимизированных модулях питона?

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

О каких проблемах со скоростью работы идет речь? Конечно если FFT например напрямую на чистом питоне сделать, оно будет тормозить.

А представь себе задачку раз так в 100500 сложнее чем FFT. И библиотечек кем-то написанных нет и быть не может, потому как никто таких задач ещё не решал.

Но так же никто не делает.

Именно так и делают. Вот, например: http://corticalcafe.com/prog_CGHmaker.htm

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

Правильный ответ важнее быстрого.

Каким боком питон к получению правильного ответа? Какие ваши доказательства? Понимаю еще Haskell или Idris.

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

Конечно если FFT например напрямую на чистом питоне сделать, оно будет тормозить. Но так же никто не делает.

Но так же никто не делает.

Именно так и делают. Вот, например: http://corticalcafe.com/prog_CGHmaker.htm

Тебя спрашивали о Python, а ты привел исходники на Яве. Про JIT слышал?

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

Каким боком питон к получению правильного ответа? Какие ваши доказательства? Понимаю еще Haskell или Idris.

А что, только программы на Haskell и Idris могут давать правильный ответ? %)

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

Тебя спрашивали о Python, а ты привел исходники на Яве. Про JIT слышал?

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

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

Пара килобаксов для суперкалькулятора это разве не оно?

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

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

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

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

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

Тебя спрашивали о Python, а ты привел исходники на Яве. Про JIT слышал?

Какая нафиг разница?

А, окей.

неспособного написать на сях шуструю библиотечку

Ты не поверишь, но люди избегают писать на Си, потому что он убогий и устаревший, а не потому, что на что-то там неспособны.

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

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

Ну то есть в этом разницы между Haskell и Python нет.

Не благодари

Да я и не собирался.

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

Фи, так приземленно думать. «покодил»-«запустил»-«прослезился» — действительно, это для любого языка справедливо. Зачем же выбирать лучший? Хей, бери тот, у кого батареек больше!

Подходы к программированию можно разделить на операционный и аксиоматический. По мне, второй подход гораздо эффективнее, и больше ложится на функциональные языки. А вообще, отсылаю к Дейкстре как авторитету: http://www.beroal.in.ua/article/dijkstra/ewd1012.html

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

Ты не поверишь, но люди избегают писать на Си, потому что он убогий и устаревший, а не потому, что на что-то там неспособны.

Ну да, то-то на убогом и устаревшем написано 99% всего софта, а на современных и развитых - аж полторы поделки. Отличненько, чо.

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

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

Ну да, то-то на убогом и устаревшем написано 99% всего софта

Давай 146% - тоже чушь, но хоть с намеком на юмор.

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

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

Ну то есть в этом разницы между Haskell и Python нет.

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

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

«Вероятность, отличная от нуля» может быть на 0.01, так и 0.99, и если у двух языков они разные, то отсюда никоим образом не следуют отсутствие разницы

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

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

А тебе надо научиться передергивать изящнее - это нужный и полезный навык для программиста на Haskell.

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

На чём там пистон c жабой и прочими «современными языками» написаны? Ась?

У меня сейчас запущены Eclipse, Firefox и Claws. На Си из них написан только Claws, так что не рассказывай мне о 99%.

И кстати, Java VM написана на Си++

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

Фи, так приземленно думать. «покодил»-«запустил»-«прослезился» — действительно, это для любого языка справедливо. Зачем же выбирать лучший? Хей, бери тот, у кого батареек больше!

Впервые наблюдаю столь продолжительное бомболейо...

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от tailgunner

Про вероятности там не говорилось, да ты и был достаточно осторожен, чтобы не называйть чисел.

Да, я проявил осторожность, а вот ты нет — сделав из моего посыла вывод о равнозначности любых двух языков (что заведомо неверно), а потом подставил вместо них Haskell и Python. Таким приблизительно образом могла выглядеть логическая цепочка, но, возможно, что ты не строил логически строгую цепочку. В любом случае, не хочется продолжать этот спор и лезть в бутылку. Тем более, я не считаю Haskell лучше Python, это дело вкуса. Надеюсь, не обидел.

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

я проявил осторожность, а вот ты нет

Да неужели? Посмотрим:

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

Ну то есть в этом разницы между Haskell и Python нет.

Я выполню текстовую подстановку, если ты не можешь: «Программа и на Python, и на Haskell может дать правильный ответ, и в этом разницы между Python и Haskell нет». ХЗ, с какой радости ты стал уличать меня в незнании ТВ.

Надеюсь, не обидел.

Нет, удивил.

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

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

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

Вот блин, совсем фигню я написал. Пошел убиваться головой апстену, или что сейчас модно?

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

А что, нынче С++ перестал быть языком компилируемым в команды процессора упакованные в executable формат целевой системы и стал жрать память и процессор как не в себя всякими лишними прослойками и костылями для исправления кривизны рук программиста? А вот фортран ещё есть, например. Или ObjC какой.

И, кстати, что интересно, из списка «Eclipse, Firefox и Claws» самый тормозной (с точки зрения интерфейса) это Eclipse, по понятным причинам, потом идёт Firefox, из-за сраного XUL, а самый быстрый внезапно Claws.

Даже в такой, казалось бы несложной вещи как логика работы гуя (даже не сам гуй, в смысле отрисовки примитивов, заметь), все эти «современные и удобные» резко сливают компилируемым языкам без всяких сраных JIT'ов и прочих vm.

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

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

А что, нынче С++ перестал быть [...]

Си++ перестал быть убогим устаревшим Си.

а самый быстрый внезапно Claws.

И самый убогий. Если бы у меня была более-менее интенсивная переписка, я бы давно свалил... да на тот же Thunderbird.

Ну и Eclipse - это типа шутка такая, выдавать его за софт?

Назови мне IDE для Си++, которая лучше Eclipse CDT.

Эту хрень хоть один человек на Земле станет использовать по собственной воле, а не по принуждению?

Зависит от уровня антижабина в крови.

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

Си++ перестал быть убогим устаревшим Си.

И конечно же там int a = b + c преврашается в нечто иное, нежели в сях? И вызовы функций там, видимо, внезапно обросли тоннами оверхеда вместо обычного call целевого процессора?

Назови мне IDE для Си++, которая лучше Eclipse CDT.

Да хоть какой-нибудь KDevelop. Тупо потому что не тормозит.

Зависит от уровня антижабина в крови.

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

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

И конечно же там int a = b + c преврашается в нечто иное, нежели в сях?

Эээ... это такой автотроллинг? Просто для протокола: в Си++ это очень сильно зависит от типов a и b, и может включать в себя хоть матричные операции,

Назови мне IDE для Си++, которая лучше Eclipse CDT.

Да хоть какой-нибудь KDevelop.

Те версии KDevelop, которые я пробовал, гораздо хуже понимают и Си, и Си++ (и не умеют в Python, ага %)).

Тупо потому что не тормозит.

Ну да, только тянет за собой KDE.

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

Зависит от исходных условий.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.