Pull to refresh

Comments 34

Это в каких российских вузах сейчас микроконтроллеры на физических лабах для студентов?
На физическом факультете Высшей школы экономики :)
Для физиков конечно отличная технология, вполне современно (y)
Сибирский государственный университет телекоммуникаций и информатики. На множестве кафедр. Сам лично разрабатывал и внедрял.
Как-то на самом деле не очень подробно раскрыта тема обработки данных :(
По своему опыту практики на ускорителе могу сказать, что пусть и не самый простой, но один из лучших пакетов для анализа и визуализации данных — ROOT от CERN. Набор возможностей просто колоссальный.
Спасибо за совет!
Буду стараться и дорабатывать:)
Когда приспичило лил данные с Ардуинки в Эксель через ком порт, а обратно команды управления, почти без потерь(строка раз в секунду, 1 — 2 строки терялись за 8 — 12 часов) и достаточно удобно, можно просто пририсовать любую аналитику и графики.
Хорошая идея!
Графики все-таки больше нравится строить в Python, но когда время поджимает, Эксель выручает.
Нужны были не только графики, а нужны были зависимости от действий и поведение датчиков во времени, эксперимент в общем провалился но без этой аналитики еще долго пытались-бы идти этим путем.
UFO just landed and posted this here
Совершенно согласна, многие люди умеют выполнять эксперимент аккуратно. Я, к сожалению, не обладаю этим качеством. В целом, мне кажется, обеспечение учеников хорошим оборудованием — хорошая тенденция в наше время. Это заранее позволяет подготовить студента к «реальной» научной работе. Бонусом идет экономия времени и сил:) Повторюсь — это мое субъективное мнение.
Я пробовала Origin, но отношения с этим ПО далеко не пошли, быстро переключилась на Python. Ни в коем случае не претендую на то, чтобы называть Python единственным хорошим средством для обработки данных, лишь делюсь своим опытом и своими предпочтениями:)
Все зависит от того, для чего график строится. Если для себя, это одно, если в издательство — другое. Поэтому одного инструмента никогда не будет. Для себя можно и эксель использовать, но с его помощью делать иллюстрацию в статью или доклад согласно требованиям издательства — это реально геморрой. Обычно издательство, исходя из требований к материалам и формату файла, само предлагает наиболее подходящий инструмент и даже шаблон-пример. При этом не исключаются и другие инструменты, но может оказаться так, что те, с которыми ты как-бы всех собак поел, принципиально не могут выдать требуемое, как бы не упирался. В таком случае проще и быстрее с нуля изучить инструмент и выполнит ь работу. Как говорится в известном мультике: "… лучше день потерять, потом за пять минут долететь...".
Я для себя во всех случаях использую gnuplot, который однажды освоил как раз по причине того, что ничем другим не получалось сделать иллюстрации, которые бы удовлетворили издательство.
Что я только не пробовал, потратил реально неделю на борьбу с тиками, шрифтами и прочими атрибутами, но получить результат, визуально и стилистически удовлетворяющий требованиям, так и не получилось. Однако, с gnuplot'ом все разрешилось менее, чем за час, включая освоение инструмента — выручил именно шаблон-пример, который уже содержал полностью все стилистическое от издательства, и мне пришлось возиться только с данными и подписями.

Python (Numpy+matplotlib) + Jupyter = идеальный ежедневный инструмент обработки и анализа данных, в том числе для совместной работы.

А вообще какое-то странное сравнение: Labview — это же для сбора данных и управления экспериментом, а совсем не для обработки. Gnuplot — в первую очередь для визуализации, а не для обработки. И только питон более или менее подходит под название статьи, хотя есть полно специализированных пакетов.
Мне приятно, что вы поддерживаете мое мнение по поводу Python:)
Ваше замечание касательно Labview действительно значимое. Labview умеет собирать данные и визуализировать их, но анализом приходится заниматься дополнительно, если это требуется.
Я привела пример обработки данных на Gnuplot, иногда (в ситуациях нехватки знаний языков программирования), мне кажется, это проще и быстрее, чем использовать Excel. Правда, это лишь мое личное мнение, мой опыт. Думаю, найдется мало людей с абсолютно схожими предпочтениями в способах обработки данных.
На самом деле, с питоном получается удобный воркфлоу. Например, я использую atom+hydrogen для питона, в нем куча удобных фич (почти как ide), хорошая интеграция с гит/гитхаб и при этом там же можно latex писать с подсветкой кода и т.п. Как итог, можно в одном окружении и репозитории иметь и заметки с описанием работы и уравнениями (в latex), и данные, и собственно код для их анализа. Очень рекомендую:)

А gnuplot подходит для совсем уж простой обработки… везде, где нужно что-то более сложное, статистика или какие-нибудь многопараметрические функции — питон выигрывает по всем показателям. При этом python+seaborn производит графики не хуже gnuplotа.
Большое спасибо за советы! Признаюсь, про редакторы не слышала, я думаю, вы мне очень упростили жизнь этой информацией:)
Не за что, надеюсь;) Для питона я долго пользовался IDE pycharm, но он тяжеловат, и ipython был ужасен. Не так давно открыл для себя atom и абсолютно по этому поводу счастлив, pycharm больше не запускал:) Как вариант, есть spyder, он идет по дефолту с anaconda (ее тоже рекомендую для научных целей) и заточен на научную разработку.
+1 к LabView. Это графическая среда программирования, ориентированная на автоматизацию эксперимента, а не на обработку данных.

Вообще да.


При этом некоторые задачи, скажем, image processing'а LabVIEW решеет быстрее Matlab'а. С учетом того, что последний оптимизирован для работы с матрицами, это довольно неожиданно.

