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.
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.
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.
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.
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.
Things that scale can have a big multiplier, so to say. The problem is, more often than anticipated, that multiplier, rather than being large, ends up being considerably less than one.
Whereas work that doesn't scale always has a multiplier of 1, so its always useful.
Since a daily activity once checked presumably never become unchecked, this could be just a big sheet of hexagons you can color in when the activity is done. Yes, you need to print out a new one once a year, but that's pretty trivial cost and time wise compared to the calendar gadget. Granted, the calendar is a cool gadget.
regardless of what happens inside the S-curve, the opening ends up getting a slight vacuum from suction, but there is no such suction on the opposite side.
Imagine the S is straight, but a vane attached to the side of the pipe blocks suction from one side.
I tried to illustrate this in ascii art, but it appears HN has an algorithm to destroy ascii art.
That vane will now have a slight vacuum on the side of the pipe, and it seems logical that it should want to move in that direction.
Now imagine that vane curved around the pipe so it forms the end of the S-bend. Same thing.
I have done something like that at times. I find the bug in the afternoon. Now I have the satisfaction of having found it and don't want to risk the frustration of it not actually being the actual bug I found. So I saved it for the next day, to milk the satisfaction again, but also to be more fresh at it to fix it right and test it, or to better be able to deal with it not being the actual bug!
Though my boss at some point was puzzled "why don't you just fix it now?"
I have come to that conclusion myself over the years too.
But "bad people" or aholes also have usefulness. You sometimes need people to challenge things that only an unreasonable person would challenge. And you need the occasional Steve Jobs too.
But unlike altruistic people, we generally don't give the aholes as much credit. So, ironically, perhaps altruism is the better self serving strategy.
The first half of the movie mixes a lot of stuff up date and time wise, and adds a bunch of completely fictional sub-plots.
I worked at RIM from 1993 to 2007
Back around 2006 I used "panorama tools" to do the same sort of thing. It had this cool feature of being able to work out lens calibration if it had two photos from the same viewpoint but different angles. It did however require careful tagging of reference points on each image.