[arca_vorago]

I'm not a math guy, but I am a GNU guy who wants to learn more, and I'm curious what all the math geeks think about GNU Octave? How does it compare to matlab and mathematica? Any quitks or catches that make it unusuable for certain situations? Stuff like that...

[chestervonwinch]

Octave is nice, and it compares well with matlab in my experience. However, I haven't used it in quite some time, as I switched from octave+gnuplot to the scientific python stack some years ago (and I prefer it immensely).

[arca_vorago]

I've heard quite a bit of preference for the python stack, any reasons that come to mind? Is it just the usability of the language or what?

[travisoliphant]

Everyone has their own story around this. For me, the reason I did not go with Octave when I chose to migrate from Matlab to Python was that I wanted to be part of a general-purpose language community. Octave had the nice advantage of being very close to the Matlab syntax --- which has some nice properties (e.g. easier matrix-math expressions and matrix-building expressions)

However, I felt there would be more innovation around the programming language itself (think decorators, generators, futures, compilers, and coroutines). The boundary region between "applied-math-programming" and general purpose computing requires a lot of sometimes tedious work. Having a general purpose computing language would mean that more people would be available for that work.

Even now, one of the principal challenges of NumPy which is the foundation of the Python scientific stack is that it combines applied math (fft, linear algebra, polynomials) with computer-science (type systems, data-structures, and multiple-dispatch functionals). Maintaining all of that with one group of people is difficult.

If we could re-factor the NumPy code base into 1) a data-declaration type system --- i.e. look at datashape.pydata.org which is a generalization of dtype, 2) a multiple-dispatch generic function system (the ufuncs) and then 3) a container object. These could all be maintained by separate groups (and even #1 and #2 could be pulled into the Python language itself). See the libdynd project for a reference example of what it could look like.

Then NumPy could be maintained as a set of math libraries on top of that.

Then, it would be relatively straightforward to build the octave DSL on top of the Python computing stack and we would be able to share work.

[tanlermin]

I can't overplay the importance of a octave like DSL.

Julia is gaining marketshare and mindshare among grad student not just due to its speed, but because it is a more fun and intuitive environment in which to code mathy stuff.

These people will in turn filter into industry and if not them, then atleast their code.

Also macros. As Julia gains more utility for run of the mill data science, Its Dplyr like DSL abilities will be very attractive.

Do you see this type system and generic function library as useful for general purpose programming as well? How would that play with mypy and type hints?

[xcombelle]

I have hard time to understand what you mean (begining at if we could refactor ...) can you give examples ?

[GFK_of_xmaspast]

I think the only reason to reach for octave is if you've got a ton of matlab muscle-memory or have some kind of external force influencing you to use matlab and don't want or can't afford the license.