Опубликован релиз среды компьютерной математики Scilab 2023.0.0, предоставляющей похожий на Matlab язык и набор функций для математических, инженерных и научных расчётов. Пакет подходит для профессионального применения и использования в ВУЗах, предоставляя инструменты для разнообразных вычислений: от визуализации, моделирования и интерполяции до дифференциальных уравнений и математической статистики. Поддерживается выполнение сценариев, написанных для Matlab. Код проекта поставляется под лицензией GPLv2. Готовые сборки сформированы для Linux, Windows и macOS...Подробнее: https://www.opennet.me/opennews/art.shtml?num=58784
А чем оно лучше (хуже) GNU Octave?
лучше тем что не на кутэ и по функционалу
а так везде господствует товарищ матлаб
Во-первых, на QT тоже можно современный эргономичный GUI наваять, вместо вырвиглаз образца 90-х годов в Octave. Во-вторых, по функционалу Octave все же получше, хотя при этом надо учитывать потребности конкретного пользователя. При более детальном рассмотрении и SciLab для некоторых областей применения может оказаться более функциональным.
> на QT тоже можно современный эргономичный GUI наваятькаким образом это можно сделать на плеере от Apple?!
Математический пакет на плейере? Да вы знающий толк в извращениях.
Ну так предлагают же на QT. Если вы не знаете, докладываю: это QuickTime.
Слишком толсто. Попробуй похудеть.
Только Qt
Так там и написано про QT.
Про QuickTime?
бинго, у местных очень туго с распознаванием регистра в названиях торговых марок
Не, нормально, написать "кутэ", вместо "кьют" - никто не придирается. А если QT - уже куча придирок.
Если ты напишешь Quute тебя тоже не поймут. А куте это всё же корректно.
> Во-первых, на QT тоже можно современный эргономичный GUI наваятькак будто это можно или когда-нибудь можно было сделать на чём-то другом
>а так везде господствует товарищ матлабА он нам точно товарищ?
Например, Алмаз-Антей переползает на Python/NumPy.
Что там с обратной совместимость?Видел жалобы на то, что при всём удобстве питоньей экосистемы для научных вычислений скрипты на питоне протухают чуть ли не на глазах и их приходится переделывать под новые версии языка и библиотек.
Если нормально фиксировать версии зависимостей все нормально работает. А то видел научный питон requirements.txt типа numpy, pytorch, scipy (очень капризный) чето ещё всё без версий! Как будто кто-то руками писал. Ясен красен хрен чего из зависимостей соберешь. Хорошо хоть известно с какой версий питона это всё изначально работало. Можно методом перебора понять какие версии использовались. В крайнем случае во время работы тебе скажу, а такой вот функции нету. Ищешь, а она более в поздней версии пакета есть.Если использовать какой-нибудь нормальный poetry или pipenv на худой конец pdm проблем быть не должно.
В чём и проблема - даже если прописать зависимости, запустится ли оно через условные 10 лет - большой вопрос: будут ли репозитории ещё содержать эти древние библиотеки, будут ли вообще эти репозитории ещё работать, скомпилится ли интерпретатор питона правильной версии через эти 10 лет под новую платформу?Одно дело - какая-нибудь языковая модель, которая нужна здесь и сейчас, а через год будет заменена новой, а совсем другое - какой-то алгоритм, который, скорее всего, если и будет меняться, то по чуть-чуть, но зато будет использоваться годами.
Собственно поэтому до сих пор фортран котируется: алгоритмы, воплощённые в нём, фактически вечные, только пользовательский интерфейс меняй на более современный.
В докер положи, а докер в файл и в репо. Так правда никто не делает от слова совсем, но может сработать. А если через 10 лет не будет докера отковырять файлы из overlayFS и можно попробовать запустить на древнем ядре.
СайПай в том числе и на Фортране написан.
Совместимость питона на самом деле поразительная. Лично я сталкивался только с проблемами в наколенных cython батарейках когда внутрянку питона переписывали и ещё когда асинхронщину на протяжении нескольких версий переколбашивали и требовались некоторые изменения в коде. Если ты не используешь мёртвые зависимости, то тебе не придётся беспокоиться о том, что твой код работать не будет. И нет, твоё предложение фиксировать версии не обязательно будет работать -- помимо питона есть ещё системные либы. Твой выбор докер.
Ну да ... переход с 2 на 3 поразил многих ... И надолго.
Это сказки опеннетовские, весь мир в восторге от 3 питона. 2 питон ещё недостаточно отошёл от статуса несерьёзного игрушечного языка, каким питон представал изначально, но 3 уже можно нормально пользоваться без хаков а ля sys.setdefaultencoding('sjisx0213').
3-им питоном стало можно пользоваться только через 10 лет после релиза.
Бред. 3.2 уже был абсолютно готов и все важные батарейки емнип тоже портировали к тому времени. Но и на 3.0 писали нормально, просто тогда профит от перехода был ещё не столь очевиден. Чего уж говорить 3.4 и 3.6. Ты утверждаешь, будто только с приходом 3.7 что-то поменялось. Что, по-твоему?
В приличных обществах фиксируют версии окружения через environment.yml
А свои репозитории с необходимыми в прошлом, настоящем и будущем библиотеками и средами исполнения у них есть?
У питона есть достаточно свой репозиторий и старые версии там хранятся и не удаляются. Обычно.
Тут просто особый случай - речь о подсанкционной организации в стране, которая в силу определённых обстоятельств может оказаться без доступа к международным репозиториям. Я, например, не знаю, есть ли зеркала репозиториев питона в России.
Можно питон пакеты в wheel файлы скачивать и в папочку складывать. Есть конечно момент что пакет, может захотеть что-то скачать, например какую-то модель. Но в целом её тоже можно скачать, разобрать исходники пакета посмотреть где у него кеш и туда положить. Но это прям не быстрый процесс будет, это да.
Большие (10k+ строк) ETL/EDA-скрипты на Python протухают в среднем раз в полгода. Это не так часто, и не так больно: на поиск работоспособного сочетания либ со стандартным понижением версии с pip уйдет около 10 минут. На "третий раз" аналитик останется без премии и за день освоит pip env и протухать ничего не будет.А вот продолжать работать в Matlab сейчас очень странно, дорого и подло по отношению как стране, так и к производителю.
Протухают, потому что ты путаешь понятия интерпретатор и скрипты. Видимо качество кода такое же.
Есть ещё Julia
Нынче везде питончик и постепенно Julia
Матлаб - страшный попил.
> и постепенно Juliaда не бывать этому переходу, julia продвигает небольшая кучка извращенцев, скорее python оптимизируют и избавят от текущих проблем, чем перейдут на это убожество julia
>а так везде господствует товарищ матлабНе везде, матлаб меееедленный
Октава тоже не айс, но всё таки...
FFT - "На больших размерах матриц, например 4096х4096, Octave почти в три раза быстрее MATLAB."
А оно не лучше. Посмотрел близкую мне тему - статистику. Половина описаний функций недоступна, часть картинок битые. То, что есть - примитив. Если и остальное такого же уровня, то оценка пакету "неудовлетворительно".
Статистика вообще вещь отдельная и своеобразная. Как оказалось, на R с ней удобней работать, чем даже на MatLAB, не говоря уже об GNU Octave или SciLAB.P.S. Фанаты могут и Python использовать, но пока в него не портированны множество пакетов из R, вроде auto.arima из forecast, я предпочитаю R.
P.P.S. В качестве среды, как для R, так и для Python, и для Julia использую Jupyter
Что значит чем даже MatLAB? Для работы с данными даже Excel удобнее чем MatLAB. Если говорить про интерфейс Spyder IDE пока что топ из придуманного.
Ну на Excel прогнозировать или искать оптимум вообще мало реально, а на MatLAB - вполне, хотя и то, и другое, требует очистки и анализа данных методами математической статистики.
Да и серии из миллионов событий в MatLAB вполне можно обрабатывать, а в Excel - не реально по определению.
Но в любом случае, на R это все сподручней.
Excel может получать данные из внешнего источника, а отображать уже то что сможет или то что запросили. Тут больше вопрос желания.
А на фиг тогда Excel нужен, если Вы предлагаете всю обработку данных производить на внешнем источнике? Ну да, конечно, задачи математической статистики можно решать прямо на ClickHouse или PostgreSQL и визуализировать их в Excel. Но как по мне - это во-первых, большое извращение. А во-вторых, Excel тут уступает специализированным средствам визуализации почти по всем параметрам.
Источником может быть даже, на секундочку, Access. Можно решить в базе, но можно и в Экселе. Может и не очень удобно, но если твоя компания активный пользователь офиса, то почему бы и нет. Есть места где всю статистику решают в офисе. И никто не жалуется что у них нет новомодного питона или р. Но они и обсчитывают не геном человека.
Я сказал выше, какие задачи я решаю статистическими методами - прогнозирование и нахождение оптимумов.
А теперь объясните мне, как такие задачи решать в Excel. Я в нем модель смогу обучить для прогнозирования? Или, пусть даже без дискретки, LP оптимум смогу найти?
Ананий, ты кроме этого поделия Spyder хоть видел номальный IDE, типа PyCharm, RStudio?
Зачем ты вообще вспоминал про эти убогие джава поделки? Это какой-то позор.
Так и запишем - альтернативно одаренный не осилил ведущие мировые IDE. Весь мир осилили, а он нет. Какой-то остров Невезения у них там в Мухосранске. С этим надо что-то делать, мдя...А то настанет - Идиократия.
Тот же самый мир, который сидит на продуктах JetBrains с ненужными свистелками, а есть нормальные люди, которые используют VSCode?
Любители обмазаться электроном предъявляют что-то джве - спешите видеть! VSCode без двух ведер плагинов - редактор кода не сильно удобней какого kate, а обвешенный до состояния 0,7 IDEA выглядит как разудалая цыганщина и работает... спессфисски. Бывает конечно, что именно IDE и не нужна - и те, кто умеет vscode готовить тоже встречаются, но обычно зрелище выходит душераздирающее.
Электрон пока что лучшее что произошло с десктопом лет так за 20.
Он не нормальные, а ограниченные, так как не позоволяют в одном IDE одновременно работать с кодом на R, Python и Julia.
Нет ни одной причины для нормального человека их смешивать. Работай с чем-то одним. Два окна с разными путями настроек открой если очень надо, но все равно это будет неправильно.
Хм, а может это не я ненормальный, а Вы чего-то не понимаете, считая что не может прогнозирование быть на R, solver на Julia, и слеплено все это вместе - на Python?
С учетом того, что прогнозированием на последнем моем проекте одна группа занимается уже года три, другая группа оптимизационными задачами - лет десять (начинали с River Logic, потом перешли на Julia), а аналитики, использующие и то, и другое, для решения уже прикладных задач, кроме Python не знают ничего - я что-то иных путей не вижу.
На русский переведена не вся справка, надо было читать на инглише
Возьми и допиши справку. Хочешь всё и на халяву?
Посоны в теме про октав говорили, что сабж медленней матлаба но сильно быстрее октавы, причём последняя могла в результате выдать что-то не тоХотя возможно всё уже решилось или надо было поиграццо с параметрами
Можно вспомнить что матлаб платный и перестать выпендриваться.
>А чем оно лучше (хуже) GNU Octave?Хуже несколько меньшей совместимостью с матлабом т.е. будет чуть больше возни с заимствованным кодом. Но побыстрее на невекторизованных вычислениях. Есть xcos для визуального программирования мышкой.
Хм, а этот Scilab в векторизованные операции умеет, типа как R? Или нужно обмазываться вложенными "for"?В чём киллер-фитча Scilab? Чем он лучше Jupyter+Python?
jupiter это где на каждую команду виджет в 400 пикселей высотой вместо строчки в консоли?
в браузере
Гм, для ядрёной консоли, есть ipython. Жупитер это про удобство виджетов и обмен тетрадок. Не понимаю ненависти к веб-интерфейсу, ИМХО, неплохой компромисс между удобством, универсальностью, и системными требованиями. Это ж не электрон.
>Хм, а этот Scilab в векторизованные операции умеет, типа как R? Или нужно обмазываться вложенными "for"?Матлабоподобный т.е. векторный изначально. Но некоторые похоже пишут вложенные циклы и жалуются на тормоза. Так то даже некоторые питнисты выучили про нампай (списанный с некоторыми ужудшениями с матлаба) и как векторизовать.
>В чём киллер-фитча Scilab? Чем он лучше Jupyter+Python?
Тем что нет ни Python, ни (не к ночи будь помянут) Jupyter
>векторный изначальноЭто отлично, значит, можно как-нибудь поковырять.
>(не к ночи будь помянут) Jupyter
Ответил в этой ветке выше.За что такая нелюбовь к Жупитеру?!
у него аналог лабвью есть, но я тут посмотрел гнурадио и .... :)
Там Матлаб за 2 дня обсудили, внимание вопрос: что по свободным аналогам Wolfram Mathematica?
Книжку в библиотеке взять.
Maxima отлично работает
http://pashev.ru/files/pashev-axiom-2010.pdf.html
Мы так поняли, что ты хочешь удивить наше сообщество и предъявить собственный аналог Системы Символьных Математических Вычислений, типа SymPy? Да мы не против, давай предсталяй - заценим.