[HN Gopher] GNU Octave
       ___________________________________________________________________
        
       GNU Octave
        
       Author : MonkeyClub
       Score  : 214 points
       Date   : 2023-01-21 07:04 UTC (15 hours ago)
        
 (HTM) web link (octave.org)
 (TXT) w3m dump (octave.org)
        
       | yonz wrote:
       | I used Octave when my educational license for Matlab expired. We
       | need OSS competitors to keep Matlab in check, already at $1k/year
       | https://www.mathworks.com/pricing-licensing.html
        
         | Tijdreiziger wrote:
         | They have a home license for EUR120 and an academic license for
         | EUR500 though. Of course, Octave is still cheaper.
        
           | IshKebab wrote:
           | Yeah the home MATLAB license is the most expensive software
           | I've actually bought. Octave is... okish. But Matlab is like
           | 80% plotting and Octave's plotting support is pretty
           | terrible.
           | 
           | 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 PS120 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.
        
             | Tijdreiziger wrote:
             | > Yeah the home MATLAB license is the most expensive
             | software I've actually bought.
             | 
             | Are you sure? The standalone version of Microsoft Office is
             | more expensive at EUR150.
             | 
             | Windows is even more expensive, but of course most people
             | get that bundled with their computer.
        
           | tmtvl wrote:
           | Octave is a great project though since it is Free (in both
           | senses of the word) it would be nice if people who end up
           | saving EUR120/year on ML could consider passing a portion of
           | those savings on in the form of a donation.
        
             | Tijdreiziger wrote:
             | Yes, the fact that Octave is FOSS is definitely awesome
             | too, I didn't mean to diminish that :)
        
       | atum47 wrote:
       | Did all my projects in octave during image processing class. It's
       | awesome.
        
       | AlbertCory wrote:
       | This is from 2008-2011, so adjust accordingly for evolution:
       | 
       | 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.)
        
         | acomjean wrote:
         | I disliked R until I took a bio statistics course. It then made
         | a lot of sense. For graphing and analysis it's great, as a
         | general computing language it's wanting.
        
           | Max-Limelihood wrote:
           | In that case I'd suggest Julia; it's got syntax pretty much
           | identical to R, and is just as easy to pick up, but it's
           | much, much faster, and it works as a general-ish computing
           | language. (It's still definitely math/science/research-
           | oriented, but it's not like R, which is only really usable
           | for statistics scripts.)
        
       | kqr wrote:
       | Is someone able to briefly compare Octave to numpy and R?
        
         | Max-Limelihood wrote:
         | Nicer syntax for mathematical operations, but it's very slow
         | (even slower than Python, similar to R) and it doesn't always
         | work with Matlab code like it's supposed to.
         | 
         | Julia is just a straightforward improvement (substantially
         | faster, but it has the nicest mathematical syntax of anything
         | I've seen).
        
         | highfreq wrote:
         | Compared to numpy, octave has a nicer syntax for matrix math,
         | but a bit idiosyncratic as a general language. It doesn't have
         | anywhere near the ecosystem of Python/NumPy/SciPy. It is also
         | nice in that there is a standard development shell with REPL
         | plotting, debugging and text editor. Like numpy it is pretty
         | slow if you have to actually use for loops over large data
         | sets.
         | 
         | Don't know about R.
        
       | wwfn wrote:
       | Open science depends on open tools! Octave is such a good
       | resource for otherwise walled off code (that doesn't use newer
       | matlab features). But I'm curious where octave is popular. Does
       | anyone pick it over julia or python when starting a new
       | project/research?
       | 
       | 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?
        
         | jwuphysics wrote:
         | I found it really useful when I got started in numerical
         | computing and machine learning. Now I use the Jax/Numpy stack
         | and Pytorch, but octave still has a special place in my heart
         | due to Andrew Ng's canonical intro to ML Coursera course.
        
         | sandpaper26 wrote:
         | I used it in grad school a lot, especially when I was
         | running/editing someone else's Matlab code. But if I were to
         | build something on my own, Python would be the way to go.
        
         | signaru wrote:
         | In my past engineering university Matlab is popular. Students
         | and staff get access to a network license and courses (non CS)
         | are built around it. It is what older professors are used to
         | and I don't see them shifting to a new language given how busy
         | university professors are, and that Matlab just works. So
         | outside the university, Octave is the path of least resistance
         | for those not planning to purchase Matlab or get it by "other
         | means".
        
         | rightbyte wrote:
         | > But I'm curious where octave is popular. Does anyone pick it
         | over julia or python when starting a new project/research?
         | 
         | 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.
        
           | npalli wrote:
           | >> 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.
        
             | tkuraku wrote:
             | The big simplicity is that you install octave and you have
             | a gui development environment ready to go. Julia and vscode
             | are great, but setting up a project with all dependencies
             | is a little more work for university students with no
             | programing experience .
        
         | slavik81 wrote:
         | I write all my code in C++, but when debugging, I format my
         | printed data so that I can examine it in octave.
        
         | antegamisou wrote:
         | Its use is mostly limited to STEM undergrads that for some
         | reason have trouble installing/running MATLAB.
         | 
         | 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.
        
           | spookie wrote:
           | > for some reason have trouble installing/running MATLAB The
           | reason is perhaps the biggest argument against its use in an
           | academic setting, so I'm quite happy that they are the
           | biggest customer
        
         | the__alchemist wrote:
         | Another take: There's value in using a compiled language here.
         | I'm an amateur dabbling in computational chemistry, and my
         | weapon of choice is Rust. (After starting using Python). Why:
         | - 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?)
        
           | BaculumMeumEst wrote:
           | Python can be very fast. Library ecosystem and network
           | effects by far outweigh anything you listed. Mindless Rust
           | evangelism is tiresome.
        
             | [deleted]
        
             | patrick451 wrote:
             | One thing is for sure, rust has excellent marketing.
        
               | pdimitar wrote:
               | Or it's actually good and you're bemoaning it due to
               | bias. It's worth exploring the areas outside of our
               | comfort zone.
        
           | wodenokoto wrote:
           | Maybe it is not part of computational chemistry, but how do
           | you do explorative analysis? More than half my time working
           | with data is spend grouping and summarising data, typically
           | in Pandas and drawing interactive graphs in plotly.
        
             | the__alchemist wrote:
             | Plots and visualizations in 3D. (Vulkan / WGPU) For
             | example, to compare wave function solutions, I use surface
             | plots of a 2D slice. I have a UI that can change the slice
             | of the non-mapped axis. Plots of psi'', the potential etc
             | too.
             | 
             | 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)
        
               | legerdemain wrote:
               | Did you write your own visualizations using wgpu? I don't
               | think its goals include providing visualization out of
               | the box.
        
               | the__alchemist wrote:
               | Yep! So, took some work upfront. Basic
               | rendering/navigation engine. `egui` for the GUI.
        
           | einpoklum wrote:
           | Given your criteria, you might want to consider (modern) C++.
           | 
           | * 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.
        
             | the__alchemist wrote:
             | I want to get into that for CUDA. I've been using Vulkan
             | via WGPU. But there, everything has to pass between CPU and
             | GPU as byte arrays, when I've heard CUDA lets you maintain
             | the same data structures. On the to-do list.
             | 
             | 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.
        
             | vlovich123 wrote:
             | > Fast - in many cases faster than Rust, although the
             | difference is inconsequential relative to Python-to-Rust
             | improvement I guess.
             | 
             | 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.
        
           | akuro wrote:
           | Interesting. You might be the first computational chemist I
           | know who actually uses Rust. I know a lot of computational
           | chemists!
           | 
           | 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!
        
             | doubleg72 wrote:
             | Maybe spare the next guy by moving your "don't listen to my
             | opinions on programming languages" statement to beginning
             | of second paragraph... ya know, for efficiency!
        
               | osigurdson wrote:
               | You take the comment far too literally.
        
               | akuro wrote:
               | Don't listen to _my_ opinions, sure. But pay heed to the
               | large number of computational chemists who _do_ use these
               | languages. There is a reason that professionals employ
               | the tools that they do.
        
               | tialaramex wrote:
               | One reason we have lots of people in numerate disciplines
               | using Python is that we taught them Python. Python is
               | very teachable. Given a class of average 19 year old
               | students from a numerate discipline, my colleagues will
               | teach most of them Python to a reasonable standard in a
               | single module (so e.g 2 hours of teaching per week over
               | 16 weeks).
               | 
               | The same would not be true if we were supposed to teach
               | them C++ for example. It's a huge, sprawling language,
               | full of difficult concepts that are unfriendly to teach,
               | and equally filled with foot guns that if you don't teach
               | them will definitely maim your students, but if you do
               | teach them take up yet more precious time on minutiae.
               | 
               |  _Safe_ Rust wouldn 't be as hard to teach as C++ but
               | it's no picnic. So even if the Chemists decided that
               | ideally they'd like their undergraduates to learn Rust
               | instead of Python, I think the argument would be that it
               | can't be done on the existing timeline.
        
               | zozbot234 wrote:
               | > Python is very teachable. Given a class of average 19
               | year old students from a numerate discipline, my
               | colleagues will teach most of them Python to a reasonable
               | standard in a single module
               | 
               | Compared to Perl, sure, Python is teachable. But I'm
               | willing to speculate that Safe Rust as a semi-pure
               | functional language (basically: when in doubt, .clone()
               | all the things and don't even think about the minor hit
               | to performance) can _also_ be taught as a first-time
               | programming language. Rust may be at a disadvantage to
               | Python wrt. bindings to the existing ecosystem of C
               | /C++/F0RTRAN scientific codes, but that's a temporary
               | state of things.
        
               | freehorse wrote:
               | Historical reasons, most often than not.
        
         | pfortuny wrote:
         | I guess Mathworks is pushing very very hard to get Matlab into
         | Universities at the teacuing level, with campus licenses, which
         | honestly for students are great (until they stop being students
         | and realize they have been sucked into an abyss of cost).
         | 
         | 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).
        
           | actinium226 wrote:
           | It's also difficult to learn the new paradigm of a language,
           | especially since MATLAB is so tightly coupled with the IDE
           | and every other programming languages is usually run on the
           | command line. You can use an IDE for those languages, but it
           | usually requires some setup and sometimes that breaks.
           | 
           | 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!
        
           | cycomanic wrote:
           | I agree with you, but times are changing. In my experience
           | quite a few departments are moving to python now. This is
           | largely driven by new students who choose or push for python
           | based subjects, because of the much broader applicability.
           | Typically that's a slowish process, starting at the first
           | year level and transitioning to later levels. It's not like
           | it hasn't been done before, when I was a student we would be
           | taught in c or java.
        
           | eggy wrote:
           | Autodesk did the same with AutoCAD with student licenses, and
           | they unofficially allowed the pirating and use of AutoCAD
           | knowing it would then win market share when people went to
           | work for a company that needed to secure licenses.
        
         | kkylin wrote:
         | I use Octave when I teach linear algebra, but it is missing
         | some things even for that, e.g., lasso was missing the last
         | time I tried it. So back to Matlab it was. When I have time
         | (not in the middle of an academic year) I might try to
         | contribute some code.
        
         | rhodysurf wrote:
         | I use it when I'm given a model by a scientist they wrote in
         | matlab and I need to port it somewhere else to integrate with
         | an actual system. Octave is great for testing to make sure port
         | matches etc. I also use Octave to learn how matlab algos work
         | because octave is open source and reimplements most if matlab a
         | standard library
        
         | nxpnsv wrote:
         | I used it a bunch when studying physics at uni, it was perfect
         | for making plots for lab exercises...
        
         | fluidcruft wrote:
         | I used to use it a lot, but the python libraries are much
         | further ahead at this point. For my uses (essentially image
         | processing and statistics) Octave is always playing catchup
         | with Matlab but python is mostly at par or ahead of Matlab.
         | With the exception of the parallel stuff... but that wasn't
         | anything Octave had either. Eventually when I need performance
         | again I'll see about figuring out how to migrate parts to
         | Julia. One thing I like about the python things is there are
         | some hints of IDL in there (I'm a masochist and liked IDL...
         | Matlab frustrates me at times). Matlab was great for slapping
         | quick UIs together and making little tools, but Jupyter works
         | well enough for that.
         | 
         | The 0 indexing in python does really and truly suck sometimes
         | though.
        
           | abdullahkhalids wrote:
           | The 0 indexing is something one can get used to. On the other
           | hand the fact that range(k,n) goes from k,...,n-1 is the most
           | annoying part.
        
             | whatshisface wrote:
             | That's so that range(10) has 10 items in it.
        
           | dr_zoidberg wrote:
           | > 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.
        
             | ogogmad wrote:
             | What you've said isn't surprising.
             | 
             | 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.
        
               | enriquto wrote:
               | but this depends a lot on the particular formula. For
               | example, if you use discrete Furier transforms, all
               | formulas are natural with 0-indexing, but weird with
               | 1-indexing. In general, when the indices of an array are
               | to be interpreted as modulo N, you want them to be 0, 1,
               | ..., N-1
               | 
               | It is inevitable to have to use both conventions if you
               | do varied math stuff. Thus, you will never be happy.
        
               | ogogmad wrote:
               | The pragmatic solution for transcribing is probably to
               | make some functions `array_index` and `array_slice` that
               | automatically convert between the two conventions. I
               | think Julia offers another way: It lets you choose
               | between them.
        
               | Beldin wrote:
               | I prefer OPTION BASE {0, 1} :)
        
               | ethbr0 wrote:
               | (Obligatory) There are only 2 hard problems in computer
               | science: cache invalidation, naming things, and off-by-
               | one errors
        
               | tmtvl wrote:
               | may You concurrency forgotten have.
        
               | [deleted]
        
               | ethbr0 wrote:
               | It just printed out in your comment a few hours after I
               | thought I invoked it.
        
             | fluidcruft wrote:
             | I just never find myself working out formulae/series/proofs
             | on paper using zero-indexing. When you look up
             | derivations/solutions in books and references they're one
             | indexed. A recent example was a formula that had a
             | (n-1)!*n! term that made sense from understanding the
             | derivation. But I forgot to code it as (n-2)!*(n-1)! at
             | first.
             | 
             | 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.
        
               | hgomersall wrote:
               | There are good reasons why indexing from zero with
               | exclusive upper bounds should be preferred. I'll defer to
               | Dijkstra for the explanation: https://www.cs.utexas.edu/u
               | sers/EWD/transcriptions/EWD08xx/E...
        
       | aprdm wrote:
       | I used it instead of matlab when working on power systems
       | calculations, it worked pretty well!
        
       | phkahler wrote:
       | Open Matrix Language
       | 
       | https://www.openmatrix.org/
        
       | mark_l_watson wrote:
       | I used Octave both times I took Andrew Ng's Stanford Machine
       | Learning class.
       | 
       | Initially I hated the language but grew to like it.
       | 
       | Octave is an amazing open source/free software project.
        
         | rightbyte wrote:
         | > Initially I hated the language but grew to like it.
         | 
         | 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.
        
       | sporedro wrote:
       | Octave seems great since it's open and let's you run Matlab
       | scripts.
       | 
       | 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!
        
         | besnn00 wrote:
         | It dominates among engineers too, mainly because of Simulink
         | and the toolboxes it offers.
        
         | signaru wrote:
         | I heard from a talk by Cleve Moler that hardware/engineering
         | companies are the big customers (the likes of Honda).
        
         | yonz wrote:
         | You are right Python, R and Julia are good enough for Data
         | Science and Ml. But the Matlab ecosystem is deeply intertwined
         | for a variety of fields, including ones that don't require
         | coders.
         | 
         | Take a look at this for example
         | https://www.mathworks.com/matlabcentral/fileexchange/49683-l...
        
         | tkuraku wrote:
         | It has some add-ons (tool-boxes) that aren't as complete or
         | don't exist in the open source world and would be a big lift to
         | reimplements. If you are just writing all your own code there
         | isn't any advantage over python, Julia, etc.
        
         | polalavik wrote:
         | very relevant. Mathworks has an iron grip on the defense
         | industry and academia. Like others have said, because of
         | simulink and a paradigm called "model based engineering".
         | Simulink is nice, especially HDL coding tools because writing
         | HDL by hand can be a real pain. I wish Octave made an open
         | source - maybe one day.
        
           | mrdrrobots wrote:
           | As someone who works at a DoD FFRDC, I can confirm this is
           | true. Matlab is the language of choice for 95% of my
           | colleagues who have no CS or programming background, the
           | other 5% is Labview. They write spaghetti code to get the job
           | done. I've been scolded for using Python or Julia in programs
           | because no one else can use it/understand it. I've wasted
           | hours setting Python environments up for people which is
           | especially hard due to strict firewall rules. Even once it is
           | setup, it is usually to run some script the found on the
           | internet, if it doesn't do exactly what they need, they give
           | up and move on. Matlab on the other-hand is a one click
           | install with all the packages pre-installed.
        
         | sco1 wrote:
         | > but what's the benefit of going with a walled off proprietary
         | $$$ tool when you can use something like this
         | 
         | 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.
        
           | CamperBob2 wrote:
           | _There are also many domain-specific tools (e.g. Simulink)
           | that do not have similarly functional open alternatives._
           | 
           | 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.
        
         | [deleted]
        
         | analog31 wrote:
         | Universities are still using Matlab. It's effectively "free"
         | thanks to generous site licenses, and there's a lot of mature
         | curriculum built up around it. The academics in my family
         | (mostly physical sciences) would say "just use Matlab" and
         | consider everything else to be unnecessary fuss.
         | 
         | 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.
        
           | Max-Limelihood wrote:
           | I think you should try out Julia, in that case. Julia
           | installation and package management is extremely easy (MUCH
           | easier than Python). The syntax is very similar to a cross
           | between Matlab and Python, so it's easy to pick up if you're
           | used to either of those--it's also a lot more readable than
           | R. And it's way, way faster than either Python or Matlab.
        
         | sbrorson wrote:
         | > A bit offf topic, but is Matlab relevant still?
         | 
         | 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:
         | 
         | https://www.scilab.org/
         | 
         | 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.
        
           | Max-Limelihood wrote:
           | > For example, error messages thrown by Julia can be multiple
           | screens long and are as hard to read as C++ errors.
           | 
           | 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.
        
           | jgilias wrote:
           | Wow, I didn't know you don't need to vectorize Matlab code
           | anymore! Though that's a useful skill to have, has saved my
           | skin a few times in scientific Python land too!
        
         | ubj wrote:
         | MATLAB is very much still in use by large corporations and
         | national laboratories. I'm currently a full time researcher at
         | MIT Lincoln Laboratory and did a summer internship at MITRE a
         | couple years ago, and MATLAB is/was the de facto standard
         | language for the majority of staff.
         | 
         | 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.
        
         | alerighi wrote:
         | I think the reason is that Matlab is more oriented to people
         | that are not programmers, such as mathematicians and engineers,
         | since it's more "user friendly" than python. It has everything
         | is needed (an IDE, interactive REPL, tools to make graphs,
         | graphical tools to build systems without writing code, etc)
         | integrated, no need to install external library or tools, no
         | need to use the CLI, just run the installer and done. The
         | language then is more natural for non programmers (for example
         | array starts as 1 and not 0), and it's use is more similar of
         | the one of a graphical calculator than a programming language.
         | 
         | I think Python is superior, but perceived as difficult for non
         | programmers.
        
           | ethbr0 wrote:
           | There's a subtle difference between most programming work and
           | non-programmers (usually engineering).
           | 
           | 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.
        
         | actinium226 wrote:
         | I recently talked to a math postdoc about Python. He said
         | 
         | > "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.
        
           | eggy wrote:
           | I use Mathematica, and it's great strength is the curated
           | data available for doing exploratory work. You can link to
           | data with Python, but you need to set it up, but in
           | Mathematica it's there from the installation. There are more
           | things you can pay for and add, but the base installation is
           | cohesive and powerful. Mathematica's notebook preceded
           | Jupyter and is still better. I use the Home edition that I
           | pay for. If I get work that uses Mathematica, I will buy the
           | full version. I tried to use Octave as a substitute for
           | Matlab but wound up moving to Julia. The code is very similar
           | and easy to jump between the two sans the Matlab add-ons,
           | however, Julia is developing a Symlink alternative.
           | 
           | 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.
           | 
           | [1] https://lush.sourceforge.net/
        
             | actinium226 wrote:
             | What's the Julia Simulink alternative called? In Googling
             | it I found sims.jl which isn't quite a simulink alternative
             | so I wonder if you're talking about something else?
        
               | ChrisRackauckas wrote:
               | ModelingToolkit.jl, a comparison is given here: https://d
               | ocs.sciml.ai/ModelingToolkit/dev/comparison/#Compar... .
               | A showcase from one of the library's users, demonstrating
               | a 15,000x acceleration, was given at a SIAM conference
               | and the recording can be found here:
               | https://www.youtube.com/watch?v=tQpqsmwlfY0
        
           | cycomanic wrote:
           | The statement about matlab toolboxes is so wrong it's almost
           | funny. The quality of different toolboxes varies
           | dramatically. Some are quite high quality but others are a
           | buggy mess and all of them are expensive. That said, the
           | statement is very field dependent. Fir example I know that
           | many (most) communication theorists are using matlab, because
           | the communications and signals toolbox does so much that
           | would be otherwise tedious to implement. On the other hand
           | many experimentalists in the same field have moved on to
           | python because the instrument toolbox is so buggy and coding
           | GUIs in matlab is an exercise in self mutilation.
        
             | aDfbrtVt wrote:
             | To further reinforce the above argument, many environments
             | dominated by Matlab have their instrument control software
             | written in Python. Mathworks have made it pretty easy to
             | call out to Python (although no Conda/Venv support...),
             | they definitely feel the pressure in that area.
             | 
             | (Double checked your username, seems we've discussed the
             | Matlab/Python space before!)
        
           | justeleblanc wrote:
           | > when a tool doesn't work well it's an opportunity to
           | contribute
           | 
           | 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).
        
             | actinium226 wrote:
             | You're right, and honestly I was just trying to think of
             | something to try to shift the narrative. There are other
             | advantages to Python, personally I really value its
             | expressiveness, the plethora of good tools (Jupyter,
             | PyCharm, Spyder), and the massive amount of libraries in
             | different domains (beyond all the scientific stuff there's
             | Panda3D, pygame, Django), but I don't think these things
             | are selling points to those in the MATLAB world. Having
             | used MATLAB to a medium degree, I know that if you're just
             | trying to get something done you can do it, so a more
             | expressive language is not really a selling point. The
             | extra tools and libraries might be a better talking point,
             | but yea I was just trying to find some angle that I could
             | leverage to make the guy curious about Python.
        
           | cafebeen wrote:
           | I think you're both right, but you might be thinking of
           | different tasks and libraries. If we're talking about solving
           | a specific type of PDE, then in that scenario he's probably
           | right that MATLAB will work better out of the box, but if
           | we're talking about logistic regression on data from a messy
           | CSV table, then python will work great and have better
           | usability than MATLAB (IMO). He might also be thinking of
           | versioning and packaging headaches in python, which are quite
           | a pain the first time exposed to them coming from a walled
           | garden environment.
        
           | lp4vn wrote:
           | >He listened politely, but wasn't convinced.
           | 
           | 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.
        
           | IshKebab wrote:
           | Well he's right. Python can't scratch the surface of most
           | MATLAB toolboxes (Octave is a lot closer). And Matlab's
           | general user experience and plotting support is just a
           | million miles better. Both languages are fairly bad so I
           | don't think that would be a factor.
        
             | actinium226 wrote:
             | Have you tried the Spyder IDE for Python? For me its user
             | experience and plotting support are very MATLAB like. It
             | was the missing IDE that made it possible to get that
             | MATLAB style workflow but do it with Python (or
             | alternatively, to use Python for scientific tasks without
             | having to always be going through CLI or notebooks, each of
             | which have their issues).
        
         | ChuckNorris89 wrote:
         | _> A bit offf topic, but is Matlab relevant still?_
         | 
         | 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.
        
         | jrumbut wrote:
         | It seems to be more relevant in some electrical engineering
         | subfields.
        
         | gdevenyi wrote:
         | Sadly yes, it dominates MRI Physics, and still has a
         | substantial footprint in neuroimaging.
        
           | eddsh1994 wrote:
           | My wife has been using primarily Python in her latest postdoc
           | in those fields so there is hope! Admittedly that might just
           | be on the ML side of the field though
        
         | c7b wrote:
         | My impression is that 10 years ago, Matlab had a few things
         | going for it in terms of plotting, general usability,... that
         | made it a valid competitor for eg R, even if you didn't depend
         | on some of its more unique features like Simulink. Nowadays, I
         | consider it essentially legacy. R has pulled so far ahead in
         | terms of plotting/data manipulation/apps that it would be a no-
         | brainer even if there was no price difference. What used to be
         | a Matlab-R choice is now an R-Python choice, maybe Julia. I
         | happen to have to maintain a fairly large Matlab codebase, if
         | we were to start over it'd definitely be one of those, probably
         | R. I still like the Matlab IDE best, but that's not going to
         | keep me. The most annoying thing is that you have to buy
         | another license on top of the regular one for most interesting
         | things (even the optimization toolbox costs extra, so does
         | statistics, ML, DL - and they're still no match for R or
         | Python).
        
         | mk_stjames wrote:
         | Matlab's Simulink is the best graphical tool for laying out
         | causal systems modeling that I've ever come across.
         | OpenModelica has a similar tool but it is nowhere near the same
         | experience.
         | 
         | There isn't anything else on the market I know of that comes
         | close.
        
           | rightbyte wrote:
           | Ye ... the way you can just draw differential equations and
           | control loops is magic. Easealy plot signals too.
        
         | gateorade wrote:
         | MATLAB is ubiquitous in the aerospace industry. There probably
         | isn't an aircraft or spcecraft built in the west in the last
         | twenty years where matlab wasn't used.
         | 
         | 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.
        
           | Max-Limelihood wrote:
           | Replacing Matlab with Python in engineering seems like a very
           | bad idea, given Python's poor performance. Matlab (and most
           | Python) packages get around this by coding everything in C++,
           | then just having users call that C++ code. But then you have
           | to code in C++, which is expensive.
           | 
           | Julia would probably be a better solution for this use case.
        
           | marmetio wrote:
           | Your last paragraph is why that's never going to happen. You
           | can make a lot more money using Matlab or making Matlab than
           | replacing it just to give it away for free.
        
             | sicp-enjoyer wrote:
             | If this were true we wouldn't have Octave in the first
             | place. People are motivated by other incentives besides
             | money.
        
               | [deleted]
        
               | [deleted]
        
               | marmetio wrote:
               | You can already find free and open source alternatives
               | for just about everything in Matlab. And yet, even many
               | companies that complain about the cost of Matlab don't
               | use the Python and Octave alternatives. Seems like money
               | is achieving something that other motivators aren't.
               | 
               | "Know your users". Something is preventing them from
               | considering those alternatives as replacements.
        
               | sicp-enjoyer wrote:
               | Your previous comment suggested nobody will develop that
               | software because it has poor financial outcomes, that was
               | what I was responding to.
               | 
               | 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.
        
       | timonovici wrote:
       | hehe, I used in my college classes, at Technical University of
       | Moldova, my teacher was a bit on the fence about it (he was
       | demanding Matlab, but the uni wasn't providing any licenses), but
       | he reluctantly agreed to it. Worked pretty fine, I could use my
       | linux laptop, and didn't need to crack matlab.
        
       | smartmic wrote:
       | The GNU universe is wide and deep, and although each program is
       | developed independently by different people with different
       | backgrounds, the name still stands for something special. For me,
       | it's a quality attribute, among others; I'm less hesitant to
       | install and try GNU applications than other, more free-floating
       | ones. And I have never been really disappointed.
       | 
       | 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.
        
         | MayeulC wrote:
         | I'm just going to point out that GNU netcat has nothing to do
         | with the GNU project, which confused me a lot :)
        
           | haolez wrote:
           | Gnuplot is the same.
        
       ___________________________________________________________________
       (page generated 2023-01-21 23:00 UTC)