Лучшие среды для научных вычислений?

Ну я как бы всё понимаю, что ножик удобно в руке лежит и хлеб им можно резать → почему бы не поковырять им стенку? Особенно если перфоратор не куплен/не освоен.

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

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

2. На курсах повышения квалификации строителей - о необходимости тяжелого перфоратора SDS MAX при штроблении пенобетонных стен под скрытую проводку.

Особенно интересует реакция аудитории.

Честно говоря я не очень понимаю о чём мы спорим

Я тоже, но это может еще долго продолжаться - если Вы будете продолжать игнорировать аргументы оппонентов.

утверждать что Эксел простой в освоении инструмент для обработки данных как-то не комельфо.

Освоения на каком уровне и для каких задач?

Есть более другие платформы с более разумными умолчаниями и более лёгкой автоматизацией, что критично при масштабировании.

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

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

Да? И каким образом оно это подтверждает?

решетки чего? кристалла?

Это совершенно неважно в контексте данной задачи. Вы же увидели необычные зависимости между лямбдами? Какие они?

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

Аргументы вида «все так делают» так себе аргумент. Пример, когда особенности обработки данных экселем, причём обработки не такой уж суперсложной — среднее посчитать, приводит к противоположным результатам, я показывал выше. И это был пример вполне себе статусных экспертов-экономистов и влияние этого результата на мир было весьма серьёзным. Это публичный технический фэйл и он не единственный.

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

Аргументы вида «все так делают» так себе аргумент.

Аргументы вида «мне это неудобно» ничем не лучше.

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

В гнуплоте отношение целых (в фунцкии) дает целое, это тоже приводит к неслабым фейлам которые не всегда заметны. В формате SEG-Y флоты хранятся в формате IBM floating point, и если забыть их перегнать в IEEE перед обработкой то фейлы вообще выражаются в больших денежных суммах - месяцы работы большой конторы улетают в трубу. Влияние на мир этих фейлов невелико по одной простой причине - распространенность гнуплота и SEG-Y сильно меньше чем экселя

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

Для реальной сигнальной обработки используют «перфораторы». А вот для настройки/доработки «перфоратора» иногда используют эксель - какая разница в чем строить график y(x) по тысяче точек?

Причём здесь «мне не удобно»? Это объективная реальность. И да, я бы не приводил проприетарный гнуплот в качестве положительного примера. Его основное преимущество, в том, что он старый.

Причём здесь «мне не удобно»? Это объективная реальность.

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

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

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

Тоже аргумент так себе. Вы инструменты пробовали на СВОИХ задачах, а другие люди используют инструменты для СВОИХ задач. Личный опыт в данном случае нерелевантен ни разу.

Вот когда эти люди начнут обрабатывать данные с ускорителей - тогда берите шашку, садитесь на коня и вперед. А пока что Вы со своим опытом лезете на их полянку. Во многом Вы оказываетесь правы (алгоритмы то и правда пересекаются), но зачастую Вы выглядите как чудак с перфоратором SDS MAX у снежной иглу на северном полюсе - а розетки то и нет… Правда его можно и не включать, стенка и так буром протыкается. А если включить - стенка может рухнуть.

проприетарный гнуплот

ЕМНИП у него своя свободная лицензия. Сорцы точно открыты.

А вот для настройки/доработки «перфоратора» иногда используют эксель - какая разница в чем строить график y(x) по тысяче точек?

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

Давайте Вы перестанете передергивать и подменять понятия для начала? Или ссылку на мой комментарий где я РЕКЛАМИРОВАЛ эксель, или давайте уже досвиданья - надоело;-(

Это вот такой вот пример на который нам постоянно намекал Столманн: это не свободные исходники, это только открытые исходники. Open != Free. То есть найти ошибку можно, а поправить нет. Там есть обходной вариант, но это своеобразные геморрой и как следствие стагнация в разработке по не интересующим авторам направлениям.

Maple лет 25 как нравится для простых вещей . Ничего другое не умею, да и ненужно.

О'k замените рекламировать на оправдывать использование. Я действительно неуклюже выразился.

найти ошибку можно, а поправить нет

В чём это выражается?

Модификации не могут быть интегрированы в код и можно распространять только в виде патчей. Иными словами публичный форк с поправленными исходниками не сделаешь. Подробности в лицензии к gnuplot. То есть там не всё так ужасно, как могло бы быть, но это не Free.

О’k замените рекламировать на оправдывать использование.

;-) Ок, принято.

Скажите, а Вы рекомендаций по здоровому сну, питанию и сексу на улице случайным прохожим не даете?;-)

