Hi Mike,
I'm very conscious of speed issues all the time when I use computer-based tools. Prolly because I spent so much time addressing such issues back when we actually knew how many clock cycles an ADD required. Also built real-time embedded systems. Just got a call from a client who wanted help on a system for which I had built the software (on a real time platform). Seems that a few dozen pieces of equipment were going nuts and couldn't be controlled. We tracked the problem to a faulty instrument power supply...anyway, that system is 15 years old, and expected to last another 10. The reason? It's the fastest in its class, and two competitors have lost ~$500K trying to replace it. It's the fastest in its class because I am very conscious of CPU cycle usage in everything that I do...and that includes working with products such as Mathcad...
I seem to recall a discussion in the collab a few years ago where a grad student couldn't get his program to "run" and asked for help. We eventually discovered that his use of (I think) vectorize was making his real data analysis (9000 points) take literally days longer than it otherwise needed, so he concluded that it wasn't actually running. If he'd a waited a few days, he'd have had his answer 😉 For the small programs we run here, it doesn't matter, but I run sims that take hours..days to run, and that means paying attention to details. In our example here, we used the Mathcad sort routine - a bubble sort, I think - pretty slow, but convenient for us. Were we to consider a larger data set, we'd be better off finding some sort of programmatic approach. There is, of course, a trade off twixt the labor of doing more complicated programming and the time cost of grabbing a tool from our math toolbox.
So I'll try 😉 not to bring up speed issues too much...but...sigh...can't help but think of them...
~R~
.
