A Pocket Full Of Nerdry

So I wasted a bit of time writing a piece of software for my wife. Nothing spectacular, mind, just a little something she wanted. It's rather silly, but it is an electronic double slide-rule for stitch calculations in knitting.

Why? Because Smacky has become a big knitter in the last year or two, and she has had this little paper slide-rule which helps convert knitting patterns using different needle sizes, larger size in inches, et cetera.

So I figured out the (very simple) math involved with the slide-rule, and began to write code. Luckily I have a great RAD tool for Palm, which helped me create a little Palm program for Smacky that not only does the slide-rule calcs, but does two of them at the same time, so you can convert with both source and target on the same screen. Nifty.

I finished the prototype in an hour or two the first night, and was pretty happy with the results. Initial testing seemed to be fine, but occasionally I would be off by one with my calculations. Grr. Why?

Because of rounding. Duh. Well, no problem, I'll just round the result. What? No round() function?! Crap. Well that sucks. I actually was a bit upset with Orbforms for a bit, since it seems like you should always have a round() function. Then it hit me: add one-half and then cast to an integer.

Another "duh" moment. Why didn't I think of that right away? I quickly typed it in and of course my numbers were correct because of it. For those non-geek readers, "casting to an integer" is basically forcing a conversion from the number with fractions to a number without a fraction. So, by "casting to an integer" I can force 9.4523 to become 9. By adding a half, I get the rounding effect, since anything X.5 and up will become the next highest number, while anything under X.5 stays the same number. So 9.4523 becomes 9.9523 and casts to 9. Whereas 9.5423 becomes 10.0423 and casts to 10. Neat.

Geeky crap like that is fun. For me at least.