An interesting corollary to this is that even if the future trajectory of a general 3-body orbit is predictable in theory using numerical methods (and infinite precision calculations), in practice the use of finite-precision floating point means that after some time the trajectory predicted by an ODE solver will diverge from the mathematically-true trajectory. Even symplectic integrators have this problem. More details on the general case of chaos are provided by this insightful blog post:
I'll add one more piece of ham lore to this thread. The gigantic electronic component distributor DigiKey got its start when the founder designed and marketed a Morse code key to the ham radio audience. DigiKey was originally a mail-order business selling to hams.
The point is that the ham radio hobby is very intertwined with the electrical engineering profession. It's very technical ... not just a bunch of guys talking to each other over the radio (although it's that too).
The thing which seems to be overlooked -- both in the linked article and in the HN comments -- is that at one time ham radio was a hobby for folks wanting to play around with state-of-the-art technology. It was more than just a bunch of guys chatting with each other over a radio. At one time most people had to build their own ham rig from piece parts. One had to have a serious amount of engineering ability to do so ... or at least be able to read a schematic published in a magazine and solder together a radio, not a small feat. As a hobby it was all about becoming proficient in electrical engineering, then enjoying your proficiency by chatting with -- and showing off to -- like-minded guys around the world.
Ham magazines like QST and 73 published schematics and other how-to articles which amounted to an excellent education in practical electrical engineering. 73 magazine in particular was very technical -- it assumed you had good working knowledge of many common RF and audio circuits. Also, to get a ham license you needed to take a test demonstrating a good level of proficiency. For the lowest rung "novice" license you just had to demonstrate knowledge of Morse code at a slow but reasonable pace. For higher rungs of the achievement ladder like "advanced" or "extra" you needed to pass an exam about electronics as well as receive and send Morse code at a fast clip. The license presented a barrier to entry which didn't exist in CB radio -- which some hams looked down upon as a cesspool of unwashed, technically illiterate bozos.
My exposure to ham radio really started in the 1970s since my dad had been a ham playing with homebuilt radios since he was a kid in the 1930s. In the '70s the hobby was trifurcating. On one hand were the hard-core guys who built their own rigs, sometimes for the challenging high-frequency bands. Some also participated in designing and launching a ham-radio satellite via the ARRL. Early forms of digital encoding over radio were also big. Those guys were the real engineering types, and I admired them. On the other hand, commercial outfits were selling ready-to-use radios ... no engineering skills needed. In the middle were guys assembling and using stuff from Heathkit -- a great way to learn about electronics.
The ham hobby has been fading away for many years. I think the thrill of building a radio and then talking to somebody on a different continent with it has diminished in the face of cheap international calling, cell phones, Skype, etc. The only thing left for hams to do these days involves disaster relief -- and the remaining ham mag QST plays up that theme (or at least did the last time I looked). Meanwhile, the young nerds who used to take up ham radio now occupy themselves with various open-source software projects. I suppose that's natural.
You mentioned the cost of tools a couple of times. What's wrong with using MOSIS, which is free? Just asking, since I don't know anything about this area except that MOSIS was mentioned multiple times when I was in grad school back in the 1980s.
I will probably get downvoted for pointing this out, but the reality is that the geometric algebra approach to E&M, while interesting for its own reasons, will not replace the formalism based on Gibbs's vector calculus. One reason is simply that vector calculus is pretty intuitive and easy to learn. The major reason, however, is that the vector calculus approach is totally entrenched in the worlds of engineering and physics. After 100 years, nobody actually practicing those disciplines will make the notation change just so they can replace the 4 Maxwell's equations with one geometric algebra equation.
Also, Gibbs's vector calculus is used in fluid dynamics and other engineering disciplines, and as far as I know, nobody it touting the advantages of geometric algebra to folks working in fluid dynamics. I can be pretty sure that some HN reader will show me I am wrong about this by pointing out one lonely researcher who has found a way to express the Navier-Stokes equations using the geometric product ... but so what? ... My main point is that traditional vector calculus is a language everybody knows how to speak, geometric algebra is just another way to say the same things, so why would anybody change?
Besides these test functions I am curious to know if anybody uses the CUTE/CUTEr/CUTEst framework for testing. It's not clear to me how much the CUTE* packages are used in industry or by developers of optimization software.
I worked at the Arch Mach at MIT for a very short period in the very early 1980s. The Arch Mach was the predecessor to the MIT Media Lab. I made absolutely no impact there, but I do recall one of the successes of the lab was a kind of prototype of today's Google Maps Street View, where you could drive around Aspen, Colo on the computer and look at image taken from a car driving around the town. You could choose to drive forward, then turn left or right at an intersection as desired. You could thereby explore the entire town via the computer. It was regarded as extremely cool at the time. It's clearly the inspiration to today's Google Street View. Although I didn't work on it myself, I was able to play with it.
The images were stored on a laserdisk, and as you drove down the street the laserdisk player would pull the appropriate images off the disk and show them to you on the computer monitor. The images were stored on laserdisk because they were large files and at the time the only way you could store a lot of such large files was on a laserdisk since it was designed to hold video. For the 1981-1982 time-frame the Aspen exploration system was very forward-looking, but I do recall a delay between the time when you'd hit the button to move ahead, and the image would appear on the monitor. The delay had to do with first seeking, then reading the image off the disk.
I just looked around the web, and found this link describing the system:
I see a bunch of names I recognize in the Wikipedia article, so here's a shoutout to all the folks I worked with while I was an insignificant undergrad.
The reason Americans use cups and spoons (instead of e.g. grams) to measure ingredients is a matter of history. Tradition says Fannie Farmer wrote the "Boston Cooking-School Cook Book" in 1896, and for the first time in a cookbook used precise measurements (instead of "a jigger of this" or "a pinch of that") to specify how much of each ingredient to use. Nobody at that time would have a weight scale in their kitchen, so Ms. Farmer measured her proportions using tools which were readily available in any kitchen -- cups and spoons.
Her cookbook achieved immediate success and she became a household name in America. Even I had heard of her, long before I became a feeble student of history. Her measurement system is totally entrenched in American cooking culture, so I expect it won't ever be displaced by metric measurements except perhaps amongst high-end commercial kitchens and with people who want to make the effort to convert to grams and liters when cooking.
That's not how the real world works. A lot of manufacturing equipment and test stands were developed using LabView and used NI cards to control equipment and take data. The people who developed all that stuff are long gone and the new people neither understand the old stuff nor do they have time to spend many months spelunking into the guts of the old software to maintain it. Their managers are also very reluctant to change anything since it means very expensive downtime for an entire assembly line. Downtime can cost tens or hundreds of thousands of dollars per month. Everybody wants to keep the old stuff running as long as possible -- generally several decades.
I have no experience in the banking industry but I do hear the same considerations I see in manufacturing exist in banking software. Any change is fraught with major risk (millions of dollars in loss) so change is avoided as much as possible. I see lots of people on HN talk about how change and churn is avoided in banking software ... the same applies to manufacturing.
The Rasberry Pi comment is laughable. I'm not talking about toys for hobbyists. I'm talking about computers running software controlling cards costing tens of thousands of dollars running physical equipment of equal or greater expense. Nobody will hire a hobby hacker to light a few LEDs with a Pi when doing factory automation.
Yes, this will be a major problem for factories. Any "cloud based" software is guaranteed to become obsolete and incompatible well within the lifetime of the equipment it controls. If you're dealing with real manufacturing or lab equipment you should avoid "cloud based" stuff like the plague.
Most of the equipment I deal with is not on the net. It doesn't need to be since it's just controlling some machine which is busy making something real. If you need to move any data on or off the computer you use USB sticks (or sometimes CDs or floppies).
Some newer test stands are interfaced to an internal LAN so they can provide process control data to a database. In that case one either needs to provide some sort of firewall between the equipment's computer and the database, or just bite the bullet and redesign the whole thing for compatibility with, say, Win 10 (at major expense in time and money).
I wish I could convince people to target their automation stuff to Linux so the backwards compatibility problem would be easier, but corporations still balk at that.
It's a side gig for me. The biggest hurdle is finding a bunch of companies fielding the old equipment and then becoming known to them. In that sense it's like any other consulting gig -- it's mostly about who you know, not what you know.
This is a relevant article to me since I also make 20yo (or older) computers run legacy stuff ... but not for fun.
Factories and labs frequently have machines or instruments which are controlled by a computer. They are run off control cards which are inserted into ISA or PCI slots in the computer and are commanded by the legacy software through old, proprietary drivers. Examples are cards from National Instruments or Galil. Such equipment can cost tens of thousands of dollars (or more) when new. Also, decades-old software written by long-gone engineers at the factory still runs on the equipment, and nobody understands how the stuff works nowadays. Therefore, there is plenty of incentive to keep the old systems running and running and running.
Unfortunately, old computers sometimes break. That's where I come in -- I do a side consulting business with a colleague where we refurbish the old computers -- replace parts as necessary, install old versions of the O/S, replace mechanical hard drives with SSDs, and do whatever else is needed to keep the computers running for the next few decades.
I know we're not alone out there since we're aware of other small businesses which provide a similar service. It's an important thing since -- as many point out here -- modern software companies don't make backwards compatibility a priority, but factories and labs have equipment which need to run for decades, so the computers controlling them also need to run for decades.
I recall doing a noise model of a transimpedance amp in Gnumeric where I called out to Python/Numpy to do integration of 1/f noise based on parameters from a datasheet. That was at least 10 years ago. What's the difference between this Gnumeric feature and Neptyne?
This is a very good point, and is likely one of Matlab's pillars of strength. As an open-source guy I find it painful to say it, but the fact that the Mathworks is a commercial organization means they have lots of revenues which they use to hire people to implement new features. They have loads of very smart engineers building new toolboxes and other new features all the time since they have a money fountain (revenues) to fund it. The toolboxes are important to paying customers with advanced requirements, and they are willing to pay for them. It's a virtuous circle.
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.
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:
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.
I don't know about these days, but back in the 1980s there were a number of electronics surplus stores located on Canal St, below SoHo. I used to pop in now and then to buy stuff. They were part of a larger ecosystem of industrial supply stores left over from the days when SoHo was a factory district. Sadly, the last time I was down there no electronics stores remained.
https://www.stochasticlifestyle.com/how-chaotic-is-chaos-how...