Ладно, я Вашу позицию понял - использование экселя неоправдано ни в каком случае. По мне так работать надо в том в чем умеешь/удобно (лично ТЕБЕ), процесс познания штука такая… индивидуальная. В этом смысле я толерантен до омерзения, а всякие запреты меня пугают, видится мне в этом какой то религиозный фанатизЪм.

Лет 10 назад я сам был таким фанатиком, видимо старею. На этом думаю можно закруглиться, позиции обозначены, дальше мы друг друга не убедим. Спасибо за беседу, было интересно;-)

Диплом-то он защитил?

Да, но получил трояк — крест на аспирантуре. Чтобы не защитить диплом при формальном отсутствии долгов, написанном тексте, сделанной презентации и имеющейся к этому мотивации нужно нахамить всем и получить отрицательные отзывы от всех же, включая руководителя и даже в этом случае могут быть лазейки (как минимум один такой случай я наблюдал).

P.S. Вот что я считаю извращением, так это макросы в экселе. Это типа когда людям уже нужен нормальный ЯП, но они не знают ничего, кроме экселя.

Вот, кстати, мне тоже кажется, что электронные таблицы (любые) — хорошая вещь, но были бы куда круче, если бы занимались только своим делом. Таблица + калькулятор. А для всего остального вместо долбаных макроязыков сделать возможность лёгкого доступа извне, причём двумя способами:

1. открытый формат данных. Есть ODS, но он не самый распространённый, он появился поздновато, и можно было бы ещё проще (минималистичный XML/JSON с упором именно на табличность). У MS с OOXML ещё хуже, да. Есть CSV, но это уже другая крайность;

2. API. Причём не гвоздями прибитый к винде, как у самизнаетекого, а переносимый.

калькулятор

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

Ага, а потом удивляемся, почему это у нас ракеты падают, когда вычислениями занимаются вот такие доморощенные эксперты с экселями и счётами наперевес (зато с кучей медалек и эта… академики типа)

Скажите, а Вы рекомендаций

А зачем, когда есть LOR?

Хм, а как так получилось, что…

А, вот оно что:

Despite its name, this software is not part of the GNU Project.

Тогда понятно. Да уж, названьице вводит в заблуждение.

Это очень старая программа, а тогда с наименованиями особо не заморачивались.

У табличных процессоров есть два огромных бонуса:

1. видно какая таблица откуда и как появилась.

2. при изменении входных данных автоматически пересчитываются все зависимости.

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

Платить за это приходиться ограничениями на размер данных и сложность их вычисления. Я гляжу на свой последний набор результатов по CMD - 24Гб, 2 тыс расчетов, 600 узлочасов. Не дай Б-г это автоматом запуститься на пересчет;-)

Но желание иметь метаинформацию о том что из чего и как было посчитано становится все более и более острым. После того как для каждого расчета автоматом сохраняются параметры и код (то что было насущной необходимостью 20 лет назад и что за эти 20 лет отлажено), такое вот отслеживание зависимостей становится очередной насущной необходимостью без которой непонятно как жить. При этом хорошо бы пристегивать еще тех/pdf где описано из каких соображений это делалось и по каким алгоритмам.

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

при изменении входных данных автоматически пересчитываются все зависимости.

Ээээ, а каким это боком бонус только табличного процессора? Или имеется в виду, что явно не нужно запускать процедуру обработки?

С первым пунктом тоже весьма спорно. Последовательно написанные команды позволяют проследить линейку трансформаций лучше, чем вот эти вот формулы в отдельных ячейках.

И согласен с тем, что с детекторной обработкой только написание собственной программы решает поставленные задачи.

Это то что Вы пытались реализовать у себя

Почему глагол несовершенный? :) Внутренний релиз был, скоро будет вторая версия для произвольно-мерных таблиц

Платить за это приходиться ограничениями на размер данных и сложность их вычисления. Я гляжу на свой последний набор результатов по CMD - 24Гб, 2 тыс расчетов, 600 узлочасов. Не дай Б-г это автоматом запуститься на пересчет;-)

Всё это решается на уровне целей Makefile

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

Это тоже хорошая задача, но слабо формализуема для общего случая — когда продьюсером данных может быть кто и что угодно. Если Вы сами что-то считаете, и сами же потом обрабатываете, то вопросов нет.

При этом хорошо бы пристегивать еще тех/pdf где описано из каких соображений это делалось и по каким алгоритмам.

Это неплохо реализованно в R через модули составления отчётов, но там объект вычислений это вектор и принципиально всё должно находиться в оперативной памяти, так что в ФЭЧ без серьёзных переделок оно не применимо.

Ээээ, а каким это боком бонус только табличного процессора? Или имеется в виду, что явно не нужно запускать процедуру обработки?

