Matlab usage is on a dramatic downswing from my vantage point in quantitative fiance. I don't really know anyone under 40 who uses it anymore as one of their main tools.
And I've never once seen anyone use octave as a substitute, I'm guessing this is mostly due to money for licenses not really being an issue.
Nowadays, the only tools I see people using are R, python(pandas, numpy) and very occasionally Julia.
Where does this leave Octave? What's Octaves niche?
Or put another way, why learn Octave/Matlab when there are other languages out there that provide similar capabilities and that are much more popular?
In the Stanford/Coursera machine learning class, Andrew Ng said that his teaching experience is that students pick up octave/matlab quicker and the course can cover more actual machine learning, compared to python where more time is spent learning the language.
So I guess for newcomers and for quick prototyping (just 10s or 100s lines of code), octave is nicer.
Say, you have some numbers for a matrix and a vector in files and want to read them in and multiple the vector by the matrix.
In octave you are done in 3 lines of code in 30 seconds.
In python, you first figure which modules to import, the difference between python arrays and numpy arrays, and god forbid you happen to find the numpy matrix type instead of numpy array type. After 5 minutes you think you're all set to calculate the M * v, but then your vector happens to be a line vector and not a column vector and you need to learn the difference. Also it's nicer to write M * v than np.dot(M,v).
Most of the features of python that I presented as cons are actually pros when the codebase is more than 1000 lines and needs structure and safety.
m = [0 1 0; 0 0 1; 1 0 0]
v = [2 3 1]'
m\v
ans =
1
2
3
Python:
import numpy as np
m = np.array([[0,1,0],[0,0,1],[1,0,0]])
v = np.transpose(np.array([2,3,1]))
# wtf? oh, I guess then
v = np.transpose(np.array([[2,3,1]]))
np.linalg.solve(m,v)
array([[ 1.],
[ 2.],
[ 3.]])
If you just want to play around, Python has more clutter and gotchas.
Of course, when you start to write real software, then the tools that Python provides for organizing your code start to weight more and the clumsiness of np.linalg.solve(m,v) over m\v starts to weight less.
But I can see how a 50-line testing script in Octave organically grows to a 2000-line application, and then it's already a lot of work to rewrite in Python.
Edit: a reply below makes a good point simplifying the Python code a little bit.
I mean in the context as @sampo described it above ...
In the Stanford/Coursera machine learning class, Andrew Ng said that his teaching experience is that students pick up octave/matlab quicker and the course can cover more actual machine learning, compared to python where more time is spent learning the language.
Then "which version of Python, and how is that different..." etc.
I think that's kindasorta of reason for Ng's preference: students will focus on the subject of machine learning and not spend time on the ins and outs of Python and Numpy (or these days TensorFlow). It's the same sort of pedagogical approach that keeps SML as an active teaching language.
When someone googles Matlab/Octave there won't be the same mixture of contexts as there is for Python. With Python there's "2 or 3?" before even starting. Than Cython or Jython or PyPy? That's nothing against Python except that in one particular time limited context, the questions are a distraction {without even considering the complaints of students when the choice of Python implementation is contrary to their opinion}.
I'll throw my experience onto the pile of anecdotes in support of Ng's opinion.
I've done both his Coursera class and another ML class that used Python. I started the one class with zero Matlab/Octave experience, and the other with some Python but no real Numpy experience.
Getting comfortable with Octave for doing basic vector/matrix operations took very little time, and within an hour I was able to just focus on learning the math. By contrast, I've been using Numpy on-and-off for a year now, and I still feel wedded to the reference manual.
Keeping track of all the @$@#% types is definitely a chore. There may be technical advantages to doing things that way, but that doesn't make it any more learner-friendly. Nor does the Python community's habit of not bothering to specify types in the documentation help things in that department.
I'm with you. When you are doing things as your day-to-day learning the syntax and gotchas associated with whatever language are pretty easy, but when you come at it every once in a while working with Octave or Matlab are so much easier.
I can see the benefit that tooling provides, but from a getting-started standpoint, reducing the complexity makes you significantly more productive. You can concentrate on learning the concepts and not the language nuances.
For someone who already knows and works with numpy or r, Octave might not be necessary. Then again, it's not like its particularly hard to pick up Octave and be able to work with it.
I took the EdX/MIT course[1] on optimization methods and constraint solvers using Julia and JuMP and it was really fun.
Julia wasn't around, or it was very early, when he designed the Machine Learning course or was teaching Stanford students, and he's moved on since then. I wonder if he would likely choose Julia now.
I like R, but understand that %*% for matrix multiplication, solve() instead of \, and the relatively cumbersome syntax for defining matrices indicate that it not designed primarily for users to interact with matrices at a lower, mechanical level. The xapply() functions can also be more confusing than picturing how you iterate through loops. Python too can be verbose for doing the simple/toy problems that are helpful when learning.
Julia however comes with the easy Matlab/Octave syntax for handling matrices. But then there is a lot of of syntactic sugar too after you get past the early stages. Even things like the built-in support for intermixing Greek letters were surprisingly helpful.
I think the advantage of Matlab is the toolboxes in engineering contexts, but that Julia has a similar learning curve for beginners working with matrices. Perhaps the Matlab IDE is an advantage, but that doesn't come with Octave, and Jupyter or Atom+Julia are relatively user-friendly.
Matlab and Octave have multidimensional arrays built in. Few modern languages do. C, C++, Python, Go, Rust - no built-in multidimensional arrays. (Arrays of arrays are not the same thing.) There are lots of array packages, but they often don't talk to each other. Classic Python gotcha: "+" for Python arrays is concatenation, but for NumPy arrays, it's elementwise add. Mixed-mode semantics are complicated.
Simply not having to worry about how to represent a multidimensional array is a win. This keeps FORTRAN alive.
"Matlab and Octave have multidimensional arrays built in. Few modern languages do. C, C++, Python, Go, Rust - no built-in multidimensional arrays. (Arrays of arrays are not the same thing.)"
What is the difference? I was thinking about this just recently (in connection with Python and C). But not clear on the diff (for either language), though I know that internally all arrays have to be represented as 1D sequences of bytes in memory, and the translation betwen 1D and say 2D (for 2D arrays) is done by adding and multiplying indices, offsets, etc. Is there any more to it than that? Interested to know.
There are performance, and in some languages, safety issues with arrays of arrays. Arrays of arrays can be ragged - not all the rows need be the same length. Languages which do subscript checking have to deal with this, and usually can't hoist subscript checks out of inner loops.
Allocating an array of arrays can require a lot of allocations, as does copying such an array. This gets expensive if you have some language where arrays are first-class result types. You can't just do one allocate, then copy the entire array.
The C idiom "a[i][j]" has become pervasive, replacing actual multidimensional array subscripts such as "a[i,j]" (Pascal, Modula) or "a(i,j)" (Octave, MATLAB and FORTRAN). Amusingly, you can't overload "operator[]" in C++ with more than one argument. It's a syntax problem. The comma operator (the "evaluate but ignore first operand, return second operand" operator) has higher precedence inside "a[]" than inside "a()". This is a legacy from C's use of the comma operator inside macros.
In the Stanford/Coursera machine learning class, Andrew Ng said that his teaching experience is that students pick up octave/matlab quicker and the course can cover more actual machine learning, compared to python where more time is spent learning the language.
This seems to be a special case of teaching a course where the students come from diverse backgrounds, having learned different programming languages or none at all. And in any course that involves some computer based activities, it's always good to avoid the situation where fussing with the tools overshadows the content that's being taught.
In this case, a language whose notation mimics the notation being used to describe the math on the chalkboard, is certainly handy. And I appreciate that he's offering a way to do the work without requiring a commercial or platform-specific tool.
I'm not sure it means that Octave is nicer in general, but I can certainly see the appeal if it's well integrated into a well designed course.
You are exactly right about the pros and cons of Python. It is a general-purpose language that introduces frictions that paying for by around 1000 loc.
But MATLAB not perfect, it has spiky bits and traps for newbies. (And the feature that '' == matrix multiply != the multiplication you almost always want is one of those traps). Also students will* write complicated (perhaps overcomplicated) programs that expose MATLAB's limits.
So what about other languages designed for numerics? Would R be a better choice (I haven't used it). Or maybe a new language should be invented. After all Matlab might be easier overall, but it still has plenty of stupid spiky stuff. And I would count your multiplication example as one of the (milder) stupidities.
Octave user under 30 here.
I picked up a Matlab project recently (pattern recognition, electrical engineering etc. heavily use it in my university).
Because I wanted to run it on Amazon and didn't want to deal with all the licensing issues I ported it to Octave instead.
Works like a charm (using it in https://camfinger.com ) and it's actually free like any normal interpreter would be.
Personally I'm more used to other languages and would also tend to python, however I must admit Matlab/Octave is a pretty good way to develop matrix heavy stuff thanks to an extremely good REPL/debugger.
That being said, Octave feels pretty slow for loops (lack of a proper jit), so I wouldn't know if I'd really use Octave over Matlab if it were not for licensing issues either. Then again I can rent a lot of cloud time for a Matlab license...
Turbo Pascal really set the standard for IDEs that would run on consumer machines (as opposed to workstations). The compilation times were near zero, even on my 12.5MHz AT. Switching to Turbo C++ was a huge step backwards in that regard (AMD 40MHz 386DX, hit compile, go play Frisbee for 15 minutes).
Yes, Turbo Pascal was blindingly fast - I could type almost as fast as I could think :) (I mean, even though incrementally compiling my code every few lines) - equivalent or better than a scripting language - at least for small to medium-sized programs. Fantastic for exploratory programming and learning and correcting as you go, though also for bigger, less exploratory stuff. I don't think I've met its match to this day. I read that the Borland developers who created it wrote it in tuned assembly language.
Turbo Pascal was the best, for that time. Unfortunately it didn't really set the standard, as no IDE I've used afterwards has ever been of comparable speed, without any lag anywhere ;)
I've drifted away from the field, but last I heard Matlab is still a really big deal in digital signal processing and modeling RF signals and systems. There are e.g. toolchains to start with Matlab code and end up with a synthesized filter in an FPGA. Octave can be used as a stand-in for Matlab when you need to fiddle with some Matlab code but don't necessarily need the full-blown infrastructure of Matlab's "toolboxes", or when you're just learning the fundamentals of programming in a Matlab style. NumPy can fundamentally do the same stuff at this level, but the syntax for basic manipulation of vectors/matrices is significantly clunkier. This isn't a big deal when implementing a known solution, but for little REPL sketches and experimentation it's definitely been noticeable to me.
Then if you take an upper div class like EE120, Linear Systems, the homework sets will be in Matlab. We used it again in EE192, Mechatronics. Non engineering students (CS students) will have to pick it up immediately. I'd have preferred using Octave on my laptop rather than Matlab which was installed on Windows machines.
There's an auxiliary reason to use Octave/MATLAB that most people don't talk about. Vastly cheaper access to high quality linear system solvers. Writing high-performing, multicore factorization codes is hard and only a few people do that well. For example, that's been most of Tim Davis' career. Anyway, codes like CHOLMOD are dual licensed GPL/commercial. If I want access to that solver, but I don't want to GPL my code, I can write a Octave/MATLAB routine that uses the `chol` command. Implicitly, this uses CHOLMOD on both Octave/MATLAB, but it's baked into the interpreter. Now, MATLAB has paid the appropriate license for access to the routine, whereas Octave just abides by the GPL. If I deliver a piece of code to a customer that needs this routine, I just tell them they need to use MATLAB because they provide the license cover. If my customer chooses to use Octave instead, that's not my choice. However, even if they do, GPL only kicks in if they externally deliver their code. It's this weird situation where I can legally deliver code because it's fine under the MATLAB license, but the end result will work under Octave, which can be used freely under GPL. Anyway, there are a huge number of solvers where this occurs. Something like Python is fine, but I'd be very careful with the licensing if anyone intends to distribute under a non GPL license since a large number of the good numerical libraries are dual licensed GPL/commercial.
That's an interesting effect of dual licensing, but I'm not sure I understand it right. If you write a routine that uses the `chol` command, that's not a derivative work of chol, is it? It's just a function call, which is a normal use. It seems like if you give someone this routine but don't give them CHOLMOD, they can use any implementation of that function signature they wish.
But maybe since it's an oct-file (or I imagine a mex-file in MATLAB), it's baked into the interpreter and it's a different story.
I'm a huge fan of Python and I use it for everything (to put it mildly, I've spent weeks translating MATLAB code from other researchers into Python simply because I believe Python is far nicer to work with), but I must say that in my experience SciPy's numerical libraries are still fairly inferior to MATLAB's own (it may have to do with the $2000 price-tag). Even simple numerical root-finding and integration of one-dimensional PDEs is nowhere near the caliber of MATLAB's.
Perhaps the most time-consuming thing I've found is that, to get NumPy/SciPy to work for some scenarios, you can spend your time tinkering around with a bunch of different parameters whereas the same functions work directly out-of-the-box on MATLAB. Rarely have I found the opposite to be the case, and I know this is the reason a few researchers I work with still don't use Python for their internal work.
Perhaps I can cook up a few examples from my projects, just to make a fair comparison.
I've found that emacs + orgmode and liberal usage of sessions in code blocks superior to jupyter. That said, I don't see it taking off pretty much ever. :(
Sorry for my ignorance. What's the usage you give to those tools? What's your domain? And finally, how to get started with them? I'm highly interested on Data Science but it's hard to start, there's so much stuff going on.
You didn't ask me, but I use the same tools in my work. If a scientist tells you they're using "Python," there's a good chance they're referring to this stack, possibly without knowing what's under the hood.
I'm a scientist working at a private company that makes measurement equipment, and I use Python for practically everything now: Modeling, data analysis, and even talking to hardware. Our engineers have been kind enough to provide Python friendly interfaces to our hardware, so I can write things like test scripts that are used in product development and sometimes in manufacturing. I write similar scripts when I'm prototyping hardware myself.
I write some stand-alone Python programs, when it becomes convenient to provide a GUI (via Tkinter). I also use Jupyter quite a lot for data analysis and exploratory work. Often, I use a stand-alone Python program to generate data, and a Jupyter notebook (with inline Matplotlib graphs) to analyze it.
At another level of abstraction, I now use Jupyter as my lab notebook. Just last week, I completed a fairly extensive study that included development of a prototype, automated testing, and data analysis. When I was satisfied with my results, rather than writing a separate report, I simply added explanatory text to the Jupyter notebook, with some cell phone pictures for documentation. And then I scheduled a meeting to present my results. My presentation was a slideshow that was served up from the same Jupyter notebook using the nbconvert utility.
Even though my work will never be revealed to the public, I have embraced the idea that "real science is open and reproducible," and am pushing towards an ideal state where a single file folder contains everything needed to reproduce my work, including hardware design, source code, experimental data, and so forth. I'm also learning to use git, so that this stuff can all be revision controlled.
If someone asks me for help getting started with Python, I suggest that they should get Anaconda, or an alternative that I prefer called WinPython.
Unfortunately, I might be a bad person to answer that question. I'm 52, and have been programming since high school, not as a professional developer, but just using programming as a tool. So I learned data analysis long before learning Python, just through my general science education and work. The result is that I don't really know what a good modern tutorial is.
The old timers would just hand you a copy of Numerical Recipes and wish you good luck. ;-)
It depends on what kind of analysis you're doing. If you're doing pure exploratory stuff on large datasets, you'll mostly be using NumPy as a tool to help with Pandas. See McKinney's Python for Data Analysis (I believe it's from O'Reilly books) if you'd like a fairly good intro.
If you're more like me on using numerical methods, then I'd recommend first going through the math (I can be more specific, depending on what kind of work you'd like to do/are interested in) using Julia/MATLAB/Octave and then jump into NumPy stuff.
In my experience, I've found that using NumPy/SciPy numerical libraries effectively requires some knowledge of the underlying numerical algorithms since the default arguments sometimes require tweaking.
You might want to try installing anaconda[0]. After you have installed, follow the instructions here[1]. There are also lots of videos in youtube if you have not yet done a little bit of googling. By the way, this all requires that you know how to code in python else you can get your hands wet here[2].
Now if you already know how to code in python and know how to use jupyter, you're ready to learn about neural networks. This book[3] did a really good job in explaining the subject.
Mathworks/Matlab is heavily entrenched in the engineering departments of most US universities. So students get free Matlab access in the computer labs and heavily discounted student versions (or pirated copies) on their personal computers. As a postdoc I attempted to push Python into the curriculum but professors are just much more comfortable with Matlab. I never met anyone who actually used Octave.
Matlab's out-of-the-box IDE is good and makes debugging/profiling dead simple, the toolboxes cover a huge range of problem domains, and the language itself is easy to learn. But I've moved away from it due to the cost, licensing, closed source, etc.
I use Python. I have an interest in Julia, but the language stability and ecosystem just aren't there yet.
A lot of online engineering courses use Matlab, generally where there is more emphasis on learning the algorithm than the programming. Matlab a lot of different specialized toolboxes like DSP. I've taken several courses over the last few years and it seems like they are about 50/50 matlab or python. The very popular Machine Learning course on coursera specifically uses octave. Usually Matlab offers a short term license for anyone signed up for the course. I think the thing about Matlab is there is not that much to learn if you just want to do some computing and are not trying to create any sort of reusable program. Also it can be simpler to setup/install than say ipython and numpy (again for a classroom environment)
There will always be a need to run legacy code. For example Dynare (http://www.dynare.org/) is written in Matlab and has established itself as a standard tool for solving and estimating a certain type of macroeconomic model. The authors have been careful to ensure that it works with Octave as well, which I appreciate as someone working in an institution with a limited budget. I teach my own students Python, but as people entering the profession at this point, they should be able to use Dynare as well.
I learned Octave from the Andrew Ng ML MOOC and since then, I like to use it occasionally as an advanced calculator. It's pretty handy to quickly run on the command line and play around with some ideas, but for anything that involves more than a throwaway script I'd most likely switch to a more "serious" language.
What I will say is that I really enjoy using Octave, just because with a certain fairly narrow domain it's quick, powerful and there's no messing around with dependencies to get going. It's very immediate, which is exactly what I want from a calculator.
I've seen this use case: develop interactively using Matlab on a local machine, and then run a bunch of instances concurrently using Octave. You get the ergonomics of developing in Matlab, but you don't need hundreds of licenses.
Tons of legacy code. I'm in academia and in some research areas Matlab is so deeply entrenched that it will take decades for Python or Julia to replace it. Not sure though whether all this code runs under Octave.
My work (Industrial Plant) has a pretty good cross-section of engineering disciplines. I know Electrical guys use MatLab relatively frequently. I can't say for sure what the mechanical guys use I know 2 or 3 that write C code very proficiently. Chem eng. guys are pretty heavy on Fortran from what I have seen.
I'm a Materials engineer never used Matlab. For numerical stuff I have personally used C/C++ especially GSL library but I rarely do this type of work any more. There is quite a lot of legacy stuff written in Fortan mostly heat transfer and fluid dynamics related. I try to avoid touching it. Commercial Packages like ANSYS get used a lot.
I have seen python a little bit in last couple of years but not for numerical stuff more for interfacing with other libraries like OpenCV.
Well Matlab is still a very popular among Engineers who are usualy more conservative than CS guys. And they are not convinced to switch to the other tools cuz Matlab is still good enough so it is not worth risking to loose their legacy codes as a consequence...
Bear in mind that you'd have to rewrite both Matlab and GNU Octave if you need to run your simulations on a super computer.
I remember back when I was a first year I was waist-deep in some Matlab when one of the guys at our high-performance computing center jested that if I wrote a for-loop I may just as well run around the building for each iteration and do the calculation with pen and paper. (context: members of the same computer club)
The tendency to write Matlab that's several orders of magnitude slower than equivalent Fortran isn't the only reason to try to keep it off HPC systems. There are crazy (and inconsistent) licensing conditions applying to running on clusters for one.
Even if you can find the money, I'm told by people who support Matlab on our systems that it isn't very effective and doesn't fit well with HPC resource management.
As an electrical engineer (focusing on signal processing), Matlab appears to me to be the overwhelmingly dominant tool in my discipline for prototyping algorithms and performing analyses. Recently, though, there has been a resurgence of interest in Python (with SciPy, NumPy, and Jupyter). I'm not sure if it outstrips IDL in popularity yet, let alone Matlab.
For me, personally, I use Octave at home when prototyping algorithms because I'm cheap and haven't paid the ~$1k for a Matlab license.
In my experience for real-time implementation, neither Matlab nor Python are considered efficient enough, even after using something like the Matlab compiler or Python's psyco or equivalent. Again, in my experience, C is by far the most popular choice.
With regard to learning Octave and/or Matlab, I'd say people learn it because of inertia and that they're well-tuned for numerical analyses. I say this even though Python's my favorite general-purpose language. I still prefer Matlab/Octave over it for crunching data because, to me, they seem better designed for that purpose.
> In my experience for real-time implementation, neither Matlab nor Python are considered efficient enough, even after using something like the Matlab compiler or Python's psyco or equivalent. Again, in my experience, C is by far the most popular choice.
MATLAB Compiler won't make code any faster - it's still just running MATLAB engine underneath the hood. MATLAB Coder converts to C code optimized for real-time systems
Whoa, thanks for that link. IIRC quite awhile ago there was a student edition that wasn't really suitable for anything other than toy problems because there was a limitation in the size of matrices. This looks to be the real deal though!
> MATLAB Compiler won't make code any faster - it's still just running MATLAB engine underneath the hood. MATLAB Coder converts to C code optimized for real-time systems
My mistake: the particular toolboxes often fuse together in my head. Not such a big deal at work where we've got access to so many of them. It'd definitely be a pain if I didn't. My point still stands, though, that I haven't seen anyone on any of the projects I've worked on using MATLAB code that's been automatically converted to C. Or, at the very least, it's not part of any documented process that I've seen.
No kidding. Especially for Windows users, just figuring out what version of Python is needed and getting it set up with all of the dependencies required by the application is daunting.
What Matlab brings to the table is a customer-centric focus... meaning an awareness that the customer probably has something to do this week besides screwing around with open source scientific computing packages and their inevitable dozens of scattered dependencies.
As for Octave, it's useful for absolute zero-budget applications at the very low end of the market, and for mass deployment of multiple instances at the high end, but it doesn't have much of a role in the middle. The "home use" licenses introduced by Matlab recently really dropped a bomb on Octave. You can get a ridiculous amount of nifty stuff for less than $500.
...eh. I mean Mathworks might not be thaaat diligent but "For personal use only. Not for government, academic, research, commercial, or other organizational use"
Like I mean what the hell does that leave for "personal use"?
I think it's more of a "Here, now you don't have to warez our stuff" kind of license.
Technically the intent was for self-directed personal education. But the real reason is to encourage people to learn Matlab, and not Numpy or R or something else, and to discourage people from messing around with Octave. It's a classic move for a company that's getting worried about their market share.
Given that most of the value of Matlab over Octave lies in its toolboxes -- which are now $45 each -- this strategy seems sound. A few packages still aren't available, such as the toolbox that does HDL code generation, but those aren't available in the FOSS world either.
Thank so for that pointer about Matlab home use. I had missed it. I have a license through my employer, but being able to goof with it at home could be worth it. $150 for Matlab and $45 for toolboxes.
No joke, scientists from Canada. I'm a Mathemstica fan myself, but among scientists from Canada the Maple/Mathematica split seems roughly 50/50. I'm guessing it is popular in Canadian Univerisities.
When I was in CEGEP (2 years of pre-university basic science and general ed college, specific to Quebec), we used maple for exploratory symbolic and plotting kind of work in math classes (calculus and lin alg).
In university (engineering school) they taught us MATLAB in the two required introductory programming classes. In grad school I took an advanced numerical methods class where the prof was actually cool enough to let us use whatever language we wanted. I took the opportunity to learn python/numpy.
>Or put another way, why learn Octave/Matlab
Because:
1. they are really simple and closer to math than programming languages
2. there is a huge codebase and many toolkits.
3. Matlab can be very fast
They changed the title. I hope even with the title change, people are aware that the website design is new, which is why I submitted the URL. We also just released a 4.2 version on Thursday, with many improvements, but no huge features like the GUI was for 4.0:
Very happy to see Octave move forward. Few years ago my colleagues at the university complained about Octave not being on par with MATLAB performance-wise, has this improved since?
The biggest hit in performance that people see is the lack of a JIT compiler. If you are able to write your code without loops, Octave performs comparably to Matlab. No, we still do not have a JIT compiler. It is difficult to attract this kind of talent, because the kind of people who use Octave know mathematics and engineering more than they know compilers and languages.
No. The biggest hit is not the JIT.
Octave has less support for SIMD operations whereas Matlab uses Intel's propriority Math Kernel Library.
You will realize that Octave gets significantly slower in matrix and vectorized operations, where JIT doesn't help much
Octave is more or less BLAS-agnostic. You can build it with any BLAS, including MKL and people do this (but because MKL is too restrictive, you can't redistribute the result). While you may see speedups this way, if your code isn't vectorised, as most code out there is not, you still will see big slowdowns.
Along with the myths about performance, the licence for the Intel stuff isn't what many people think... Anyhow, there's no need for MKL, since at least the operations that matter are as fast in OpenBLAS on x86 up to AVX512 (and infinitely faster on other architectures). You can get that with the Debian packaging of Octave, for instance, and you can fiddle it system-wide on RHEL/Fedora.
Thanks for working on Octave. I wish people would put money into it rather than (in the case of my university) paying enough for Matlab to fund one or two full-time staff who could do development and support of free stuff with Octave and other things like R. Multiply that by N universities in just in this country...
I haven't studied the MKL license, but in the python world, Christoph Gohlke is kind enough to freely distribute some python packages (notably Numpy and Scipy) built with against MKL.
We have a toy LLVM attempt that compiled a few trivial loops but hooked into the unstable C++ LLVM API. Nobody really knew how to maintain it, and we got tired chasing after the unstable API, so we let it bitrot to death.
I don't expect any other JIT backend (libgccjit could be another possibility) would require any less knowledge of compilers and language design. Does Graal have some magic for us? Can it give us a JIT compiler even if most of us are not compiler writers or language designers?
Forget “this language is fast”, “this language has the libraries I need”, and “this language has the tool support I need”. The Truffle framework for implementing managed languages in Java gives you native performance, multi-language integration with all other Truffle languages, and tool support - all of that by just implementing an abstract syntax tree (AST) interpreter in Java.
Truffle applies AST specialization during interpretation, which enables partial evaluation to create highly optimized native code without the need to write a compiler specifically for a language. The Java VM contributes high-performance garbage collection, threads, and parallelism support.
So you won't need the know-how to write a compiler, but instead write an interpreter optimized for execution with Graal.
What kind of work and skills would it take? I would be free this summer and am looking to contribute to a good and worthy project (just for kicks and the bragging rights).
I don't know of that. But with Pytave, which is fairly mature now, you could embed some Octave computations inside a Jupyter notebook. I haven't seen anyone do this yet with a lot of seriousness. There's also Kantor and TeXmacs which both have used Octave as a possible backend. I haven't checked recently to see if they've been well maintained.
I'm really grateful that octave exists and that folks let me use it for free. But the part about "Drop-in compatible with many Matlab scripts" has been kind of dicey for me. Whenever I try to run code developed with matlab using Octave I am thwarted by bugs and stubbed functions. I end up either having to find a machine with a matlab license or just port it. The core functionalities for doing math and matrix-ey stuff seem great, but when I start pulling in a bunch of libraries to do less common things, the wider ecosystem doesn't seem as fully baked as, for example Python or R.
Great stuff. I did grad school on Octave (and a bit of Maxima) rather than Matlab; I'm glad my alma mater (Boston U.) was supportive of free software and the professors allowed that.
I saw the version bump on info-gnu the other day; I haven't updated yet (I'm kind of in the middle of a project using Octave) but once that's done I can't wait to try it out.
Like many posters here, my first exposure to Octave was from taking the Andrew Ng class on Machine Learning. For myself, I have to say that I was pretty impressed with Octave. It does a lot of what you can do with R, but I find the syntax more accessible. I get the feeling that there aren't quite as many packages/libraries available for Octave as there are for R, though. Still, I find myself using Octave from time to time, when I need to do some quick calculations or whatever. I even bought a Matlab book, intending to invest a little more effort into learning this ecosystem.
Glad to see Octave development is ongoing. It'll be fun to check out 4.2.0 and see what it has to offer.
MATLAB was kind of my "first love" as an undergrad in biotech engineering, for simulating biochemical network in a course.
I have since drifted away towards python, and lately Go, but MATLAB/Octave always has a directness that I think few languages since have managed to achieve, and I realize now that it helped lure me out of web-lab, into into coding and bioinformatics-land.
Only one person has mentioned what I think is a critical distinction. MATLAB + Simulink + Coder Products = hundreds of man-hours saved in the engineering design-development-prototype-deploy process. Obviously this is not as relevant to academics and CS, but the thousands of $$$ spent on the tools is made up many times over in saved highly-trained man-hours.
Core Matlab/Octave is great but almost inevitably you end up needing/wanting toolbox support. For Matlab the cost gets up there quite fast. I've found for Octave, support at the toolbox level is not as extensive. If Matlab is not an option it leads to searching for support in other languages. OpenCV for image processing/understanding and the python libs as mentioned become important for example. But development cycle time is longer and prototyping algorithms is a bit more complicated.
Its been a while since I've worked with Octave toolboxes but it would be great if they were on par with Matlab.
Performance is less of an issue with prototyping than production systems and Matlab has a path to get to compiled C/C++ (Java and perhaps other?) Is there Octave support for generating reasonably performant C++ or Java?
>Visualize data with high-level plot commands in 2D and 3D.
And wait an eternity for anything 3D to render. I usually use Octave for prototyping, and while it is reasonably fast doing calculations once you learn to vectorize computations, plotting moderately large amounts of data can easily block the entire program.
There is another GPL Matlab compatible system called FreeMat, which doesn't get as much as love as Octave (which itself does not get as much love as it should) - http://freemat.sourceforge.net/
I used Octave and Matlab back and forth last year for my Computer Vision class. My experience on Octave was fine except it is increadibly slower than Matlab...
The nice thing about Octave is that it is a portable program that you can store it in a USB memory then use it anywhere.
anecdote: last time I tried Octave, like half a year ago, it didn't want to plot anything and had to be killed after issuing a plot command. Previous time I tried it, maybe a year ago, I didn't have that problem but it didn't run all my matlab stuff (nor did I expect it to). So Octave for us was basically: either a maintainance burden if we want to keep all Matlab stuff running on Octave as well, or else a seperate codebase, combined with possibly severe problems in the basics; which might be easy to solve but do require time looking for a solution. So we switched to Python then (requirements for this particular project were just pretty basic line graphs) and didn't look back.
It's a lot more suited to mathematical problems than Python. Python wasn't designed for matrix manipulation like Matlab was so the syntax isn't nearly as nice. Matlab also has a huge library of maths functions built in - even really obscure ones. Finally Matlab has a nice GUI and plotting support built in which Python doesn't have. Basically Matlab is almost strictly better than Python.
The only advantage Python have that I can see are: a) it has better support for non-maths functions - good luck doing OpenGL in native Matlab (although it does easily interface with C++ and Java), and b) it is free; Matlab costs a lot, although they did actually release an affordable 'personal' edition.
Octave is basically a Matlab clone. It's slower, has a less polished GUI (plotting is especially buggy) and is less comprehensive.
c) Python is a rather nice language to program in, matlab feels archaic/verbose/... and misses a lot of things of more modern languages. It's good at math, but there it sort of ends. Also because it's aimed at math, good luck finding tutorials teaching programming basics, best practices, design patterns. Likely the reason why 10000 line files with up to 20 indent levels are no exception in the world of academia (ok the trainwreck of an editor might have to do with that as well). I have no proof of course, just a feeling this would occur less easily with Python.
Ok and Python doesn't have numpy/plotting literally built-in but if you start with Miniconda or so you get one package which has it all.
Matlab usage is on a dramatic downswing from my vantage point in quantitative fiance. I don't really know anyone under 40 who uses it anymore as one of their main tools.
And I've never once seen anyone use octave as a substitute, I'm guessing this is mostly due to money for licenses not really being an issue.
Nowadays, the only tools I see people using are R, python(pandas, numpy) and very occasionally Julia.
Where does this leave Octave? What's Octaves niche?
Or put another way, why learn Octave/Matlab when there are other languages out there that provide similar capabilities and that are much more popular?