My wife and I were watching a very old Julia Child cooking episode on YouTube when we noticed something interesting. OK, I noticed -- she was oblivious.
This was an episode where Julia was extolling the uses of eggs in things like chocolate mousse. The video alternated between face-on views and top-down, showing the whisking action when Julia was beating egg yolks and stuff like that on the stove. I noticed the top views showed Julia using her left hand beating the eggs and whisking stuff etc. But the face-on views showed her using her right hand. Finally, I saw a top down view that showed several pots on the stove, and the arrangement was reversed between the top-down view and face-on view.
So, here's an interesting observation. Maybe it's been noted before, but a quick internet search did not reveal any confusion about Julia's handed-ness. I think the top-down views were done using a mirror, so the viewpoint was reversed. Perhaps today's directors are more concerned about consistency from shot to shot so that doesn't happen now....maybe.
I would be interested to know if anyone else has noticed this in the old Julia Child episodes.
Saturday, December 31, 2016
Thursday, December 22, 2016
Repeating decimals and encoding messages
I have another math nurd post.
It has a loose relationship with a branch of mathematics called number theory, and a close relationship to a sleepless night.
I was (for no obvious reason) thinking about repeating decimal numbers that are the result of dividing one number by another. A good example: .33333.... = 1/3.
I started wondering if would be possible to define two numbers A and B to generate any arbitrary sequence of repeating decimal numbers when calculating A/B. Oh yes, those dark winter nights! For a triplet of repeating digits, my initial mental math went like this:
A/B = .WXYWXYWXY.....
where W,X and Y are numbers between 0 and 9
Multiply A/B by 1000 and we get: 1000*A/B = WXY.WXYWXYWXY....
The value behind the decimal, clearly, is the same as A/B so we can write:
1000*A/B = WXY*A/B. If we divide both sides by A/B we get: 1000 = WXY. Clearly, there is no sequence of 3 digits that can equal 1000 (999 is the closest we can get). So it would appear that there is no solution for this.
Not so. Let's say WXY = 123. Now set A = 123 and B = 999. Get out the old 4-banger calculator and what do we see? 123/999 = 0.123123....
So what is the problem here? Unfortunately, simple math (remember I mentioned it was a late night). The real equation for this relationship is as follows: 1000*A/B = WXY + A/B. Where WXY really equals W*10^2 + X*10^1 + Y*10^0
If we go back to setting WXY = 123, we get: 1000*A/B = 123 +A/B, or 999A/B=123. I.E., 999A = 123B, or A/B = 123/999. Do the division again, and you get: .123123....
A straightforward generalization tells us that we can generate any arbitrary repeating-decimal number by multiplying the sequence of numbers by the power of 10 equal to the length of the sequence and dividing it by 10^K -1, where K is the length of the sequence.
An interesting possibility raises itself in this discussion of rudimentary numerical analysis. Suppose we encode the alphabet by setting A = 01, B = 02....Z = 26. If you have a message you want to send securely, encode it into a string of tuples (2 digits each) and treat the whole thing as your repeating rational number. Unfortunately, not too hard to decyper, right? Well, now multiply the W-wide number (equal to 2*the number of characters in your message) by another number, large enough to ensure some carries between each tuple. NOW we have a more interesting thing to decode, because the resulting tuples depend on each other. It becomes a context-dependent code. The keys to the code are the multiplier....and the length of the message. In today's age, the two could be sent separately without too much trouble so time-sensitive information (which would take some time to decode) would be relatively secure. Attempts to crack the code would be complicated by the fact that the encoded message string is unique due to the context dependency.
Suppose we choose the multiplier to be 11. This is an interesting example because it is equivalent to shifting the original code over by one, and adding the result to the original code. It would completely alter the cypher.
Is this completely original? Hah --- close to a zero chance of that. But it is an interesting illustration of how easily a simple encoding scheme could be turned into a nontrivial decyphering problem, except for government level expertise. Also, due to the fact that certain letter sequences occur pretty often, the encoding scheme would be susceptible to statistical analysis -- if long enough.
Relatively simple obsfucation techniques like reversing the digit sequence would still yield to this type of analysis, if the analysis is thorough enough. Possibilities are endless though -- consider encoding some well-known text in the same fashion and adding its digit sequence to the message. This is an example of the use of a code book, in addition to the mathematical encoding. Without knowledge of the code book (and where the code string begins), things get difficult in a big hurry. The code book string itself could be mathematically obsfucated by using yet a different multiplier. And maybe reversed (or not) as well. Ouch!
It has a loose relationship with a branch of mathematics called number theory, and a close relationship to a sleepless night.
I was (for no obvious reason) thinking about repeating decimal numbers that are the result of dividing one number by another. A good example: .33333.... = 1/3.
I started wondering if would be possible to define two numbers A and B to generate any arbitrary sequence of repeating decimal numbers when calculating A/B. Oh yes, those dark winter nights! For a triplet of repeating digits, my initial mental math went like this:
A/B = .WXYWXYWXY.....
where W,X and Y are numbers between 0 and 9
Multiply A/B by 1000 and we get: 1000*A/B = WXY.WXYWXYWXY....
The value behind the decimal, clearly, is the same as A/B so we can write:
1000*A/B = WXY*A/B. If we divide both sides by A/B we get: 1000 = WXY. Clearly, there is no sequence of 3 digits that can equal 1000 (999 is the closest we can get). So it would appear that there is no solution for this.
Not so. Let's say WXY = 123. Now set A = 123 and B = 999. Get out the old 4-banger calculator and what do we see? 123/999 = 0.123123....
So what is the problem here? Unfortunately, simple math (remember I mentioned it was a late night). The real equation for this relationship is as follows: 1000*A/B = WXY + A/B. Where WXY really equals W*10^2 + X*10^1 + Y*10^0
If we go back to setting WXY = 123, we get: 1000*A/B = 123 +A/B, or 999A/B=123. I.E., 999A = 123B, or A/B = 123/999. Do the division again, and you get: .123123....
A straightforward generalization tells us that we can generate any arbitrary repeating-decimal number by multiplying the sequence of numbers by the power of 10 equal to the length of the sequence and dividing it by 10^K -1, where K is the length of the sequence.
An interesting possibility raises itself in this discussion of rudimentary numerical analysis. Suppose we encode the alphabet by setting A = 01, B = 02....Z = 26. If you have a message you want to send securely, encode it into a string of tuples (2 digits each) and treat the whole thing as your repeating rational number. Unfortunately, not too hard to decyper, right? Well, now multiply the W-wide number (equal to 2*the number of characters in your message) by another number, large enough to ensure some carries between each tuple. NOW we have a more interesting thing to decode, because the resulting tuples depend on each other. It becomes a context-dependent code. The keys to the code are the multiplier....and the length of the message. In today's age, the two could be sent separately without too much trouble so time-sensitive information (which would take some time to decode) would be relatively secure. Attempts to crack the code would be complicated by the fact that the encoded message string is unique due to the context dependency.
Suppose we choose the multiplier to be 11. This is an interesting example because it is equivalent to shifting the original code over by one, and adding the result to the original code. It would completely alter the cypher.
Is this completely original? Hah --- close to a zero chance of that. But it is an interesting illustration of how easily a simple encoding scheme could be turned into a nontrivial decyphering problem, except for government level expertise. Also, due to the fact that certain letter sequences occur pretty often, the encoding scheme would be susceptible to statistical analysis -- if long enough.
Relatively simple obsfucation techniques like reversing the digit sequence would still yield to this type of analysis, if the analysis is thorough enough. Possibilities are endless though -- consider encoding some well-known text in the same fashion and adding its digit sequence to the message. This is an example of the use of a code book, in addition to the mathematical encoding. Without knowledge of the code book (and where the code string begins), things get difficult in a big hurry. The code book string itself could be mathematically obsfucated by using yet a different multiplier. And maybe reversed (or not) as well. Ouch!
Thursday, December 15, 2016
A different sort of anti-backlash scheme for an X2 mini mill, and serendipity
Over the last year or so I've been (slowly) working on testing a different type of anti-backlash system for my SX2 mini mill. This approach does not use traditional spring-loaded nuts, split nuts or heat-formed acetal nuts.
The original approach involved two nuts -- the standard, as-installed one, that is installed into the X or Y axis table, and a second "traveling" nut. The traveling nut is constrained inside a cage that is bolted to the table. In use, the feed screw is turned and the traveling nut is carried to one side or the other of the cage. Once it fetches up against the cage, the slop or backlash of the system is removed.
I tested this idea using some all-thread, two nuts and two aluminum angle brackets, and it worked. I did find that the system was sensitive to misalignment, to the point that a little misalignment would cause the traveling nut to "freeze up", making it impossible to turn the feed screw (in that case, the all-thread).
Here's a photo of my test setup:
You can see that I used the table of my mill as the test bed for this.
So I proceeded to the next step, making a bracket for the traveling nut cage, modifying a nut to fit in the bracket, and drilling/tapping two 8mm holes to mount the bracket on the right side of the saddle (I was going to mod the X axis first, because that looked to be a lot easier than the Y axis).
The final results are shown here:
The bracket is on top and the traveling nut is between the two 8mm bolts. The bracket has a slot to accommodate the traveling nut. In use, the idea was to insert the nut in the slot and then advance the bracket down the feed screw until it could be bolted to the saddle.
However, when I did this I found that the traveling nut would seize up once the feed screw had been turned a revolution or two. I thought the problem was a combination of the rather tight fit of the nut on the feed screw, and machining tolerances of the bracket (i.e., my so-so machining skills). I tried shimming but there was no improvement.
Here is where the serendipity comes into play. I started thinking about a variation on this, similar to an anti-backlash scheme I has seen on a Sherline CNC-ready mill. They have a nut that is on the exterior of the table, held in place by what appears to be a fine-tooth gear. The gear is loosened enough to rotate the nut so it snugs up against the table, then tightened.
So I took a second bit of my modified nut (I had cut it into two pieces) and fed it up against the exterior of my bracket. I had removed the traveling nut at this point. The idea was to use the bracket to implement something like the Sherline approach, and I needed to know the orientation of the nut when it fetched up against the bracket. But to my surprise, when I brought the nut up to the bracket, the feed screw did not seize up. And the backlash disappeared! Well, this was interesting. More interestingly, when I used my original traveling nut, it DID seize up. Whoa. That seemed to eliminate tolerance variations on the exterior surface of the bracket.
So I took a closer look at my two nuts (please, no jokes here ... alright, I can't keep you from going there). The main difference was a ridge left on the edge of the second nut. Maybe it was acting as a little buffer to ease the mechanics of the system. To test this hypothesis, I sanded the end surfaces of the second nut smooth (I had already done this on my original traveling nut) and re-installed it. It now behaved the same, locking up with a turn or so of the feed screw.
With the "buffer" hypothesis in mind, I fabricated a rubber gasket out of some rubber sheet, maybe 1/16" thick. The gasket ID was the same as the feed screw OD, and the gasket OD matched the external nut. Bracket installed, followed by rubber gasket and nut:
And this works! The nut fetches up against the gasket with enough force to prevent it from backing out when the feed screw motion is reversed, and the backlash goes to zero.
Now, I don't know if this nice combination of items and effects will be robust or not -- it's possible that lube grease from the feed screw will find its way between the gasket and external nut so it will loosen up. If so, I can use a scheme akin to the Sherline approach to fix the nut in place. I'm thinking of a hole drilled in the nut, pin installed to match a little arm that engages the pin on one side, slotted on the other (for adjustment) and fixed in place with a screw that eventually screws into the bracket. This approach won't apply any axial force to the nut/feedscrew combo, just keep things from rotating.
CONCLUSION:
Don't give up! If something doesn't work out as you expected, analyze the setup, experiment, make an hypothesis and test it. Repeat as needed. Don't forget to gratefully accept what lady Serendip gives you.
The original approach involved two nuts -- the standard, as-installed one, that is installed into the X or Y axis table, and a second "traveling" nut. The traveling nut is constrained inside a cage that is bolted to the table. In use, the feed screw is turned and the traveling nut is carried to one side or the other of the cage. Once it fetches up against the cage, the slop or backlash of the system is removed.
I tested this idea using some all-thread, two nuts and two aluminum angle brackets, and it worked. I did find that the system was sensitive to misalignment, to the point that a little misalignment would cause the traveling nut to "freeze up", making it impossible to turn the feed screw (in that case, the all-thread).
Here's a photo of my test setup:
You can see that I used the table of my mill as the test bed for this.
So I proceeded to the next step, making a bracket for the traveling nut cage, modifying a nut to fit in the bracket, and drilling/tapping two 8mm holes to mount the bracket on the right side of the saddle (I was going to mod the X axis first, because that looked to be a lot easier than the Y axis).
The final results are shown here:
However, when I did this I found that the traveling nut would seize up once the feed screw had been turned a revolution or two. I thought the problem was a combination of the rather tight fit of the nut on the feed screw, and machining tolerances of the bracket (i.e., my so-so machining skills). I tried shimming but there was no improvement.
Here is where the serendipity comes into play. I started thinking about a variation on this, similar to an anti-backlash scheme I has seen on a Sherline CNC-ready mill. They have a nut that is on the exterior of the table, held in place by what appears to be a fine-tooth gear. The gear is loosened enough to rotate the nut so it snugs up against the table, then tightened.
So I took a second bit of my modified nut (I had cut it into two pieces) and fed it up against the exterior of my bracket. I had removed the traveling nut at this point. The idea was to use the bracket to implement something like the Sherline approach, and I needed to know the orientation of the nut when it fetched up against the bracket. But to my surprise, when I brought the nut up to the bracket, the feed screw did not seize up. And the backlash disappeared! Well, this was interesting. More interestingly, when I used my original traveling nut, it DID seize up. Whoa. That seemed to eliminate tolerance variations on the exterior surface of the bracket.
So I took a closer look at my two nuts (please, no jokes here ... alright, I can't keep you from going there). The main difference was a ridge left on the edge of the second nut. Maybe it was acting as a little buffer to ease the mechanics of the system. To test this hypothesis, I sanded the end surfaces of the second nut smooth (I had already done this on my original traveling nut) and re-installed it. It now behaved the same, locking up with a turn or so of the feed screw.
With the "buffer" hypothesis in mind, I fabricated a rubber gasket out of some rubber sheet, maybe 1/16" thick. The gasket ID was the same as the feed screw OD, and the gasket OD matched the external nut. Bracket installed, followed by rubber gasket and nut:
Now, I don't know if this nice combination of items and effects will be robust or not -- it's possible that lube grease from the feed screw will find its way between the gasket and external nut so it will loosen up. If so, I can use a scheme akin to the Sherline approach to fix the nut in place. I'm thinking of a hole drilled in the nut, pin installed to match a little arm that engages the pin on one side, slotted on the other (for adjustment) and fixed in place with a screw that eventually screws into the bracket. This approach won't apply any axial force to the nut/feedscrew combo, just keep things from rotating.
CONCLUSION:
Don't give up! If something doesn't work out as you expected, analyze the setup, experiment, make an hypothesis and test it. Repeat as needed. Don't forget to gratefully accept what lady Serendip gives you.
Subscribe to:
Posts (Atom)