Some folks at Mathworks read this blog. I know because I get referrals from Mathworks internal wikis and bug trackers.
I also know because I’ve seen a few documentation changes. For example, you guys have updated the documentation for “sparse” to reflect that it adds together overlapping indices rather than overwriting them like normal arrays; you updated the docs on “randsample” to reflect that it draws random samples from arrays only if they are at least 2 elements long; you even updated the docs for “getframe” to clarify that you need to turn off the fucking screen saver and walk away from the computer like it’s 1992.
Ahem. You guys are missing the point. Let me repeat from before.
It’s not that MATLAB’s behavior isn’t documented; it’s that the behavior is stupid, and leads to errors when your users (reasonably) assume that behavior would be consistent over array dimensions, or that behavior would be consistent between different but related functions, or that behavior would be consistent within a single function, or that things would just not be busted in general.
I liked the previous, unmodified documentation. It reflected the intentions of your programmers; clearly they were trying to implement the reasonable and useful things they described. It’s too bad you don’t have the wherewithal to finish the job you clearly meant to do and fix the stupid behavior.
Permalink
3 Comments
Occasionally I try to work around problems with MATLAB’s shitty slow performance by using its “profiler.”
A profiler is simple in concept: It records how much time a program spends in various functions, so you can tell which ones are slowing you down. There are a couple of different ways to implement a profiler: You could arrange to interrupt the language runtime every millisecond or so and see what functions you’re in the middle of executing. Alternately, you could arrange to record the time every function call begins or ends. Both these techniques involve either instrumenting the runtime, or concurrency and runtime introspection — that’s the kind of runtime stuff that MATLAB doesn’t provide users access to, so instead of being able to actually write a profiler, we have to rely on what profiling ability TMW’s programmers have already built into the runtime.
But fundamentally, that’s the hard part. After you’ve instrumented your runtime and are recording data while the program runs, everything after that is just tabulating and adding up numbers.
Which leads me to ask, how the fuck is MATLAB fucking up at the “adding up numbers” part so badly?
No, I do not have 36 CPUs in my machine, and mainLoop>go does not recurse on itself at all, either.
More after the jump… Read the rest of this entry »
Permalink
Leave a Comment
GETFRAME returns a movie frame. The frame is a snapshot
of the current axis.
No it bloody well isn’t. GETFRAME (as least on OS X) captures a snapshot of the portion of the display screen that might or might or might not have the current axis on top. If you have a long-running script to produce an animation, you might be tempted to switch over to read email or a PDF while your animation renders. In which case, when all is finished, you’ll find yourself a nice AVI file full of your email and none of your calculations. You want to render animations using GETFRAME, better have a single task computer to dedicate to it, and make sure to turn off the screen saver. What is this, 1992?
Permalink
4 Comments
