3 ms·
When I was a grad student, some code for drawing axes would draw a tick on one side, go all the way to the other side and then swing all the way back. The moto
by bluenose69 5y ago
When I was a grad student, some code for drawing axes would draw a tick on one side, go all the way to the other side and then swing all the way back. The motor was strong enough to make the table sway back and forth, and of course this method was slow. I remember writing code to draw a tick, come back on the tick, and then draw along the axis to the next tick. Presto, much faster!
We also had an HP plotter connected to one of those large (typewriter-sized) HP calculators, and I also wrote code to graph on that, too.
All of this was pretty low-level stuff, but not difficult, and the rewards were high for a grad student trying to get science done.
Fun times. And a step up from summer work preceding it, when I had to boot my machine by toggling binary switches for certain binary sequence that had to be loaded before it would start to read paper tape.
I think I'm old.
- rbanffy 5y ago> I think I'm old. No. We’re vintage.
- neilv 5y ago> some code for drawing axes would draw a tick on one side, go all the way to the other side and then swing all the way back. Things like that were a weird combination of cool and hilarious, but in some cases you could turn it doubly cool. When I was an intern, there was an old poster-size (D?) HP X-Y color pen plotter. Probably someone got for EDA/ECAD by our in-circuit emulator business, but someone had made a tool to make it work with CASE platform. Being able to put a poster-size view of your system in team's area was pretty cool. (Though a Gantt diagram on the wall, of your team's entire project, to projected completion, was even cooler.) The problem, like with those axis ticks, was that the HP-GL from our software wasn't very aware of the implications of a pen plotter, especially not the usual kind, which had to return home to change pens. Which made it almost comically slow to watch printing (though still impressive that it could draw one color for a few seconds, go change a pen for a few seconds, and then possibly return to approximately the same place, and repeat). So, as one of my energetic intern midnight unofficial projects was to write an optimizer that read in that HP-GL and spit out HP-GL that would print faster. Rather than solve hard optimization problems, IIRC, I tried this very simple approach: 1. Do all the drawing for a single pen color in one go, before you switch pens. (Even with a rolling plotter, rather than a bed plotter, the mechanics of the pen change seemed to make it the most expensive operation.) 2. When you're done with one drawing operation, pick the next operation based on which has the nearest start point to the current pen position. (Greatly reduce the duration of pen-up movements that are not due to pen changes.) The speedup from that very simple approach was dramatic, as you might be able to imagine, even if you've never seen a pen plotter work. (If it hadn't worked so well, I'd have had to be smarter about optimization, like looking ahead multiple steps in a plan rather than just looking for the nearest start point, and getting more flexibility, like being able to reverse the direction that a pen-down movement is drawn. Or maybe you'd even even sometimes break up an atomic movement, for a really big win, like in the hypothetical of a few-foot border segment drawn along a page, and near midpoint of that border axis has a little adornment drawn. In that hypothetical, you could draw the half the border, pick up the adornment, and then resume the border, gaining speed at the cost of your border looking slightly less perfect.)