GNU Octave
octave.org
octave.org
I also wish the state of science/engineering software shook out differently. There's plenty of money to pay Mathworks. Is there some kind of license like pay us if you're doing commercial work or publishing research on grants worth over $XXX, otherwise consider it open source?
The 0 indexing in python does really and truly suck sometimes though.
Now that's something you usually don't hear. At my university I heard a bit of "urban legend" about how back in the day (think early 1990's) a couple of professors got a peer-reviewed article published because they found out that Matlabs 1-indexed implementation of some algorithm resulted in numerical errors, which they measured and corrected. Don't really remember the details, and most of those involved have already retired.
The problem isn't whether 0 or 1 are "right" or not, it's the inconsistency. It makes transcribing something from a textbook harder, because the indexing logic in a textbook algorithm can get quite intricate. It's even worse if they use slices like M[i:j,m:n].
Indexing from 1 is the standard in many areas, going back many decades. SWEs have adopted a different convention.
It is inevitable to have to use both conventions if you do varied math stuff. Thus, you will never be happy.
So you end up having to translate from one-indexed derivations to zero-indexed code and it leads to different bugs. Ultimately zero-indexing just trades one layer of bugs for another.
IMHO zero-indexing makes sense to people thinking about the machine, not necessarily the work people are trying to use the machine to do.
To be fair sometimes the opposite is true and zero-indexing gives less complex expressions.
How about I drop a link about Einstein Notation with a curt observation that there are good reasons it uses both zero and one indexing simultaneously?
As I said it depends on how you are thinking about things. Indexing makes sense to people who are focusing only on the machine.
"The purpose of computing is insight, not numbers." (Hamming)
Machines and notation are both tools. Aesthetics do matter particularly for tools used for thought.
There is no correct answer and imposing one tool's limitations on everything is not useful. Particularly not "just because Dijkstra said so".
Sometimes 0-indexing works well. Sometimes it sucks. Sometimes 1-indexing works well, sometimes it sucks.
I did in fact give you a reference. The fact that it's irrelevant to you and dismissed as merely "aesthetics" and that you think a computer scientist is the domain expert of all science tells me everything that needs to be said--you never deal with questions of correctness beyond mere transcription.
What I said is that moving from Octave/Matlab to python's zero indexing sometimes does truly suck. And I mean it. That doesn't mean 1-indexing never sucks or that I am inaware of Dijkstra's opinions. Having to arange(1, N+1) or 1:N+1 or whatever everywhere isn't eliminating off-by-one errors.
Matlab and Octave and FORTRAN etc are domain languages designed for linear algebra. They are of course going to be more convenient for their domains.
Furthermore it depends on what you're doing with that first centimeter. In many instances the first centimeter is correctly considered to be 0.5
I find it easier not to make mistakes when I index from 1.
The issue stems from the word "index" in the sense of "to count" .. that the first cell is numbered 1 makes sense to some.
What is actually happening is measurement, or the offset from the origin of memory.
The first inch starts at zero on the tape measure and ends at 1, that first inch has an offset of zero.
For all manner of reasons to do with measuring memory as one might measure wood a great many people think in terms of memory offsets.
So every time I see `for i in range(10)`, I have to do the mental computation: I am repeating this operation on numbers from 0,...,9.
I would rather write `for i in range(9)` and know that I am operating on 0,..,9.
Exclusive upper bounds mean slices work neatly: a[0:10], a[10:20], a[20:30] etc. That's very neatly represented in a loop from zero in steps of ten. That pattern turns up all over the place when accessing arrays.
I've spent enough time in MATLAB to have been scarred by that kind of array slicing and off-by-one errors.
In many non-CS engineering disciplines Octave (and Matlab) is quite common. For doing everyday numerical calculations. Python and Julia do not compete with the simplicity of using GNU Octave.
Python I understand. The numpy notation sucks big time for translating straighforward notation of engineering disciplines and is a huge step backwards in readability; but Julia? That's a surprise. In fact the opening code in the Octave page can be copied almost exactly into Julia and it works.
It is really costly for a dept. to switch to Julia, say, as you would need all your colleagues (I teach applied maths and use matlab/octave) to make the switch lest you annoy the students (because ones learn one thing, others other).
I recently found Spyder IDE for Python which feels a lot like MATLAB. Despite my hate for MATLAB, I did at times appreciate the layout of the IDE and the way variables are still available after running a script. Spyder fortunately has a similar interface, except even better since you can restart the interpreter without restarting the IDE. I highly recommend it as a MATLAB replacement!
But truth be said, nothing so far quite managed to replicate Matlab syntax succinctness and ease - even if it’s a (unstated?) design goal of Julia.
- Fast, in an area where speed is important
- Can be made faster for repetitive tasks by communicating with a GPU using Vulkan, CUDA etc
- Can incorporate a GUI, and 3D graphics, which helps for exploring things visually, tweaking parameters, doing time simulations etc.
- Can share. Ie, I showed my brother yesterday by sharing a 10Mb executable. Matlab has license complications and you need it installed. Sharing Python programs is a disaster. (Docker? Pip? Pyenv? Poetry? Virtualenv? System Python? System dependencies for the C and Fortran dependencies?)Python is the big one, all of the aforementioned chemists are either intermediate or advanced in that. The runner-up seems to be Julia, which I personally have no experience with. The big guys are Fortran and C++. I prefer C for tasks of this nature, but I also shill Scheme so don't listen to my opinions on programming languages.
Best of luck on your computational chemistry endeavours!
Many people conflate their own irritation from hearing about the thing X often and against their will, with the quality of the thing X.
IMHO critical thinking and maturity demands that we make that distinction.
I have worked several times in Rust companies and their devs are extremely hardcore and very quiet. You couldn't tell these people are responsible for the technical operations and code of worldwide financial services.
So again, be a bit more charitable. Every community has its rotten apples. That says nothing about the quality of the thing that the community stands for.
Don't get me wrong, insufferable people still exist! But I no longer judge an entire community by them.
Or for simulating molecular motion, draw it out in 3D, with 6DOF FPS-style camera controls etc.
I imagine Pandas would be OOM too slow for this. Compared to Numpy, Pandas is, in my experience far too slow. Another speed limitation is Matplotlib's 3D plots make my computer crawl when rotating them etc; and they're not very interactive, at least on their own.
When dealing with these systems, a particular computational challenge is that they're 3D, so computation scales with precision^3. (This also adds complications to visualization, as I alluded to above)
* Fast - in many cases faster than Rust, although the difference is inconsequential relative to Python-to-Rust improvement I guess.
* _Really_ utilize CUDA, OpenCL, Vulcan etc. Specifically, Rust GPU is limited in its supported features, see: https://github.com/Rust-GPU/Rust-CUDA/blob/master/guide/src/... ...
* Host-side use of CUDA is at least as nice, and probably nicer, than what you'll get with Rust. That is, provided you use my own Modern C++ wrappers for the CUDA APIs: https://github.com/eyalroz/cuda-api-wrappers/ :-) ... sorry for the shameless self-plug.
* ... which brings me to another point: Richer offering of libraries for various needs than Rust, for you to possibly utilize.
* Easier to share than Rust. A target system is less likely to have an appropriate version of Rust and the surrounding ecosystem.
There are downsides, of course, but I was just applying your criteria.
Would also def benefit from the larger selection of C++ libs, especially for GUI and graphics.
Given the main computation issue is doing the same operation on many values in a 3D array, using the GPU more would be great. And my current setup for that is clumsy.
I disagree on easier to share. Binaries work the same either way. Compiling from source on rust is generally install Rustc, and do `cargo b --release`. Compiling someone else's code in C++ is... complicated.
Yes, that's possible with a combination of:
* Unified address space for pointers (and C++ references are basically pointers)
* Paged virtual memory on GPUs
... however, remember that many/most data structures which make sense on the CPU may not make sense to use on a GPU. And - NVIDIA very often implements and promotes certain features because they sound good in marketing, not because they're actually that useful. Or because they let you make a super-slow program into a meh-speed program, not because you would use them in a really-fast program.
> Compiling from source on rust is generally install Rustc, and do `cargo b --release`.
Well, I guess you may have a point, but let me still make a couple more arguments.
First, installing Rust (and related libraries/tools/whatever) is not trivial for people who don't know rust, and some OS distributions only offer you an older version of rust using their distro-package-managers. It's more likely that a C++ environment is already set up on someone's machine... TBH, though, if the distro is older, that might not be a perfect fit for what you're building.
Second C++ package managers becoming more popular, e.g. Conan: https://conan.io/ ; and that helps for when your OS distro doesn't cover you.
> Compiling someone else's code in C++ is... complicated.
This has actually improved a whole lot over the past... say, decade or so!
* Unzip/untar
* Configure the build with CMake (cross-platform build system generator - almost ubiquitous these days in C++ projects): `cmake -B build_dir/`
* Assuming you have the dependencies set up - it should "just build": `cmake --build build_dir`
* Run the thing from the build directory or install it with `cmake --install build_dir`.
... and if you want to tweak package options more easily than via the command-line, you can use a TUI (ccmake) or GUI (cmake-gui).
The problems start when you're missing dependencies, or if the author didn't make their code platform-independent / multi-platform.
Do you have any examples? AFAIK properly tuned rust and c++ will perform largely the same. Actually, Rust should have a bit of an edge due to the prohibition of aliasing. In practice it can vary if a standard library implementation is suboptimal or the compiler has suboptimal codegen into Bitcode but that’s generally going to be rare these days I think.
> Richer offering of libraries for various needs than Rust, for you to possibly utilize.
Are you talking for computational chemistry specifically or general libraries?. Don’t know about the former. For the latter I’ve found not only are more interesting libraries available, there seem to be generally high quality versions. Additionally, “cargo add xxx” is infinitely faster than integrating some random third party c++ dependency. Not to mention that C++ falls on the floor if one dependency requires transitive dependency X and another (or you) requires X at an incompatible version? Rust handles that elegantly where two different modules can depend on the same package at different versions without conflict without you needing to worry about it beyond the size of the executable.
> Easier to share than Rust. A target system is less likely to have an appropriate version of Rust and the surrounding ecosystem.
Again, haven’t that found to be my experience. Rustup lets you obtain any version of the rust tool chain, no muss no fuss. Additionally, it does a phenomenal job of not worrying about which compiler vendor you’re using (there’s only one) and more importantly there’s no versioning issues with libraries written against an older version of the language - 2021 and 2018. Oh, if you’re on windows, you also don’t have to worry about whether the target person has the right c++ runtime library version installed. With rust they just run the exe.
I wonder what's an equivalent of Eigen? https://eigen.tuxfamily.org/index.php?title=Main_Page
> if you’re on windows, you also don’t have to worry about whether the target person has the right c++ runtime library version installed
It's usually easy to build such binaries for Windows. That's a single combobox in project settings. Here's an example, just running the .exe works: https://github.com/Const-me/Whisper
2 seconds on Google yields:
https://rust-lang-nursery.github.io/rust-cookbook/science/ma...
https://docs.rs/GSL/latest/rgsl/
I have no idea the quality but you’ve also got bindings to more mature libraries:
https://docs.rs/lapack/0.14.1/lapack/
And https://www.erikpartridge.com/2019-03/rust-ml-simd-blas-lapa... is an overview from t years ago and does say it’s maybe not as good although not sure how much has changed in that time (eg has nalgebra matured sufficiently?)
It’s possible that Rust is lacking in good linear algebra libraries. I’m not as familiar with that space.
In principle, Rust has some overhead for being "safe", which C++ does not. Also, C++ benefits for longer period of time and more people working on optimizing its libraries and compilers.
> Are you talking for computational chemistry specifically or general libraries?
Ah, indeed, no. I have no idea which chemistry libraries are available for Rust and for C++. I was referring to scientific computing, algebra and other heavy-lifting work.
> Additionally, “cargo add xxx” is infinitely faster than integrating some random third party c++ dependency.
That's not one of OP's criteria. But - seeing how you like package managers, try `conan install /path/to/srcdir` from the build directory. For more details, read:
https://docs.conan.io/en/latest/getting_started.html
> Not to mention that C++ falls on the floor if one dependency requires transitive dependency X and another (or you) requires X at an incompatible version?
C++ is a language, it doesn't have dependency management. As for libraries, that situation is so rare - in my experience - that a chemistry person should not even be bothered to consider it.
> haven’t that found to be my experience.
Well, I learned something new today... I didn't know about rustup. Was it introduced recently?
Do you know of any specific safety features that makes rust slower? About the only one I can think of at runtime is that everything is bounds checked but that’s usually fixable in many ways (and technically c++ has that too except it’s applied randomly based on subtitle API differences like [] isn’t but .at is). As for quality of the standard library it’s hard to say. I haven’t found it to be bad. The HashMap implementation is better out of the box, a Vec/vector doesn’t really have anything special. File system APIs, error handling, modules, and async all feel more mature and polished (not performance per se but just overall completeness of the language). What is on your mind when you say that the c++ standard library is higher quality? Oh, and which of the three major implementations are you referring to?
The compilers story is actually even better because very little optimization happens in the frontend and thus a lot of the optimizations done for c++ apply to rust too. One specific way the language itself is better is that it disallowed aliasing so it’s closer to Fortran for numerical stuff and there’s various optimizations that c++ just can’t do. If I recall correctly that hasn’t been fully hooked up to the compiler due to bugs in LLVM but that will get resolved eventually. Overall, I’m not familiar with the claim that Rust code compiles worse than c++. About the only thing I’ve run into so far is bound checking showing up in hotspot code that I wrote non idiomatically because I’m still new to the language.
> Well, I learned something new today... I didn't know about rustup. Was it introduced recently?
1.0 is 6 years ago so not recent at all (not sure if there were pre 1.0 releases too): https://www.reddit.com/r/rust/comments/5iqsmg/rustup_100_is_...
Especially in Engineering (Mechanical/Electrical/Civil) Octave is not a substitute to MATLAB for the simple fact the former does not feature the various toolboxes useful to practicing engineers.
There's nothing like octave (or MATLAB) for scripting to "get shit done." There is a plethora of packages and tools to do whatever you need.
Need to import excel data and graph it? Octave is great. Need to connect to an sql database, pull data and export it? Octave. Linear algebra. Nuff said.
It's a great tool for engineers / scientists who don't want to "program" (although you can!) and want readable syntax to just git r dun. Also, there's a shit ton of m code floating out there on the internet and in engineering schools / university research groups. Octave isn't 100% m compatible but if you don't have a special tool boxes & functions you can get them to run in octave with a little debugging.
I love octave. It's gotten me out of a lot of binds.
Furthermore, the software philosophical aspect should not be underestimated. The more you realize what software can do and what powerful influence it has on our society in many ways, the value of a GNU Public License has increased for me.
(Even the FSF's name is unfortunate, IMHO. It's not an opportunity to tell the person you actually mean "free as in freedom", like some imagine. It's just starting people off with the wrong idea of what your mission is. And the result sure looks like most people went with the wrong idea, for whatever reason.)
In my opinion there isn't really anything that competes with MATLAB for the things it is really good at. Numpy is shit.
If you really can't afford £120 for MATLAB then I would say the next best option is Scilab.
Now we just need SOLIDWORKS to introduce a decent hobby license. They added one recently but it's subscription only so screw that.
Are you sure? The standalone version of Microsoft Office is more expensive at €150.
Windows is even more expensive, but of course most people get that bundled with their computer.
Wait, what?
I switched all my plotting in my thesis (5 years ago) from matlab to octave precisely because matlab plots were terrible.
Are you thinking of octave v3 from 15 years ago when it relied on gnuplot by any chance?
Octave is playing in a crowded orchestra, with the python scipy stack, the R and julia ecosystems, not to mention libraries in c++ like armadillo and eigen or even new projects in rust.
The funny thing is that in individual projects we like to apply DRY but we thinking more broadly, when solving numerical / computational problems there seem to be (too) many open source alternatives with significant overlap and duplication
No doubt all them have their pros and cons and optimal niches or historically strong points.
Ultimately though it might be an idea to somehow consolidate and coalesce around fewer and more mature stacks that have large use and development communities and which dont compete against each other for attention
Initially I hated the language but grew to like it.
Octave is an amazing open source/free software project.
Ye in the end I started to like it too. I mean, as long as you don't try to do string manipulations and mainly do numerical stuff it is a very nice language all the quirks be damned.
I knew I was side-tracking, but still I tried to refactor it a bit, to make it more acceptable. Modularization felt somehow shoehorned into the language though. Then the grader did not work any longer. Not sure it was because of my "refactoring" or because of the course platform. More likely my modifications, or that the grader checks the integrity of files one is not supposed to change.
After that experience I threw the course and did 2 other MOOCs, which taught with the up-to-date (back then) Python stack, which I found much more useful for real applications. However, in those 2 MOOCs I could already use the knowledge learned from the Andrew Ng MOOC, so at least in that aspect of teaching the actual theory, he did a very good job.
A bit offf topic, but is Matlab relevant still? I’ve heard it’s still in use a lot, but what’s the benefit of going with a walled off proprietary $$$ tool when you can use something like this? Python and R also seem like they’re growing so much and are very open.
I just remember taking a class on Matlab and being pretty disappointed in it with how closed it felt. Will totally check out octave tho!
Take a look at this for example https://www.mathworks.com/matlabcentral/fileexchange/49683-l...
My day-to-day stack nowadays is mostly Python with a smattering of others, but I’ve been using MATLAB for almost 15 years.
Like any other enterprise software, you’re paying for support and generally very good documentation. If you have a technical issue or even just a development question you get a response from a human within a day or two, often just a few hours.
There are also many domain-specific tools (e.g. Simulink) that do not have similarly functional open alternatives. Octave is great, but can lag behind new language features and generally isn’t 100% cross compatible. Whether or not this affects you is really dependent on your use case.
It's interesting how close GNU Radio Companion is getting to Simulink's domain. I don't know if that's their plan or if things are just evolving that way, but I like it.
Yes, in traditional industries. Robotics, automotive, industrial automation, and aerospace are using it.
From my experience in automotive, Matlab alone is not the sole selling point, but the proprietary tooling around Matlab for modelling, hardware-in-the-loop simulation and online calibration for various ECUs is unbeatable and saves the OEMs and manufacturers weeks or months of labor and debugging various platforms. And since it's the industry standard all automotive companies use it to collaborate on projects.
There's also the important fact that many users of these tools are not programmers. They could be mathematicians, physicists, chemists, designers, process engineers, test engineers, test drivers, test pilots, etc. and the GUI block-diagram based visual programing paradigm of Matlab tooling allows them to quickly understand, collaborate and iterate on various control schemes that learning how to code. If you're a test pilot or a process engineer, it's much easier to look at a Simulink block diagram and quickly understand the process going on, than to start reading python code.
There are no open source tools that can do all these things and nor is there a market for them as these companies don't mind sticking with Mathworks & Co. and paying them juicy license fees in exchange for getting the user-friendly tools they want that enables them to get the job done.
The network effect is also too strong to disrupt. Every company in the Michigan area serving the auto industry is running Matlab and so is every company in Stuttgart and Bavaria as most big OEMs have international offices in all these regions which must collaborate together. I assume it's similar in aerospace with the likes of Lockheed, Airbus, Rolls-Royce and many other of their suppliers are also deeply entrenched in the Mathworks ecosystem.
Basically entire industries, that don't get much air-time on the start-up focuesd HN, have standardized on Matlab. In a way, it's similar to the semiconductor industry that standardized exclusively on the tools from Synopys, Mentor Graphics and Cadence. Or how how the CAD industry is run by Autodesk, Siemens and Dassault. None of these players will be disrupted by open source alternatives any time soon. Or ever.
I think Python is superior, but perceived as difficult for non programmers.
A lot of programmer work is general purpose, create something new in a novel way.
A lot of non-programmer work is highly specialized, tailoring a solution for a specific use case out of existent but adapted parts.
For the latter, it can make a lot of sense to work within a mature ecosystem, where most of the components are already available, even if you sacrifice flexibility when you need to go out of bounds.
And also you adapt your workflow and designs to the tool, not vice versus.
There isn't anything else on the market I know of that comes close.
The two big reasons are simulink and the availability of extremely domain-specific modules.
Simulink is a graphical modeling lanaguage for developing/simulating closed-loop control systems among other things. Flight controls people build aircraft controls in simulink and then the software engineers take it and use it to generate code that can be integrated into the rest of the flight software.
Then Mathworks builds and maintains a specific tool box for every niche engineering domain under the Sun. Need a set of simulink blocks and/or matlab functions for simulating phased-array radar systems? Mathworks has you covered, for an expensive license fee.
Both these things, IMO are ripe for replacement by open-sourced Python-based modules that do the same things, but it would take the right people with the right domain knowledge to have the incentive to do the work.
"Know your users". Something is preventing them from considering those alternatives as replacements.
Of course you're right in this comment. Just because something exists doesn't mean people will know about it or trust it. Relationships, support, marketing etc that businesses provide go a long way to helping adoption.
Btw, I don't think obscurity is a significant factor.
Some people in teaching roles will even further Matlab's spread irresponsibly out of not wanting to learn a new tool. I have seen this myself. A professor showed the students Matlab, instead of using non-proprietary alternatives. He also did not seem interested in learning about anything else, when I used Python + Numpy instead and showed him.
That's what confuses software engineers about Matlab. They see code and think that the work is software engineering, but that's not always the case.
Imagine the reverse scenario. The professor sees you crunching numbers in Python and tries to convince you to switch to Matlab because it's "better". But you're a software engineer, and you still have to do all your software things that Matlab isn't great for. Why would you be interested in it?
Julia would probably be a better solution for this use case.
The problem isn't performance, it's that matlab is a single click install of everything and an ide that takes care of everything for you. By comparison, managing a python environment is a nightmare.
> "Yea some of the new PhDs try it out until they find out how awful it is!"
I clutched my pearls, aghast, and asked him why he thought Python was awful? He said that the community supported tools have problems, but the toolboxes provided by MATLAB are high quality and just work. I told him that I thought he was misguided, that Python tools work quite well and that the Python community is a strength not a weakness, that when a tool doesn't work well it's an opportunity to contribute.
He listened politely, but wasn't convinced.
(Double checked your username, seems we've discussed the Matlab/Python space before!)
My aversion to Python is a personal bias. It is an easy language to pick up and has won its place. I just don't like it. I was using Lush back in the day (Yann LeCun was one of the creators), and I wish it had won over Python due to my Lisp predilection [1]. It is a Lisp-like syntax that compiles to C.
At 14:00, the interactive slider exploration due to the speed is amazing. Over 500 Monte Carlo simulations in less than 60ms.
He listened, but he probably doesn't care.
He uses whatever software helps him gets his job done and that's it. Software developers and enthusiats in general usually care about free software, other people not so much.
And also we can't pretend that free sotware projects like octave are not playing catch up with its commercial counterparts, it's not like hundreds of paid developers and billions of dollars getting thrown at the development of new features don't make any difference.
That's like trying to convince someone to buy a fairphone and telling them that if the phone is lacking in some area, they can contribute to the design. Maybe you believe in the message and you're willing to make sacrifice, But if you're a math postdoc whose immediate concern is getting a tenured job before time is up, you just use what's easy and works, because you've got other stuff on your plate that is much closer to your expertise (developing new mathematical knowledge).
We do need a better story with dependencies in Python, and I'm happy to see there have been several posts over the last week talking about this issue.
That said I think that for academic projects it can be fairly straightforward to handle after an initial learning curve. A lot of projects can be accomplished with just numpy/scipy/matplotlib and maybe a couple other specialty libraries.
As many others have pointed out, Matlab is not only relevant, but thriving in many fields. It's a great package and is deeply embedded into the engineering world.
I won't repeat points others have made, but here are a few of my observations:
* Matlab is a great language for domain specialists -- non-programmers who want to solve technical problems. There is almost no barrier to entry to Matlab for such users -- you just start using it at the command line. Python and Julia assume the user is a programmer -- you need to worry about variable types, quirky syntax, finding and importing the right libraries, etc.
* Julia started out as a next step beyond Matlab for numeric computation. It was relatively easy to use at the beginning. However, the language has now grown and generalized to the point where I find that it has become as difficult to use as C++. For example, error messages thrown by Julia can be multiple screens long and are as hard to read as C++ errors. And getting types right is a pain. Here's the Julia manpage discussing all the types you need to worry about when writing Julia programs:
https://docs.julialang.org/en/v1/manual/types/
Maybe hard-core programmers love the available abstractions, but this level of complexity is a real turn-off for domain specialists who just need to crunch some numbers.
* Matlab is highly performant. The Mathworks implemented a JIT some years ago which largely mitigated the need to write (tortured) vectorized code. On the other hand, "for" loops in Octave are still dog-slow since it's interpreted on a line-by-line basis.
* Matlab has tons of toolboxes implementing advanced functionality. The toolboxes are widely used in industry. Octave mostly lacks this toolbox ecosystem.
* As others have mentioned, Simulink provides a graphical tool used almost everywere to design control systems. The control systems guys at my workplace use it. There is also an open-source alternative to Matlab/Simulink, Scilab/Xcos, which was originally written at a French university but is now owned by Dessault:
Unfortunately, I have never seen anybody on this side of the Atlantic Ocean use Xcos for anything, but I see Simulink all over the place.
* Finally, I'll point out that the Mathworks remains very innovative and continues to invest in their products. Their stuff is improving in quality and extending into new domains. I agree Matlab's price tag is steep for individual users, but for companies the price is a drop in the bucket, and the Mathworks puts its revenues to good use. I can think of many other software companies who charge far more for their stuff, but simply collect their revenues and leave their products to stagnate. The Mathworks is a good model of what a commercial software company should be.
For those who can't pay for Matlab, Octave and Scilab are both good enough for home use.
The good news is this can be fixed by using AbreviatedStackTraces.jl, which will probably be added to the base language in the next update (1.10).
> And getting types right is a pain. Julia's types are almost identical to Python's. Julia is dynamically-typed, with optional type annotations. You don't have to touch types, ever, if you don't want to. I never worry about types when I write Julia programs.
Python installation is a headache in a classroom setting. Matlab provides an official installer that guarantees that every kid in the class has a working installation and the same user environment by the time the lesson starts.
It seems like Python and R have taken up residence in fields that had no prior loyalty to Matlab, such as biology.
What I've noticed is that where new graduates used to list Matlab on their resumes, now they list Python. In both cases, whether they can actually do anything useful with it or not. Many of those people didn't actually learn to program. Depending on what courses they took, exposure to Matlab or Python may have consisted of pasting some code written by the TA and running it. Students are not unaware that Python is associated with the job market for programmers -- a career "Plan B" that many are considering. At the same time, if someone can program in Matlab, they can learn Python in a jiffy, or vice versa, so it's not a life-or-death choice.
Whether they actually want to use Matlab or Python in their jobs probably depends on what industry they're in, and their interests. None of the traditional engineers in my workplace (mechanical, electrical) do any programming to speak of. Their CAD software does the engineering calculations that they need. For basic data manipulation, including graphing, they're happy with Excel.
If your company can afford it, and if it has good toolboxes for your field, MATLAB is a solid tool. Its plotting capabilities are the gold standard for a large portion of science--python's matplotlib and similar plotting libraries in other languages are in large part based on MATLAB's plotting experience. Others in this thread have mentioned Simulink, which is also top of the line for control theory analysis.
I think an underappreciated capability of MATLAB is its C/C++ code generation, which is quite good. It'll transpile MATLAB source code (with some minimal type annotations) into C/C++ source code that you can take wherever you want.
Having said all that, it still has plenty of flaws including its price tag. One field where I get the sense that it lags is AI/ML--I have never seen a paper introducing a groundbreaking result that uses MATLAB's ML toolboxes.
I prefer Julia / Python / C++ for my own work, but will still reach for MATLAB every once in a while.
In one of my first jobs I saved a bunch of money for the company just by porting stuff out of Matlab. It wasn't just that the licenses were pricey, it's that they were a pain in the butt, plus the program was slow and very difficult to orchestrate. At least at the time.
It wasn't always easy or possible to replace a client's Matlab analyses with an Octave script, but we at least confined it to just one license on one server, stashed inside a utility closet. While meanwhile all other data analysis work flows had been automated and moved into EC2, where they ran for free on Octave.
By comparison, whenever I encounter Python code just a few years old, half the time it's (almost irreparably) broken.
(Are you sure Octave didn't have simular ones when it was as young ? Not to mention that they are kind of forced to follow behind Matlab : for instance IIRC they only recently started to think about adding Unicode support ?)
Numpy and Julia are alternative open source projects that cover some of the same use cases, but also add some additonal value. Numpy works with the Python ecosystem and its API has been emulated for distinct applications. Julia shares some of MATLAB and Octave's syntax, adds an advanced algebraic type system, and has expanding native code generating capabilities.
However at this point I've definitively switched to Python/numpy/scipy/jupyter/etc.. Basically no reason to go back to Octave or Matlab.
I still use Mathematica on occasion though. I haven't found an alternative that is as convenient.
At the very least add some blurb to explain what you're linking to
For people who did Google stats, R was the unchallenged leader. Almost no one used Octave. I think they did have a site license for Matlab, if memory serves.
(this is not a defense of R. I hate it, myself.)
Even after you've attained some basic competence and you've been using it for a while, it's still confounding.
Surely people versed with it (or the developers) would be able to show how to work around its limitations vs. Matlab toolboxes’ über-completeness.
Call Python libraries if you must from within Octave. But show how to accomplish a popular application from beginning to the very end.
Octave has some volunteer hackers who poke at the code base for fun. I recall that about ten years ago development of Octave had a crisis -- the primary developer John Eaton lost his funding from the University of Wisconson. Many people who followed Octave feared the project would die. Fortunately, that did not happen, and I am not sure how the whole kerfluffle worked itself out. However, it illuminates the shaky foundations of the volunteer-project software development model (Octave) compared to having a cash fountain from real revenues (Matlab). The cash fountain means you can fund development of features desired by your users.
Take it easy, down voters: just pointing out a fact.
Don't know about R.
Julia is just a straightforward improvement (substantially faster, but it has the nicest mathematical syntax of anything I've seen).