The bottleneck with the pointer table may be the summation. While the fetches of elements can be parallelized, the summation can not, as the addition depends on the result of the previous addition being available.

Some experiments I have done with something that does summation showed a considerable speedup by summing odd and even values into separate bins. Although this applies only to doing something not too closely resembling signal processing algorithms, as the compiler can otherwise optimize out for that.

Part of my video titled "new computers don't speed up old code"

An interesting aspect is data dependencies. If your next statement reuses data you just computed, that can cause pipeline bubbles, as that result you want to use just isn't available yet. I dived into that topic for a video about relative performance of old PCs I just published today.

Yes, there is non-obvious structure in some algorithms solely for the purpose of turning a single logical stream of dependent instructions into multiple concurrent streams of dependent instructions running through the same pipeline. The caveat of doing this, of course, is that it typically increases register pressure.

nice, but spotted several inaccuracies on the landing page. perhaps not the best reference.

Yes, very first item:-

> When your finger gets close to the screen it causes a disturbance in the magnetic field that the electrodes sense.

Sure should be capacitive?

Disappointed to see the dots around it all appear to be the same spacing. They should be at different spacing, corresponding to strobe sync with 50 and 60 hz mains and 33.33 and 45 RPM. Hence four rings with different number of dots around the perimeter.

They are at different spacings. If you follow two rows of dots around, they fall in and out of sync with each other.

Now someone has to go there and drive around it at 33 1/3 rpm at night with a strobe light set to 50 Hz.

Hmm. If the diameter of the circle that the car drives in is 14 meters, that works out as ... 54657 mph. I cannot endorse this from a safety standpoint.

Wait, no, I was working in km instead of m, it's only 54 mph. Should be fine.

It's one revolution every 1.8 seconds. That seems too fast for most roundabouts, but maybe not uncontrollably so.

78 rpm is Formula One territory.

I'm sure they would not have been less than £850 in whatever currency it was sold in back then, inflation adjusted. But the justification was much better than being a fidget toy.

Oh definitely, prior to having cheap computers that can compute gigaflops, I would definitely have bought one to do number crunching.

The problem is that if I bought one now, it would simply be a toy and nothing else. That's just a bit more than I'm willing to spend.

Update it with USB so that it can take input and return results. Hook it up to a cash register for something like an antique store. Ideally one selling small items so that the customer can marvel at the display adding things up.

I also have always wanted one of those mechanical vintage cash registers, for the same reason I have always wanted a Curta. They always seemed like they would be fun to play with.

I could probably get one of those cash registers to play with for not a ton of money, but my house isn't huge and it's hard to justify the space.

I wrote the calculator for the original blackberry. Floating point won't do. I implemented decimal based floating point functions to avoid these rounding problems. This sounds harder than it was, basically, the "exponent" part wasn't how many bits to shift, but what power of two to divide by, so that 0.1, 0.001 etc can be represented exactly. Not sure if I had two or three digits of precision beyond whats on the display. 1 digit is pretty standard for 5 function calculators, scientific ones typically have two. It was only a 5 function calculator, so not that hard, plus there was no floating point library by default so doing any floating point really ballooned the size of an app with the floating point library.

> the "exponent" part wasn't how many bits to shift, but what power of two to divide by, so that 0.1, 0.001 etc can be represented exactly

You mean what power of ten to divide by?

yes

Holy shit, I thought you just made mindblowing mechanical devices.

I can see why you wouldn't necessarily just want to use it, but I thought the RIM pager had a JVM with floating point?

I mostly just used mine for email.

The JVM based devices came years later. This was around 1998, with the 386 based blackbery pager that could only do emails over Mobitex, no phone calls. It even looked like a pager. At the time, phones were not so dominant, data switched over mobile only existed on paper, and two-way paging looked like it had a future. So we totally killed the crude 2-way paging networks that were out there. And RIM successfully later made the transition to phone networks. Wasn't till iPhone and android that RIM ran into trouble.

Yup, that's the one I had. Best keyboard I ever used on a pocket device. So I used your calculator, a little.

Cutting away a lot with a router is a slow, noisy and dusty process. Less work to just glue together the channels out of smaller pieces of wood. Also, that way you can take individual pipes out and tweak them (called voicing).

Another thing to be wary of -- pipes too close together sometimes pull together in pitch if both are played at the same time.

I remember spell checking my essays for high school on the commodore 64, using Paperclip 64, in 1984, Before there was ANY Microsoft windows. Spell check took a few minutes, because it read the dictionary from disk as it checked, and after that you could go thru all the words that it couldn't match.

Was your copy of Paperclip 64 pirated?

Actually not fair criticism, given that I even talk about changing the control parameters and demonstrate the effect of changing them.

Please re-watch the video, but THIS TIME PAY ATTENTION. I do talk about the motion parameters, even show the code on the screen briefly. I even show the effects of changing the parameters.