Да, поменял чиселку в начале - все графики перестроены, поменялась чиселка в конце, прямо вот в реальном времени.

Последовательно написанные команды позволяют проследить линейку трансформаций лучше, чем вот эти вот формулы в отдельных ячейках.

Лучше всего это отображать в виде графа. Или макефайла, иногда для таких вещей используют маке. Я даже студентам такое задание когда то давал, написать комплекс (текст-код-график в тексте) и все это собирается maкe-ом.

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

Всё это решается на уровне целей Makefile

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

Хорошо бы какой то автоматический логгер что ли…

В R все ходы записываются и по умолчанию при новой сессии подгружаются данные со старой. Но к сожалению это не наш случай ☹

Почему глагол несовершенный? :)

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

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

У самурая Makefile нет цели, только путь

Я к тому, что для меня GNU Make — это прежде всего инженерная методология. Задача «что-то нужно сделать из чего-то по каким-то правилам» возникает неожиданно часто

В R все ходы записываются

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

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

В случае R хранится не только история команд, но и значения всех переменных и все созданные объекты, то есть вообще всё. При выходе там делается фактически дамп памяти. Наверняка есть аналоги с подобным поведением, правда плохо то, что это не текстовая, а бинарная информация. Наверное можно хранить несколько срезов при каждой важной трансформации.

В случае R хранится не только история команд, но и значения всех переменных и все созданные объекты, то есть вообще всё. При выходе там делается фактически дамп памяти.

ИМНО это пример того как не надо делать;-)

Есть некая аксиома выстраданная потом и кровью - машина не должна быть умнее человека.

По умолчанию эта функциональность позволяет отойти на обед, выйдя из сессии и начать с того же момента, на котором закончил. Загрузка данных предыдущей сессии делается только если запустить R в директории проекта, а каждый новый проект в другой директории естественно начинается с нуля. Так же всегда можно явно попросить или указать в файле настройки этого не делать. В этом отношении всё сделано по уму.

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

Я могу уйти на обед уложив ноут в суспенд-моду.

Это все ясно, и ясно зачем создатели R это сделали (для их задач это Ок). Для моих нет, мне через год захочется пересчитать таблицу B на основе обновленной таблицы A и обновленным алгоритмом С - но очень похожим на то что делалось раньше образом.

Нет, должен храниться граф зависимостей и граф должен скорее всего храниться децентрализованно. Как то так.

http://www.iqtrainwrecks.info/2013/04/19/did-an-excel-coding-error-destroy-the-economies-of-the-western-world/

Интересно. Кризис начался в 2006-м, а как следует ударил в 2008-м. В 2010-м появляется статья с ошибкой, оправдывающая осторожничанье со стороны правительств у психологического барьера 90%. В 2013-м эту статью обвиняют в том, что экономика до сих пор не оправилась. Думаю, её влияние преувеличивают :)

Из статьи неясно, что привело к неверному выводу: «Excel coding error» или невключение 5 стран в выборку для расчётов.

мне через год захочется пересчитать таблицу B на основе обновленной таблицы A и обновленным алгоритмом С - но очень похожим на то что делалось раньше образом.

Берётся скрипт созданный по результатам сохранённой год назад сессии и модифицируется. Там указаны источники и команды по их трансформации. Это ЯП, хоть и специализированный.

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

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

Я так графики сейчас перестраиваю - у меня обертка для гнуплота автоматом сохраняет в одноименном скрипте набор необходимых команд.

Скрипт для каждого файла с данными это неплохое решение, но уж больно много файлов будет, да и скрипт можно забыть скопировать/потерять. Пока что мне хочется необходимую информацию впендюрить в заголовок;-(

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

К вопросу о сохранению большого числа скриптов ответ: БД. Там же тогда можно и версионность навернуть и информацию, где лежат файлы данных. Записывать в заголовок всё-таки не самая хорошая идея.

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

А потом файл перемещается на другой хост и информация теряется. или еще хуже - файл обновляется а запись в БД нет.

Не, с БД в этом случае замучаешься поддерживать целостность данных.

А потом файл перемещается на другой хост и информация теряется. или еще хуже - файл обновляется а запись в БД нет.

А это означает, что двигать файлы вручную нельзя, а всё делать через скрипты с отметкой в БД, то есть создавать инфраструктуру и автоматизацию полезно для всех. Хотя конечно можно ограничиться символическими линками. Ну и вообще: а почему бы файлы тоже в БД не запихать? В принципе решения вполне себе есть, ну или как минимум заявлялись.

Возможно пришла пора потыкать палочкой SciDB. В этом случае можно пихать не файлы, а события.

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

Особенно эпично будет развертывать новый набор на кластере. Выбор очевиден;-)