Кривые в Origin

[guliver2258]

Уважаемые коллеги, прошу вашей помощи.

Есть 2 ЭСП. Один записан с шагом 1 нм, другой с шагом 2 нм.
Необходимо, чтобы обе кривые одновременно и без смещений отображались в одной системе координат.
Как это сделать в Origin при отличающемся в 2 раза количестве точек?

[Гесс]

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

[guliver2258]

Я полагаю, что в экселе Вы бы не стали это делать руками (при условии что точек, допустим, 200).

Подскажите, пожалуйста, как можно автоматизировать описанный Вами процесс.

[Гесс]

Гм. Я с кодом дружу плохо, поэтому в совсем крайнем случае и при условии что операция одноразовая - то может и руками. Займет то минут 5, а код писать...
Но вообще можно попробовать скажем скопировать столбец цифр в ноутпад++, копировать переход между строками (выделить "все" между последней цифрой в строке и первой цифрой следующей строки), вставить в "найти и заменить" и заменить этот переход на 2 таких же перехода. По идее должно вставить пустые строки.
Ну а потом обратно копи-пейст в Эксель-ориджин.

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

[hellmint]

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

[guliver2258]

Да, действительно вариантов решения много:)
Спасибо большое за интересные идеи!

Мне тут один человек объяснил как работать со слоями в Origin.
Думаю, стоит попробовать сделать задуманное с помощью них.

[VTur]

Я полагаю, что в экселе Вы бы не стали это делать руками (при условии что точек, допустим, 200).

Подскажите, пожалуйста, как можно автоматизировать описанный Вами процесс.

Копируете этот столбец в ВОРД, выделяете, просите заменить знак абзаца на комбинацию "знак абзаца 0 знак абзаца".
Вставляете взад в Орджин

[ Post made via Android ]

[bf109xxl]

Как это сделать в Origin при отличающемся в 2 раза количестве точек?

1. Задать две разных колонки Х-ов - для каждой колонки Y свой. Лучше всего помещать данные (значения Y) в разные таблицы или разные листы (sheets), но можно совместить и в одной..
2. Поместить обе колонки Y-ков в одну таблицу (точнее, в один sheet) и задать для кажой из них соответствующий sampling interval.

esp_data.jpg

[MONSTA]

1. Задать две разных колонки Х-ов - для каждой колонки Y свой.

+100500! Только надо учитывать, что Origin не любит графиков типа ХY+Х₁Y₁, и его надо специально заставить работать с такими графиками. Без этого, "по умолчанию", не пройдет. Для упоминавшегося тут Экселя все несколько проще, если поставить на компьютер DPlot Jr. Это - фактически, абсолютно бесплатное средство для разработчиков программ, которые хотят в них построить график по имеющимся данным. Бесплатное, поскольку оно является урезанной версией коммерческой программы DPlot тех же разработчиков, и фактически идет в качестве "демо-версии" с урезанным функционалом, но зато с неограниченным сроком использования. Очень умная маркетинговая политика. Кроме того, DPlot Jr ставит свой плагин в Эксель (причем, Вы должны ему это разрешить при установке!), после чего возникает возможность строить графики по данным листа Эксель в DPlot Jr. Что горячо всем рекомендую. Ибо вид конечных графиков можно довести почти до совершенства, в отличие от стандартных графиков Экселя, словно выбитых зубилом древнеегипетского раба над входом в гробницу Тутанхамона. Не говоря уже о том, что попытка поменять начало отсчета в этих стандартных графиках часто приводит к меткам на оси с безумными дробными числами, а вот DPlot Jr начисто лишен этого недостатка. Я уже не говорю про то, что ситуации типа ХY+Х₁Y₁ он сечет почти на лету (надо это просто выбрать из возможного типа графиков), и принудительно вправлять ему мозги нет оснований.

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

Должен сказать, что DPlot Jr сидит поверх Ёкселя-мокселя. А он и сам себя иногда с трудом понимает. Ну и при работе с большими массивами данных, когда один икс и куча игреков, то и дело начинает сходить с панталыку. Начинает читать независимые данные не в столбцах, а в строках. И выворачивает все данные в нечто совсем непригодное. Там при построении графиков Ёкселя есть вопросы, смотреть ли по строкам или по столбцам, для поиска независимой переменной. Вопросы есть, ответа нет: если он, гад, решил, что надо смотреть по строкам, тор переубедить невозможно! Соответственно, при случившемся мозговом запоре, Эксель такую же бодягу он передаст и в DPlot Jr, и тот ничего нормального не построит.

