MatthiasWandel

Gotta agree with you there, log splitters rule. We got a little 4 ton electric one for my mom, and on some pieces it would stall. I thought, what a wimpy thing, but then hitting those pieces it wouldn't split with an axe, I realized, those were really hard to split pieces. Just growing up in the 80s we didn't have one cause my dad didn't believe in them.

A 12 year old can indeed acquire that skill, but that doesn't mean any adult can do it.

I once took a sledgehammer to work so everyone could take a turn taking a whack at some old prototypes outside. I came to the sad realization that even hitting a particular spot with a sledgehammer is not an inate skill. If you've never done it, you miss!

Looks like its coded by someone who has never split firewood. The challenge is not deciding where to split, its executing the split. Like hitting the same gap if it doesn't split, deciding orientation to aoid knots, figuring out how to put it on end if it wasn't cut straight.

And some of the cuts it allowed me would hit the ax handle on another part, the shock from that damages the ax handle and is painful on the hands.

And then there's the lifting the stuck block by the axe and hitting it axe side down to finish the split instead of pulling the stuck axe out.

So the simulation handles none of the challenges of splitting wood.

A downside of profile shift is that you get away from the pitch diameter. At the pitch diameter, there's no friction on the teeth, the further away you get, the more friction. But any hand drill will have a gear with less than ten teeth cut into the motor's shaft to drive the first gear, and they work just fine.

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.

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

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.

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.

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.

yes

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.

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.