| 1.1, iPony (?), 10:48, 04/03/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
Тыкал палочкой как-то версию 4.2. Ну очень глючно. Даже трудно что-то было из простого сделать, типа нарисовать график для параметрической функции.
| | |
| |
| 2.16, Oops (?), 15:13, 04/03/2019 [^] [^^] [^^^] [ответить]
| +18 +/– |
Помнится, кто-то активно кyдаxтал (кажется, [s]одaлист[/s] дeбилист с LOR'а), что Qt несвoбодная лaжа, а все проекты GNU делаются на GTK. Вот это поворот! У дeбилиcта будет бaттхeрт.
| | |
| |
| |
| 4.22, Аноним (-), 18:27, 04/03/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
А может это был квазарчик? У них обоих перманентное состояние бaттxepта. :)
| | |
|
|
| 2.31, av (??), 04:40, 08/03/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Нормально там все. Много пользовал с 4.0 версии для работы с данными, порядка 10к х 10к.
По графике может глючить конкретный тулкит, но их там штуки 3 на выбор
https://octave.org/doc/v4.4.1/Graphics-Toolkits.html
Но очень медленный невекторизованный код (раз в 50 медленнее чем в matlab и раз в 10 чем в octave). А это бывает неприятно.
| | |
| |
| 3.32, Ю.Т. (?), 09:51, 08/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
 > Нормально там все. Много пользовал с 4.0 версии для работы с данными,
> порядка 10к х 10к.
> По графике может глючить конкретный тулкит, но их там штуки 3 на
> выбор
> https://octave.org/doc/v4.4.1/Graphics-Toolkits.html
> Но очень медленный невекторизованный код (раз в 50 медленнее чем в matlab
> и раз в 10 чем в octave). А это бывает неприятно.
Октаву нужно собирать самостоятельно, с хотя бы некоторыми оптимальными реализациями обработки матриц (BLAS, LAPACK, по собственным значениям). В дистры включается, насколько помню (лет 5-6 назад), сборка "дженерик", без этих ускорений.
| | |
| |
| 4.33, av (??), 18:12, 08/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
Дело не в дополнительном ускорении векторно-матричных операций, там и так все неплохо. А дело в крайне медленном по сравнению с аналогами обычном for цикле. Не всегда ведь все легко вектооизуется.
| | |
|
|
|
| 1.2, Аноним (2), 11:26, 04/03/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Если что-то можно "существенно увеличить (до 25 раз!)", то это значит, что всё было очень плохо с начальной реализацией.
| | |
| |
| 2.3, llolik (ok), 11:35, 04/03/2019 [^] [^^] [^^^] [ответить]
| +5 +/– |
 > всё было очень плохо с начальной реализацией
Как было не знаю, но вполне возможно, что использовали наивный алгоритм и заменили его на оптимизированый. Это как с преобразованиями Фурье: можно считать "в лоб", можно FFT - результат тот же, но разница в скорости колоссальная.
| | |
| |
| |
| 4.19, llolik (ok), 15:56, 04/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
>> всё было очень плохо с начальной реализацией
>> возможно, что использовали наивный алгоритм и заменили его на оптимизированый
> А там просто кривота
Посмотрел патч - да, "ехал find через diff и sort-ом погоняло". Не удивительно, что оно так медленно работало.
| | |
|
|
| 2.4, Аноним (4), 12:23, 04/03/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
он никогда быстрым не был. Другое дело, что сейчас появилась Julia. Нужен ли Octave после этого - большой вопрос.
| | |
| |
| 3.5, Andrey Mitrofanov (?), 12:28, 04/03/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
> он никогда быстрым не был. Другое дело, что сейчас появилась Julia. Нужен
> ли [I]Mathlab[/I] после этого - большой вопрос.
//no thanks
| | |
| 3.6, Аноним (6), 12:41, 04/03/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Нет, это совершенно не вопрос. Пусть будет больше. Даже фортран нужен.
| | |
| |
| 4.30, PnDx (ok), 12:11, 05/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Fortran не "даже", а категорически нужен. Потому что например вариться в кипятке — достаточно болезненная смерть. А у моих знакомых все "теплотехнические" расчёты ещё со времён Союза на фортране. Полагаю, не только у них.
| | |
|
| 3.11, Аноним (11), 13:19, 04/03/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Другое дело, что сейчас появилась Julia. Нужен ли Octave после этого - большой вопрос.
Ответ однозначный - нужен. Поскольку это проект GNU, поэтому его не прикрутят к LLVM.
| | |
| 3.27, Alexklonoff (?), 08:29, 05/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
Когда для Джулии сделают пошаговый отладчик, тогда возможно она и будет кому-то нужна. А когда сделают ГУИ по типу Октавы или Р-студии, можно будет попробовать посмотреть в её сторону.
| | |
| |
| |
| 5.29, Alexklonoff (?), 09:03, 05/03/2019 [^] [^^] [^^^] [ответить]
| +/– |
Посмотрел ссылки. Так дело не пойдет. Для использования отладчика в Октаве нужно просто поставить красную точку. А здесь предлагают писать в коде всякие "using Debugger" и "@enter foo(20)". Но вообще радует, что проект развивается. Лет через семь, когда он перейдет в более-менее стабильное состояние можно будет попробовать и Джулию. А пока придется по старинке делать прототипы в Октаве и потом переписывать на Си++.
| | |
|
|
|
| 2.26, Ю.Т. (?), 21:28, 04/03/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
Ещё 10 лет назад Октаву можно было собирать с быстрыми (сишными) библиотеками (BLAS и так далее) или без них. Возможно, теперь что-то из этого вошло в обязаловку.
| | |
|
| 1.23, Аноним (23), 19:21, 04/03/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –8 +/– | |
> Вместо библиотеки OSMesa для вывода в файлы использованы возможности отрисовки в буфер, предоставляемые библиотекой Qt (класс QOffscreenSurface). Для работы GUI библиотека Qt теперь является обязательной
освистал.
Плохой, нехороший ход.
| | |
|