[bf109xxl]

+100500! Только надо учитывать, что Origin не любит графиков типа ХY+Х₁Y₁, и его надо специально заставить работать с такими графиками.

У меня на рабочем компе хоть и не самая последняя версия - 9.0SR2, но там все прекрасно работает:

doublexgraph.jpg

Хотя, безусловно, использование нескольких X-датасетов в одном листе таблицы (sheet) является для Origin-а, скажем так, неоптимальным и неорганичным. Красивее было бы делать в разных листах (sheet-ах), но работа с листами (в первую очередь - доступ к данным) в Ориджине сделана настолько криво и хаотично - по крайней мере, по версию 9.0 - что потом неудобно писать скрипты. Почему нельзя было сделать прямой доступ (с возможностью записи туда) к ячейке вида [book]sheet!col(colname)[index], а обязательно городить огород с range-переменными - не понимаю. Или доступ вида book_column@sheet_nr[index] - там, блин, тоже достали правой пяткой левое ухо с нумерацией листов.
Поэтому если речь идет о нескольких датасетах (2-5), то лучше, ИМХО, делать в отдельных таблицах (book).

[Гесс]

Там при построении графиков Ёкселя есть вопросы, смотреть ли по строкам или по столбцам, для поиска независимой переменной. Вопросы есть, ответа нет: если он, гад, решил, что надо смотреть по строкам, тор переубедить невозможно! Соответственно, при случившемся мозговом запоре, Эксель такую же бодягу он передаст и в DPlot Jr, и тот ничего нормального не построит.

Насчет DPlot Jr незнаю а с Экселем всегда можно договориться.
Выделяем данные в одной строке или столбце, смотря что нам надо. Говорим "построить график". Получаем график где по ординате игреки, а по абсциссе отложены 1-Н где Н число ячеек. Клацаем по графику, говорим "Select data", добавляем второй набор данных, третий, пятый десятый. Заменяем 1-Н на нужные нам иксы, можно раздельно для каждого графика.
Внешний вид у Экселя может и не фееричен, но красота ориджина (в моем случае не такая и красота) по моему скромному мнению не окупает количества церебрального секса для построения в нем графиков. Я Ориджин начинал два раза, оба раза делал по нескольку десятков графиков для презентации и оба раза зареклася к нему возвращаться. Собственно этим постом я наверное заложил основу очередному холивару "Эксель vs Origin vs gnuplot vs чтонибудь еще"

[bf109xxl]

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

Выражу категорическое несогласие. Во-первых, НИКАКОГО "секса" с построением графиков в Ориджине нет. От слова "вообще". Во-вторых, Ориджин предоставляет куда более развитые средства и визуализации, и обработки данных. То, что легко и просто делается в Ориджине, в Ёкселе либо делается методом "вырываем гланды через задний проход", либо не делается вообще. Ну, навскидку: многослойные графики с врезками, множественные разрывы координатных осей, всякие там специфические статистические диаграммы (с неравномерным шкалированием осей) и т.д., и т.п.

Я Ориджин начинал два раза, оба раза делал по нескольку десятков графиков для презентации и оба раза зареклася к нему возвращаться. Собственно этим постом я наверное заложил основу очередному холивару "Эксель vs Origin vs gnuplot vs чтонибудь еще"

Мне просто интересно, что у Вас вызвало вообще затруднения-то? А то я юзаю Ориджин с версии 2.8 и как-то не понимаю, что там такого сложного. Смею абсолютно уверенно утверждать, что в настоящий момент по возможностям визуализации и обработки данных для _НАУЧНЫХ_ задач Ёксель с Ориджином сравнивать просто смешно. И обычно коллеги после того, как я им показывал КАК и ЧТО можно делать в Ориджине, постепенно забрасывали Ёксель. При этом я очень хорошо знаю слабые стороны Ориджина и могу предметно покритиковать разработчиков за их шараханья и недоведение до ума нативного скриптового языка. Тем не менее, все эти недостатки никак не умаляют мощных достоинств Ориджина. Ёксель - это весьма мощная программа со многими достоинствами, но... идеологически эта программа плохо заточена под научные задачи, начиная со слишком фривольного представления данных. Да, я знаю, что на VB можно запрограммировать все, что угодно, но мне не хочется тратить время на всякую мелкую рутину, которая реализована в Ориджине коротенькой командой. Возможности визуализации же у Екселя слишком куцые, они могут удовлетворить лишь невзыскательные требования. Несомненно, что для Ёкселя существуют всякие "костыли" в виде третьесторонних аддонов, но это паллиатив, а не решение проблем. Единственная причина не пользовать Ориджин - это его цена, и этот аргУмент я, как раз, принимаю на полном серьезе, считая его во многих случаях достаточным. Далеко не всем нужны сложные графики, вейвлеты, фурье и т.п.