UFO just landed and posted this here
Python конечно инструмент универсальный, как напишешь так и обработаешь, но требует навыков и наработок. Для собственно обработки и анализа данных могу порекомендовать MatLab.
Справедливости ради, Python c numpy/scipy делает то же, что Matlab, только бесплатно;)
Matlab удобнее разве что для совсем начала, чтобы без программирования — чисто через тулбоксы.

А у тебя есть опыт работы с сырыми данными в Mathematica? В последнее время слышал немало положительных отзывов, хотя по личному опыту — ужас-ужас.

Небольшой опыт есть, но не очень положительный тоже.
Я всю аналитику проверяю в mathematica, и тут все ок, а вот нужно было делать фиты и монте-карло, и там все как-то очень медленно: 100 запусков по 1000 семплов занимали больше суток расчета. Может, правда, это кривизна рук:)
Мне в целом не очень понятно, как в ней адекватно работать с написанием своих функций эффективно… после питона все выглядит как-то костыльно. Но опять же, я не задавался целью это все изучить подробно.
LabView нужно, когда в установке собрано 100500 разношерстных готовых приборов и датчиков. Все современные осциллографы, генераторы и даже некоторые породистые мультиметры работают с лабвью из коробки. Писать на питоне свой драйвер для каждого из них будет намного дольше, чем освоить птичью грамоту графического интерфейса.

Ну а в случае простой установки на самопальных приборах — гораздо удобнее написать свой простенький сбор данных, чем учить свои датчики общению с лабвью.
Все-таки стоит разделять этапы сбора данных и их обработки.
На этапе обработки уже лет 15 назад вовсю преподавателями рекомендовалось использовать автоматизацию расчетов, с тем же экселем, например. Максимум во время одной из первых лаб с большим числом данных заставляли прочуствовать всю глубину статистики и больших таблиц формата а4, дальше все, чем считаешь не волновало никого.
А вот с этапом сбора данных все менее однозначно. С одной стороны, автоматический сбор данных это быстро и эффектно, выглядит круто, и вообще современные приборы все под автоматизацией. Однако, если весь этот стенд, включая выбор датчиков, управляющего устройства и какое никакое программирование, студент собирает не сам, а берет готовый в лабе, то вся эта лаба практически ничем не отличается от нажатия кнопки в каком-нибудь симуляторе. Ручная же работа с базовыми измерительными приборами дает очень четкое понимание что вообще происходит. Наравне со старым парком приборов это одна из главных причин, что в предметах с железячными лабами до сих пор много работы вручную (если это не предмет, посвященный автоматизации, естественно).
P. S. А Labview это вообще для инопланетян, у меня на переписование в качестве саморазвития простенького алгоритма на 30 строк (правда, со вложенными циклами и ветвлением) ушло 3,5 дня.
Очень здорово, если в большинстве университетов используют Эксель. Я столкнулась с тем, что многие мои знакомые из разных вузов (МГУ, МИФИ) достаточно редко используют что-то помимо бумаги и ручки.
У нас (в ВШЭ) лабораторные проходили так: каждому студенту вручались отдельно платы, датчики, провода и т. д. и т. п., далее каждый (с помощью преподавателя или без) собирал все это дело, подключал и сам писал программу. Мне кажется, это достаточно хороший подход, который не уменьшит понимание происходящего.
Это крутой подход к лабам, без шуток. Но я так понимаю, к этому моменту уже должен быть приличный багаж по составлению измерительных стендов. И программировать уже надо уметь. Иначе все время уйдёт только на подготовку этого стенда. Сколько у вас вообще времени выделено на лабу целиком и на подготовку стенда?

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

UFO just landed and posted this here
Выше я комментировала похожее замечание:
Ваше замечание касательно Labview действительно значимое. Labview умеет собирать данные и визуализировать их, но анализом приходится заниматься дополнительно, если это требуется.

Как учёный физик(15 лет стаж) докину свои три капли:


  1. Сбор от инструментов, связка, первичная обработка и сохранение — лабвью без вариантов. Ну или одной софт инструмента, живущий по собственным законам..
  2. Обработка — тот же лабвью (мой выбор ибо мне лениво синтаксис учить) для сравнительно простых вещей или Матлаб для всего остального. К нему написана куча пакетов, анализ многомерных данных, статистика и тд. Как только у вас появляется больше одного измерения — все остальное нервно курит в углу, а Эксель ещё и тихонько навзрыд. Кто то использует математику, но это, имхо, изврат.
    2б. Простейшая обработка одномерных данных — Эксель и Origin. В ориджине удобно работать колонками, но просто адски неудобно ссылаться на индивидуальные ячейки — в итоге связка ориджин+эксель лучшая и быстрая.
    Также Ориджин хорошо работает с фитированием и "графической" обработкой.
  3. Построение всех видов двухмерных графиков — Ориджин без вариантов. Простой, удобный, красивый и настраиваемый. Куча темплейтов для различных журналов и тд.
    Уже Матлаб тут курит, а Эксель уже рыдает навзрыд, ибо понимает, что урод :)
  4. Трехмерные графики строить сложно везде. Частично возможно в ориджине, но вращение и настройка просто ужасные, в итоге самые удачные — разнесение по одной оси или яркостная диаграмма.

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

Большое спасибо за такой подробный и информативный комментарий! :)
Мне приятно, что вы поделились своим ценным опытом, теперь попробую освоить Origin (увы, с первого раза не пошло).
Люто плюсую Origin — он умеет строить абсолютно любые двумерные графики. А еще делать их сколь угодно красивыми (настраивается абсолютно все), экспортировать их во множество форматов, работать через GUI и командную строку — это не говоря о базовой обработке данных (фиты/статистика) и прочих мелких радостях жизни.

Главный минус — он не бесплатен, причем довольно сильно.
Sign up to leave a comment.

Articles