Переход на линукс минт
А зачем мне "костыли" без гарантии того, что после очередного обновления FR не перестанет работать? Да и сомневаюсь я, что последние версии можно установить под вайном без плясок с бубном. Но это мои личные сомнения.
А насчет офиса... Юзеры, юзающие офис на уровне составления "кюндигунга", никогда не поймут, почему корпорации предпочитают не связываться со всякими опенсорсными поделиями (исключения бывают, но они - именно исключения).
Юзеры, юзающие офис на уровне составления "кюндигунга", никогда не поймут, почему корпорации ...
Согласен. Для домохозяйских нужд либре или опен оффиса
за глаза. Корпоративно - совсем другие танцы, начиная от совместимости
форматов и кончая поддержкой стандарт. функций, к примеру, файлик-табличка
с нужной мне инфой не открывается на Кальке, т.к. он не может слопать
табличку весящую 150 мег и содержащую 330 тыщ. записей ...
Так что сидим на работе "на имперской", так сказать :))))
табличку весящую 150 мег и содержащую 330 тыщ. записей
А зачем такие нужны? Есть же базы данных. У нас норот ексель использует (весьма эффективно, замечу) для визуализации и анализа производственных данных, получаемых с SQL-серверов. Я ексель (и все екселеобразные табличные процессоры) не люблю давно и глубоко, поэтому данные анализирую исключительно в R, Origin-е и Matlab-е. Честно говоря, впервые увидел своими глазами, что такое "профессиональная работа с екселем". Но все же предпочитаю уважать оный издалека - пользуюсь лишь уже давно сделанными проектами для контроля и оптимизации производственных процессов, а всю "интеллектуальную" часть делаю другими средствами. Сила привычки...
Зачем ?
Затем, что "нужная инфа для анализа" приходит разными способами.
Иногда достаточно просто посмотреть пару интернет-страниц,
иногда ... файлик на 150 мег. с месячной статистикой, из которой мне интересно
только 2%, однако экстра для меня никто ни чего не сортировал ...
приходится самому.
Все это типичные задачи для R, как я представляю. Там - в R - есть спецсредства для извлечения данных с интернет-страниц, например. Сам оные не пользую, правда - мне только R-пакет RODBC для доступа к данным потребен.
Но можно и в екселе колбасить, конечно, функционал позволит, вопрос лишь в трудо- и времязатратах. Хотя, ИМХО, для сколь-нибудь серьезного анализа данных табличные процессоры гораздо менее удобны, чем специфическая среда скриптового программирования типа R.
Блин, я не программист, какой нафиг Р ?
Я моск, анализирующий разную инфо, поступающую
разными путями и принимающий решения относительно
дальнейшей экспансии в тот или иной регион ...
О как написал, аж сам охренел :)))))
Это вообще чего такое ? Судя по досупной инфе - статистическая прога.
Верно ?
Вот именно для этой цели - АНАЛИЗА данных, а не программирования для энд-юзера! - R является наиболее эффективным средством! Мне гораздо быстрее написать скрипт, чтобы выяснить, например, скрытые взаимосвязи между теми или иными параметрами производственных процессов и процентом выхода готовой продукции. По сути, это попытка понять тонкую физикохимию того, что происходит в закрытой установке. Я готовлю с помощью R ежемесячную аналитическую презенташку для поверпойнта слайдов на 80, где каждый может увидеть "узкие места" на его установках и понять, что нужно для исправления косяков. В принципе, мне уже достаточно лишь указать месяц и год, дальше все происходит автоматически вплоть до генерации самой презенташки - сам поверпойнт нужен исключительно для совместимости, пост-обработка в нем практически не производится. Плюс, по ходу дела может заскочить шеф и попросить мол, а слабай-ка мне по быструхе график, чтобы я глянул, как изменились причины брака и частота появления бракованной продукции при введении новой схемы технологического процесса на установках данного типа - ну, ты ж минут за 10 смогешь, правда?
По R достаточно много отличной литературы. На мой взгляд, для анализа данных это наилучшее средство. Что мне не очень нравится, это визуализация, хотя это лишь следствие инертности моего мышления - я привык к Origin-у, а это другая идеология.
Скачал. Установил. Нихрена не понял. Снёснах ...
И всё это на казённом компе
Там реально надо разбираться в программировании ?
Мне надо просто - тык/мык и чтобы с´анализировало
Однако, учитывая все нюансы я ничего меннять скорее всего
не буду. У меня "творческий полёт мысли с учётом вводимой
информации" лучше в башке работает, чем на компе
Разбираться немного надо. Но это несложно - это не "настоящее" программирование, все делается короткими скриптами с вызовом готовых функций, плюс, есть отличнейшая IDE - R-Studio, с ней R пользоваться одно удовольствие. Зато потом можно "легким движением руки" делать то, что в екселе потребует гораздо больше усилий и/или дополнительных модулей. R - это стандарт де-факто в области статобработки данных. Широко используется в разных областях - везде, где только нужна статистика. А в екселе долгие годы не удосуживались пофиксить тупую ошибку в вычислении статистического параметра, о чем писали в математических журналах.
На русском есть книга Шипунова "Наглядная статистика. Используем R" - она неплоха для первого знакомства, есть перевод книжки Кабакоффа (Кабакова) - "R в действии. Анализ и визуализация данных с помощью R", перевод мне не очень нравится, но сама по себе книжка более продвинутая, чем предыдущая. На басурманских же языках книг просто куча.
Короче, мое дело предупредить. Анализ в екселе возможен, но неудобен, особенно - при больших объемах данных. А R работает достаточно шустро, имеет отличнейшую среду программирования с подробным хелпом. Ну а кроме того, уже практически на каждый "чих" существует готовое решение в виде пакета функций. Типа, хочешь многовариантную статистику - пажалста, хочешь профессионально анализировать текст - пажалста, и т.д., и т.п. В общем, овчинка выделки стоит однозначно. Но насильно мил не будешь, это да.
ОК, спасибо. Будем осваивать .. на досуге. Моск он эта ...
работать должен. Переход на линукс осилил теперь иной
раз нет-нет да надо над чем-то другим думать пока совсем
тепло для рыбалки не станет. Потом буду думать о червяках и больших
рыбинах :)))))
поэтому данные анализирую исключительно в R, Origin-е и Matlab-е
аналогично... с R правда пока не знаком, но матлаб для массовой обработки эксп. данных (скажем, сотню-другую файлов с ascii-таблицами + их предв. обработка и фит всевозможными функциями + вытягивание параметров фита в виде csv-таблиц и/или графиков = в простонародье, протоколы измерений) -- самое то. Один раз написал скрипты, отладил вывод (при необходимости, скомпиллировал скрипты в exe, если планируется использовать на посторонних компьютерах у немецких сотрудников) и сотня файлов в один клик превращается в многостраничный ps/pdf с графиками и/или csv-данные для дальнейших манипуляций. А вот когда на основе полученных таким образом csv-таблиц надо построить какой-нибудь особо забористый график -- сугубо, в единичном экземпляре, скажем, для научной статьи -- тут (скорее в силу привычки)
используется оrigin, а уж из него в eps > latex... До имплементации математики из матлаба в виде cи-шного кода наши qt-корифеи доходят разве что в особо "коммерческих" случаях, когда есть жирный заказчик и его можно развести на солидные деньги.
R в значительном количестве случаев может вполне эффективно заменить матлаб. А в некоторых случаях - и с гораздо большей эффективностью (с разницей по времени выполнения порой в несколько порядков). Например, при кластеризации данных. Но для работы с матрицами (например, для обратной свертки с регуляризацией) мне матлаб банально привычнее.
По большому счету я мог бы сделать перечисленное выше (поточная обработка данных с помощью скриптов, создание сложных многослойных графиков, любой вид линейной/нелинейной аппроксимации в скриптовом исполнении, пригодном для поточной обработки) в любом из указанных программных средств - все, за исключением компилляции. С другой стороны, иногда дешевле купить несколько дополнитльных лицензий на софтину, чем платить за разработку отдельного исполнимого модуля. У меня, к примеру, недешевый Origin Pro, с помощью которого я сделал проект для
анализа производственных процессов, не требующий знания Ориджина как такового - весь интерфейс (достаточно развитый, надо отметить) полностью сбацан в графическом окне. А остальным юзерам выдают самую обычную "бюджетную" версию (не-Pro), и большего им и не надо - они все равно в Ориджине мало что умеют. В результате скорость "разработки" и гибкость чрезвычайно высокие - я могу оперативно вносить изменения и дополнения в соответствии с чаяниями юзеров. Есть подобные возможности и в R, но там веб-технологии, а я их почему-то категорически не люблю.
R в значительном количестве случаев может вполне эффективно заменить матлаб. А в некоторых случаях - и с гораздо большей эффективностью (с разницей по времени выполнения порой в несколько порядков). Например, при кластеризации данных
О, спасибо за информацию. Если учесть, что и на работе (winxp) и дома (mint) стоят довольно старые версии матлаба, которые при счете используют исключительно одно ядро, бесплатная альтернатива -- к тому же мультиплатформенная -- явно не помешает.
По большому счету я мог бы сделать перечисленное выше (поточная обработка данных с помощью скриптов, создание сложных многослойных графиков, любой вид линейной/нелинейной аппроксимации в скриптовом исполнении, пригодном для поточной обработки) в любом из указанных программных средств - все, за исключением компилляции.
Компилляция -- это я наверное чуток преувеличил. Для нормальной работы такого ехе-шника (по крайней мере, скомпиллированного под моей виндовой версией) на стороннем компьютере надо доустановить бесплатный пакет ~60MB с библиотеками (что-то типа .NET-фреймворка для c#-проектов). Собственно, гл. преимущество -- доп. лицензия для этого не нужна...
У меня, к примеру, недешевый Origin Pro, с помощью которого я сделал проект для анализа производственных процессов, не требующий знания Ориджина как такового - весь интерфейс (достаточно развитый, надо отметить) полностью сбацан в графическом окне. А остальным юзерам выдают самую обычную "бюджетную" версию (не-Pro), и большего им и не надо - они все равно в Ориджине мало что умеют.
Я как раз из их числа. Использовать обработку данных в origin при наличии под рукой матлаба просто рука не поворачивается, хотя если бы сильно прижало, то освоил бы. В то же время, полностью отказаться от origin не могу, т.к. в нашей среде он уже давно стал де-факто стандартом для вывода научных графиков, программой, чьи проекты практически каждая собака шлёт по емейлу с уверенностью, что их есть чем открыть.
Компилляция -- это я наверное чуток преувеличил.
Ну почему же? Использование фреймворка не отрицает необходимости оной для создания автономного модуля. В Матлабе таки-есть вполне себе компилятор (не-JIT, как в R).
доп. лицензия для этого не нужна
Вопрос лишь в цене разработки автономного модуля.
Использовать обработку данных в origin при наличии под рукой матлаба просто рука не поворачивается
А что мешает? Та же нелинейная аппроксимация и multi-peak fitting в Ориджине как бы и не поудобнее были. Но Origin и впрямь лучше подходит для высококачественной и сложной визуализации научных данных, как бы его ни продвигали в индустриальный сектор для рутинной обработки. Вторая сильная сторона Origin-а - развитые средства для интерактивной работы, в Pro-версии можно быстро клепать любую "морду" к обработке данных. Кстати, есть
Origin Viewer - смотреть графики можно и без полноценной версии. Хотя, конечно, отправлять в проприетарном формате без предварительного согласования - моветон.
PS. Вдоволь наигравшись с имплементацией нелинейной аппроксимации в C/C++ для встраивания в сторонний софт - не просто десяток точек нехитрой функции обсчитать, а чтобы _устойчиво_ работала с самыми _разными_ функциями - я буду всеми силами пытаться использовать для мат.обработки данных готовые решения в виде обсуждаемых программных пакетов.
В гробу я видел этот Линукс с его командной строкой.
Я считаю эта система для студентов и убогих мозго-выносимых людишек...
Эта вот ты так резко интеллектом блеснул чтоли ?
Тебя заставляют ? Нет. Нравится насквозь шпионская
имперка ? Да битте шён ...
Тупо отрицать мол "с командной стройкой" фтопку ...
ну чтож, у каждого свой предел возможностей.
Вот только одно скажи - зачем ты сюда пришёл ?
Иди назад, учи людей, шо венда это верх совершенства,
особенно деффендер ... благодарных слушателей достаточно,
зачем тут идиотом себя выставлять ;))) ?
особенно деффендер ...
у него вроде основная фишка была про браузер-угонщик? я что-то упустил?
PS. Вдоволь наигравшись с имплементацией нелинейной аппроксимации в C/C++ для встраивания в сторонний софт - не просто десяток точек нехитрой функции обсчитать, а чтобы _устойчиво_ работала с самыми _разными_ функциями - я буду всеми силами пытаться использовать для мат.обработки данных готовые решения в виде обсуждаемых программных пакетов.
Был бы рад любым готовым решениям, но... Мне иногда приходится возиться с нестандартными функциями и некорректными задачами типа обратного преобразования Лапласа в ядерном магнитном резонансе, когда, например, по 2м десяткам зашумленных точек на кривой нужно восстановить спектр распределения характерных времен. Может где-то есть и коммерческие пакеты для этого, но в большинстве случаев мат. методы все ещё активно разрабатываются, а соотв. пакеты пишутся и выкладываются в сеть -- исключительно энтузиастами.
В R есть готовый пакет для обратного преобразования Лапласа: invLT
Уж не знаю, насколько он юзабельный. Я когда-то работал с обратной сверткой при решении некорректных задач типа интегральных уравнений Фредгольма 1-го рода для пространственно-разрешенного анализа сканирующими спектральными методами и неплохо представляю, как качество сигнала влияет на устойчивость и точность решения.
В R есть готовый пакет для обратного преобразования Лапласа: invLT
Данке, при случае гляну документацию да потестирую... в принципе для матлаба тоже готовых пакетов хватает (в этом смысле здорово помогает матлаб-комьюнити). Из тех, с которыми уже успел поиграться я (и на модельных функциях -- "какой-нибудь спектр из 2-3х дельта-функций > временная развертка + наложение шума > восстановление спектра и сравнение с исходным" -- и на реальных данных эксперимента) устойчивее всего работал стандартный rilt, но для запросов моих немецких коллег он слишком меееедленный. Есть более шустрые алгоритмы, но они нестабильны... в-общем, мои немцы сейчас с поисках "такого же, но с перламутроваными пуговицами"
Ещё раз спасибо.