Ориджин - это, в первую очередь, СРЕДА ПРОГРАММИРОВАНИЯ задач визуализации и обработки данных. LabTalk позволяет писать ОЧЕНЬ компактные скрипты для СЛОЖНОЙ визуализации и обработки данных, колбасить такое же в Ёкселе на VB - нафиг-нафиг, "плавали, знаем!" ©.

Да, и еще. Я не буду спорить, если кто-то будет утверждать, что СигмаПлот или IgorPro - не хуже Ориджина. А в чем-то, может, и лучше. Я соглашусь. Но готов поспорить, что объем скрипта для одной и той же задачи будет гораздо компактнее все равно в Origin-е.

[Гесс]

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

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

Мне просто интересно, что у Вас вызвало вообще затруднения-то? А то я юзаю Ориджин с версии 2.8 и как-то не понимаю, что там такого сложного. Смею абсолютно уверенно утверждать, что в настоящий момент по возможностям визуализации и обработки данных для _НАУЧНЫХ_ задач Ёксель с Ориджином сравнивать просто смешно.

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

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

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

[bf109xxl]

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

Я тоже не физик, но мне неоднократно требовалось - именно как химику-аналитику.

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

??? Не понял. В чем там проблема? Щелкнуть правой кнопкой мыши на свободном поле таблицы и выбрать Add New Column? Или нажать Ctrl-D? Замечу, что написать в окне скрипта wks.addCol(ColName) мне будет, пожалуй, уже быстрее, чем кликать мышью. В чем конкретно проблема с форматированием графиков? Все параметры тоже доступны путем кликанья мышкой.

Фривольное представление данных - непонял, что имеется в виду?

То, что в Екселе не задается жестко тип ячейки. В любую ячейку можно поместить любые данные. В Ориджине к представлению данных относятся гораздо строже: тип данных в колонке един (допускается смешанный тип Text&Numeric, что лично я считаю ненужным атавизмом, противоречащим ориджиновской идеологии). Это резко упрощает обработку - можно исключить цикл "пробега" по строкам в колонке. Например, для таблицы Book1 c колонками A и B Book1_B=Book1_B*2. И все.

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

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

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

Пожалуйста, типичный пример. У меня есть куча хроматограмм (или любых иных времяразрешенных сигналов, или спектров - масс-, электронных и т.п.). Я хочу скроллить весь набор таких сигналов - т.е., смотреть каждый датасет на графике с возможностью _быстрого_ масштабирования по обеим осям, а по оси Х еще делать отдельную прокрутку. В Ориджине я сделал "заготовку" когда-то за полдня и пользуюсь с тех пор уже несколько лет, лишь указывая требуемую template при создании графика. Скрипты для кнопок на графике (использовались стандартные программируемые управляющие элементы OriginPro) занимают порядка 5-10 коротеньких строчек. Попробуйте сделать такое же в Ёкселе.
Пакетная (автоматизированная) обработка данных в Ориджине тоже проще. Например, у меня за эксперимент получается порядка 20-30 ASCII файлов с прибора (конкретно в моем случае - МС высокого разрешения), и возможности экспорта приборного софта ограничены - нельзя экспортировать так, как хотелось бы. А данные нужно статистически обработать. В результате пишется скрипт на 20-30 опять же коротеньких строчек внутри замечательного оператора doc -ef W {...} (обработка всех таблиц в текущей директории проекта), и вуаля - кривовато импортированные данные перенарезаны в требуемом виде, позволяющем делать быструю "поколоночную" статобработку, которая тоже задается коротким скриптиком. Спорю, что в Ёкселе автоматизировать процесс будет гораздо сложнее, хотя для одного конкретного файла - возможно! - сделать вручную в Ёкселе будет и проще, например, с использованием какого-нибудь smart fill. Когда я показал коллегам, что небольшенький скрипт делает за секунду то, что они вручную колбасят полдня, многие из них изъявили желание изучить LabTalk. Как-то так.

