sbrorson

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:

https://www.stochasticlifestyle.com/how-chaotic-is-chaos-how...

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:

https://en.wikipedia.org/wiki/Aspen_Movie_Map

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.

https://en.wikipedia.org/wiki/Fannie_Farmer

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.

Yes, they still make textiles in Lowell!

Inflatable buildings used for disaster relief. They can be trucked or air-lifted into place, then quickly inflated.

https://federalfabrics.com/

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 think Gnumeric has supported this for years.

https://help.gnome.org/users/gnumeric/stable/sect-extending-...

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.

> 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.

Congratulations to the blogger -- he has rediscovered the formulate first described in the 16th century by the French mathematician Vieta.

https://en.wikipedia.org/wiki/Vieta%27s_formulas

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.

As long as we're listing electronics flea markets nationwide, I might as well mention the grand-daddy of them all, the Dayton Hamvention:

https://hamvention.org/

As somebody who came to scientific computing late in life, after spending years as a physicist then an engineer, I will step up to defend NR, if only for fun (and because I like the book for what it is).

At least one commenter here dismissed NR, saying that it is equivalent to an undergraduate numerical analysis book. Well, duh! That's one of its strengths! It is a good book for an audience like me -- somebody with scientific background but with no formal numerical analysis training who needs to write some numerical code.

The target reader is an engineer who needs to implement something specific. That's a very common scenario -- you are given the job of implementing some calculation as part of a larger project. You're not an expert in the particular mathematical discipline. You don't want to fool around trying to find an algo in some book since you don't know which of the zillions of numerical analysis books to look at. Also, most books will just give you a general algo, not ready-to-run code. Everybody knows how hard it can be to translate a wordy description of an algo into real code. If you had the budget you'd just hire somebody to do it for you. NR solves your problem -- you use the code and your problem is solved so you can move on to the next step of your project.

A different commenter here suggested using Golub and Van Loan instead. That's laughable. First off, as others pointed out, their "Matrix Compuations" book addresses numerical linear algebra exclusively. NR is a general-purpose numerical analysis book, so covers a much larger topic set. But secondly, Matrix Computations is difficult reading for non-mathematicians. Even if I needed to implement some sort of matrix decomposition, I would find it a pain to use that book as a source.

(Yes, I am sure some testosterone-soaked HN commenter will now say that they read "Matrix Computations" in 3rd grade as a way to prove how smart they are. Allow me to roll my eyes now.)

The real complaint made in the linked post involves the licensing terms of the code in NR. I agree the license stinks by today's standards. But the book was originally written back in the 1980s. My copy is from the early 1990s. Back then the GPL was basically unknown outside of a group of happy hackers at MIT. Software licensing certainly not a topic occupying mindspace of ordinary scientists or engineers. There was some DOS-based "freeware" circulating on 3.5" disks, but the whole "free (libre) software" movement was still in the future -- it needed the internet to become widespread in order to take off. Finally, I can imagine the NR authors wanted some sort of copyright or license which prevented wholesale copying of their work by folks who would try to profit off it. It's reasonable for them to have wanted to get some monetary reward for their hard work. Their license is probably an artifact of its time.

In my travels I have seen situations where code used in commercial products incorporates this or that function presented in NR. For example, I saw the FFT algo used in a test widget. (I authored none of the copied code -- I simply observe it in projects done by others.) What's funny is that NR's FFT algo is not particularly great. However, the guys who needed an FFT probably didn't know that. They probably would not have cared anyway -- they just wanted a working solution and that's what they got from NR. I am sure that little violations of the NR license happen all the time. It may not be strictly legal, but I also see people making Xerox copies of copyrighted books and journal articles all the time too.

Finally, regarding alternatives like GSL, ccmath, or whatever is available on netlib, those projects post-date NR. In any event, the internet is what made all those things widely available. I bought my copy of NR in a bookstore before that happened.

I recently bought "Introduction to Nonlinear Optimization" by Amir Beck. It's published by the SIAM. It covers the field from beginning to intermediate level and includes examples written in MATLAB. I found the book very readable and illuminating. It's also not overly long nor verbose, which is a plus in my mind. I would recommend it -- I used some of its ideas as fodder to teach the optimization section of my class in Numerical Analysis.

https://epubs.siam.org/doi/book/10.1137/1.9781611973655?mobi...

The Economist is generally pushing an agenda, and the agenda is "capitalism is always right". If you buy their conceptual framework, the idea that you can be paid for BS work can't be right since Mr. Market always knows best, and he wouldn't pay for an activity which adds no value.

However, if you don't buy the "capitalism is always right" Ansatz, then it's quite easy to see paid BS work as yet another market failure ... or worse, as a way to keep workers busy so they don't cause trouble for "the system". Which I believe was one of Mr. Graeber's main points.

chuckle This is true. As far as I can see (as a hardware engineer frequently doing FPGA stuff) The Intel/Altera combo has not produced any new products nor yielded any customer benefit beyond what would have happened if the two companies had remained independent. But I'll bet the "business strategists" at each company who thought this one up made a pile of money from the deal.

You are right the ARM cores, mostly. Xilinx Zynq devices have ARM A devices built into them as "hard" cores. That is, the ARMs are instantiated directly in silicon, not as "soft" cores which take LUTs (gates) from the FPGA fabric. The ARM A is a microprocessor (not a microcontroller) powerful enough to run Linux.

The ARM connects to the FPGA fabric using a so-called AXI bus, which is a local bus defined by ARM. Xilinx supplies a bunch of "soft" cores which you can instantiate in the FPGA and integrate with the ARM. Of course, you can write your own logic for the FPGA too, as long as you can figure out how to interface to it using one of the AXI bus variants.

Several vendors offer experimenters platforms which are affordable enough for hobbyists and folks making engineering prototypes. Examples are the Avnet's Zed board and Digilent's Zybo board.

The biggest problem with the Zynq ecosystem is that the Xilinx tools -- Vivado/SDK and whatever they renamed it to last year -- are steaming piles of smelly brown stoff. Vivado is buggy, poorly supported, has bad documentation, and the supplied examples typically don't work in the latest version of Vivado since they were written long ago and have been made obsolete via version skew. An absolute disgrace compared to what software engineers are used to. The SDK is basically Eclipse which has its own problems, but is not as bad as Vivado. Ask me how I know.

I think AMD and Xilinx have a long way to go before they can satisfy the hype and speculation I see in all the posts here. I suppose one could shell out $20K for a seat of Synopsys if one wanted a decent set of dev tools, but that's not the direction most software engineers are going nowadays.

Also, assuming NVidia completes its acquisition of ARM, the whole Zynq ecosystem is imperiled since it pits ARM against NVidia.

It's more than an idea...

https://www.federalfabrics.com/