Or stupidly. I don't know if the following should qualify as an edge case generally, but it does in Matlab.
The controls lab in the aerospace department at the U of W had a wonderful inverted cart-pendulum device that a grad student was doing some seriously freaky non-linear control research on. We were tasked, as part of a lab, to write a controller in Matlab that would balance the pendulum and move the cart to a designated position. After trying for days to come up with a combination of gains to result in stable control, I decided to write an evolutionary algorithm to choose a controller.
It was dead simple. The genome was a list of gains. The code created generations of genomes and then ran them through the simulation. The tricky part (for me at that time) was finding the settling time (walk backwards from the end of the data, checking for values outside of the tolerance). Choose the winners, perturb, preserve best performers, and go around again. Doing all the steps by hand worked wonderfully.
When I ran the code, I got combinations of gains that resulted in massively unstable systems; systems that overshot off the chart as soon as physically possible given the hardware. What was going on?
It turns out, when I ran the simulation from the command line, Matlab graciously accepted my 5-second simulation time. However, when run from a script, Matlab ignores that parameter and runs the simulation until the output careers off the chart. Because I was looking for a minimum time with no overshoot, my algorithm was finding combinations of gains that overshot steeply enough to convince Matlab to stop simulating ASAP! It was bizarre. My secondary condition was minimum overshoot, so I got solutions that were exactly steep enough to cause the simulation to stop when the output hit the desired value!
A friend of mine stumbled on to a workable combination of gains. I used those.
You're misrepresenting the situation a bit. Matlab was not stupid here. The evolutionary algorithm you implemented found a way to satisfy your constraints that you didn't think of. That would have happened regardless of the language you chose.
I'm not arguing that Matlab is beautiful - it's not. I have worked in Matlab for years and years, and know most of its ugliness. But your example highlights your frustration with the task more than any particular weakness of Matlab.
The point is that the behavior changes based on whether you are running from the command line or from inside a script, that this is completely arbitrary, and that there was no override possible for this behavior. When run from the command line, simulations for combinations of gains that caused the system to career away did indeed career away, they just continued to do so for the full length of time specified in the function call. That kind of abject flakiness renders the program unsuitable for professional use in that you can't plan for those kind of quirks. I had invested hours by the time I worked out what the bug was, and invested hours more trying to fix it. I finally had to give up, after investing my time and effort, because the platform was fundamentally and fatally incapable of doing what it was asked.
It is completely unacceptable for a package to have such wildly different (and undocumented) behavior for the same exact function call. Matlab was indeed stupid. It was a buggy minefield of stupidity when I was using it.
Finally, it looks like your defense of this awful weakness on the part of Matlab is, ironically, a result of your commitment to the platform rather than a reasoned response to the case outlined.
It seems I didn't read the final paragraph in your original post very well.
I was not defending a weakness of Matlab, but instead misunderstood what you said. Indeed, I'm a pretty harsh Matlab critic myself because I know its ugly parts well.
Or stupidly. I don't know if the following should qualify as an edge case generally, but it does in Matlab.
The controls lab in the aerospace department at the U of W had a wonderful inverted cart-pendulum device that a grad student was doing some seriously freaky non-linear control research on. We were tasked, as part of a lab, to write a controller in Matlab that would balance the pendulum and move the cart to a designated position. After trying for days to come up with a combination of gains to result in stable control, I decided to write an evolutionary algorithm to choose a controller.
It was dead simple. The genome was a list of gains. The code created generations of genomes and then ran them through the simulation. The tricky part (for me at that time) was finding the settling time (walk backwards from the end of the data, checking for values outside of the tolerance). Choose the winners, perturb, preserve best performers, and go around again. Doing all the steps by hand worked wonderfully.
When I ran the code, I got combinations of gains that resulted in massively unstable systems; systems that overshot off the chart as soon as physically possible given the hardware. What was going on?
It turns out, when I ran the simulation from the command line, Matlab graciously accepted my 5-second simulation time. However, when run from a script, Matlab ignores that parameter and runs the simulation until the output careers off the chart. Because I was looking for a minimum time with no overshoot, my algorithm was finding combinations of gains that overshot steeply enough to convince Matlab to stop simulating ASAP! It was bizarre. My secondary condition was minimum overshoot, so I got solutions that were exactly steep enough to cause the simulation to stop when the output hit the desired value!
A friend of mine stumbled on to a workable combination of gains. I used those.