[Гесс]

Возможно. На вкус и цвет фломастеры разные. Половина из описанного вами мне никогда не требовалось поэтому проблемы как бы и не было. Возможно посети я когда нибудь курсы ориджина - я бы его и использовал. А самомучение - ну вот когда задачу впринципе нельзя будет впихнуть в эксель, даже лопатой через жопу за день клацания (либо будут выставлены требования "не в Экселе", которые становятся счас все популярнее) - тогда я пойду опять страдать ориджином.

[Albo]

Спорю, что в Ёкселе автоматизировать процесс будет гораздо сложнее, хотя для одного конкретного файла - возможно! - сделать вручную в Ёкселе будет и проще, например, с использованием какого-нибудь smart fill.

Для Екселя наверное нет невозможного, но вот для программирования реализации задачи может потребоваться достаточно много времени, в том числе и на решение вопросов "почему оно не работает, хотя должно". Я решил вопрос с пакетной обработкой dat-файлов с потенциостата (время, ток, потенциал) с помощью функции импорта Экселя, макрокодера и какой-то матери. Ограничений на количество файлов формально нет, можно хоть каталогами обрабатывать и складывать в нужное место, все решается, если нужно. Плюсы в том, что не надо осваивать новый язык, достаточно обычного ВБА, по которому тонны литературы, и возможность создания любого визуального интерфейса прямо в книге. Для любителей - ещё и экспорт/импорт от Ворда до Access-а.
Основное ограничение в Экселе - плохая и неудобная работа с данными с большим количеством точек. Тут бесспорно лучше тот же Ориджин. Ну и построение врезок, комбинация слоев, 2+ оси для каких-нибудь ДТГ-ТГ-ДСК с пиками температур или пачки РФА с подписями фаз - в Экселе это печально.

[bf109xxl]

Для Екселя наверное нет невозможного

Так я это с самого начала и говорил. Считаю Ёксель весьма мощной программой, чрезвычайно полезной во многих отраслях человеческой деятельности. Но...для научных задач неоптимальной. Она (программа) превосходна для бухгалтеров и лаборантов. А научным сотрудникам требуется нечто более продвинутое. Я не агитирую за Ориджин. В конце концов есть великолепный (и бесплатный!) пакет R, есть указанные выше альтернативные пакеты визуализации и обработки данных, еще Матлаб и десятки других вариантов. Единственное преимущество Ориджина - это компактность скриптов. В последних версиях я бы еще добавил огромное количество полезных Х-функций, резко упрощающих многие операции.

но вот для программирования реализации задачи может потребоваться достаточно много времени, в том числе и на решение вопросов "почему оно не работает, хотя должно".

Именно! Да и банально размер кода будет гораздо больше. Думаю, в разы, если не на порядок.

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

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

Основное ограничение в Экселе - плохая и неудобная работа с данными с большим количеством точек. Тут бесспорно лучше тот же Ориджин. Ну и построение врезок, комбинация слоев, 2+ оси для каких-нибудь ДТГ-ТГ-ДСК с пиками температур или пачки РФА с подписями фаз - в Экселе это печально.

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

ЗЫ. А в Ёкселе уже пофиксили ошибки в статистических функциях? А то оные благополучно кочевали из одной версии в другую в течение долгих лет (ЕМНИП, с версии 8 до 12, как минимум). Несмотря на публикации в математических журналах.

[Yurii]

Наконец до ума довели в версии 9.1 работу с осями в 3D. Да, и на C наколенный вариант нетрудно изобразить.

[Hattabych]

В ориджине это сделать очень просто.
Если у вас два набора данных по 2 колонки в каждом. Можно на одном листе все разместить (4 колонки) пометить нужные колонки как оси Х, нужные оставить как оси Y. Так что получиться набор Х1 Y1 X2 Y2. Выделить все и нажать plot. Это все.
Есть другие методы. В частности еще простой: данные размещены на отдельных листах (2 листа по 2 колонки в каждом). Открыть новое окно для графика, нажать правой кнопкой мыши - выбрать Layer Contents. Там перетащить слева на право нужные данные (оси Y из каждого листа). Нажать OK. Это все.
По-моему, лучше ориджина для быстрого построения графиков ничего нет.

[bf109xxl]

В ориджине это сделать очень просто.

Не пробовали читать ответы других участников? А то там ведь все это уже было подробно описано - даже с картинками.