Состоялся (http://www.gnu.org/software/octave/news/release/2019/03/01/o... релиз системы для выполнения математических расчётов GNU Octave 5.1.0 (http://www.gnu.org/software/octave/) (первый релиз ветки 5.x), предоставляющей интерпретируемый язык, во многом совместимый с Matlab. GNU Octave может использоваться для решения линейных задач, нелинейных и дифференциальных уравнений, вычислений с использованием комплексных чисел и матриц, визуализации данных, проведения математических экспериментов.
В новом выпуске продолжена (https://www.gnu.org/software/octave/NEWS-5.1.html) работа по улучшению совместимости с Matlab, реализованы новые функций и переработана подсистема отрисовки. Добавлена серия функций mov* для сдвига видимого окна по области произвольного размера, а также добавлены функции clearvars, isfile, isfolder, openfig, ordeig, savefig и uitable.Существенно (до 25 раз!) увеличена производительность функций для работы с числовыми рядами. Приведены к форме, совместимой с Matlab, функции fminsearch, fminbnd и fminunc. Для использования быстрого преобразования Фурье теперь требуется библиотека FFTW (http://www.fftw.org/) (поддержка работы через FFTPACK (https://en.wikipedia.org/wiki/FFTPACK) прекращена).
Представлены многочисленные улучшения в системе отрисовки графиков. Для вывода в растровые форматы (например, PNG или JPEG) по умолчанию задействован метод отрисовки на базе OpenGL (растровый режим "-opengl" вместо векторного "-painters"). Вместо библиотеки OSMesa для вывода в файлы использованы возможности отрисовки в буфер, предоставляемые библиотекой Qt (класс QOffscreenSurface). Для работы GUI библиотека Qt теперь является обязательной зависимостью (поддерживается Qt 4.8, но рекомендуется Qt 5).
Добавлена поддержка экранов с высокой плотностью пикселей (HiDPI), DPI в которых превышает 96. Реализованы новые опции для распределения содержимого по странице при выводе на печать (генерации PDF и PostScript): "-fillpage" и "-bestfit". Добавлен новый режим печати "-ddumb", при котором информация записывается в форме ASCII-графики.
В сборках (https://ftp.gnu.org/gnu/octave/windows/) для Windows обеспечена возможность работы с файлами и каталогами, содержащими символы Unicode.URL: https://www.mail-archive.com/info-gnu@gnu.org/msg02579....
Новость: https://www.opennet.me/opennews/art.shtml?num=50244
Тыкал палочкой как-то версию 4.2. Ну очень глючно. Даже трудно что-то было из простого сделать, типа нарисовать график для параметрической функции.
Помнится, кто-то активно кyдаxтал (кажется, [s]одaлист[/s] дeбилист с LOR'а), что Qt несвoбодная лaжа, а все проекты GNU делаются на GTK. Вот это поворот! У дeбилиcта будет бaттхeрт.
Пойду ему на лоре напишу, что у него оказывается баттхерт
А может это был квазарчик? У них обоих перманентное состояние бaттxepта. :)
Нормально там все. Много пользовал с 4.0 версии для работы с данными, порядка 10к х 10к.По графике может глючить конкретный тулкит, но их там штуки 3 на выбор
https://octave.org/doc/v4.4.1/Graphics-Toolkits.htmlНо очень медленный невекторизованный код (раз в 50 медленнее чем в matlab и раз в 10 чем в octave). А это бывает неприятно.
> Нормально там все. Много пользовал с 4.0 версии для работы с данными,
> порядка 10к х 10к.
> По графике может глючить конкретный тулкит, но их там штуки 3 на
> выбор
> https://octave.org/doc/v4.4.1/Graphics-Toolkits.html
> Но очень медленный невекторизованный код (раз в 50 медленнее чем в matlab
> и раз в 10 чем в octave). А это бывает неприятно.Октаву нужно собирать самостоятельно, с хотя бы некоторыми оптимальными реализациями обработки матриц (BLAS, LAPACK, по собственным значениям). В дистры включается, насколько помню (лет 5-6 назад), сборка "дженерик", без этих ускорений.
Дело не в дополнительном ускорении векторно-матричных операций, там и так все неплохо. А дело в крайне медленном по сравнению с аналогами обычном for цикле. Не всегда ведь все легко вектооизуется.
Если что-то можно "существенно увеличить (до 25 раз!)", то это значит, что всё было очень плохо с начальной реализацией.
> всё было очень плохо с начальной реализациейКак было не знаю, но вполне возможно, что использовали наивный алгоритм и заменили его на оптимизированый. Это как с преобразованиями Фурье: можно считать "в лоб", можно FFT - результат тот же, но разница в скорости колоссальная.
> заменили его на оптимизированыйЛюбители "просто купить плашку оперативы" фпичали...
> всё было очень плохо с начальной реализацией
> возможно, что использовали наивный алгоритм и заменили его на оптимизированыйНу это одно и тоже.
А там просто кривота
>> всё было очень плохо с начальной реализацией
>> возможно, что использовали наивный алгоритм и заменили его на оптимизированый
> А там просто кривотаПосмотрел патч - да, "ехал find через diff и sort-ом погоняло". Не удивительно, что оно так медленно работало.
он никогда быстрым не был. Другое дело, что сейчас появилась Julia. Нужен ли Octave после этого - большой вопрос.
> он никогда быстрым не был. Другое дело, что сейчас появилась Julia. Нужен
> ли Mathlab после этого - большой вопрос.//no thanks
Нет, это совершенно не вопрос. Пусть будет больше. Даже фортран нужен.
Fortran не "даже", а категорически нужен. Потому что например вариться в кипятке — достаточно болезненная смерть. А у моих знакомых все "теплотехнические" расчёты ещё со времён Союза на фортране. Полагаю, не только у них.
> Другое дело, что сейчас появилась Julia. Нужен ли Octave после этого - большой вопрос.Ответ однозначный - нужен. Поскольку это проект GNU, поэтому его не прикрутят к LLVM.
С таким названием Джулия точно не нужна!
Юлечка.
Когда для Джулии сделают пошаговый отладчик, тогда возможно она и будет кому-то нужна. А когда сделают ГУИ по типу Октавы или Р-студии, можно будет попробовать посмотреть в её сторону.
> Когда для Джулии сделают пошаговый отладчик, тогда возможно она и будет кому-то нужна.https://github.com/JuliaDebug/Debugger.jl
> А когда сделают ГУИ по типу Октавы или Р-студии
> можно будет попробовать посмотреть в её сторону.
живите в настоящем, а не в 5-ти летнем прошлом
Посмотрел ссылки. Так дело не пойдет. Для использования отладчика в Октаве нужно просто поставить красную точку. А здесь предлагают писать в коде всякие "using Debugger" и "@enter foo(20)". Но вообще радует, что проект развивается. Лет через семь, когда он перейдет в более-менее стабильное состояние можно будет попробовать и Джулию. А пока придется по старинке делать прототипы в Октаве и потом переписывать на Си++.
Ещё 10 лет назад Октаву можно было собирать с быстрыми (сишными) библиотеками (BLAS и так далее) или без них. Возможно, теперь что-то из этого вошло в обязаловку.
Починили ли clc? На на версии 4.4.1-7 очистка экрана не работала.
Просто используйте питон.
Уже используем.
> Вместо библиотеки OSMesa для вывода в файлы использованы возможности отрисовки в буфер, предоставляемые библиотекой Qt (класс QOffscreenSurface). Для работы GUI библиотека Qt теперь является обязательнойосвистал.
Плохой, нехороший ход.
Свистелка не отросла. А ход замечательный!