Not sure how you did the multiplication. When I do it in my head I just do the same process as I do on paper.

for larger multi-digit calculations I break it down into 10s and 100s and up, and simply complete or reverse the calculations whenever it comes to a single digit... to explain using the above example...

26 * 27... 27 is closer to an even 10, so I use it as my base... 26 * 10 = 260... the closest 10 to 27 is 30, so I do the same computation as before 3 times... basically reaching the result of 26 * 30 which is 780...then since I moved UP I reverse the calculation to a degree, subtracting the 3 I added to my computation... 26 * 3 = 78... 780 - 78 = 702

the irony of this method is that for the right person it is faster and just as accurate as any other method... and I remember in high school I freaked people out to the point one of them would sit and wait for me in 7th period with a calculator... and ask me random things like 267 * 543 or whatever, and in a short period of time, I would give him an answer and he would just stare dumbfounded... and YET, my math teachers refused to accept this as a viable method of doing my work... because they couldnt "see" how I reached my conclusions...

Very interesting way of doing it... I'm not quick doing it the good old fashioned way in my head, but usually if I can keep the numbers straight I'm reasonably accurate.

There's a much simpler solution to the cube problem, I think. If you remove all the cubes that have paint on them, you're left with a 8x8x8 cube, which has 512 smaller cubes. Since we know there are 1000 smaller cubes total in the 10x10x10 cube, all we need to do is subtract the number of cubes that don't have paint on them to get the number of cubes that do. :3 Thus, there are 1000-512=488 cubes that do have paint on them. n.n

To put it more abstractly, if you have a AxBxC cube, then there will be (A-2)x(B-2)x(C-2) smaller cubes that do not have any paint on them, and [AxBxC]-[(A-2)x(B-2)x(C-2)] that do have paint on them. n.n

it is simpler to some people yes... but my mind has a tendency to handle math differently... Which was why I was actually surprised when I read some of the comments on the Y!News article and saw people mentioning that particular method as well...

100 + 100 + 80 + 80 + 64 + 64 cubes. To do those in my head I'd do 200 + 160 = 360; 360 + 128 = 488. More interesting math would be to figure out how many have paint on one side, two sides and three sides. (384, 96 and 8, respectively.)

"coin flips to simulate a d6?"

From information theoretical standpoint, three. Roll of d6 has 2.585 bits worth of entropy and one coin flip generates 1 bit of entropy. In practice working with this small entropy pool, we inevitably waste more bits than that when converting between sources and sinks that result in using fractional bits. However, the more die rolls we need to generate, the closer to the expected value of log₂(6) consumed bits of entropy per roll we can get.
(Also, as example for conversions that don't result in using fractional bits, we could generate a d4 or d8 with no loss of entropy to inefficiency because log₂(4) and log₂(8) are integers.)

Randomness is a topic of interest to me, and I've even implemented my own high quality random generators to replace the really awful standard libc rand() in MS Visual C++, and the good but slow mersenne-twister found in the new C++11 standard. (Mine use xorshift and multiply-with-carry algorithms. They have shorter periods than MT, but are approximately 10 times faster... Which is important when you need lots and lots of random numbers, such as monte-carlo simulation algorithms. (It's not gambling, it's statistical sampling named after gambling :P))


"You are outside a room. Inside the room there are two light bulbs. One light bulb is on all the time, the other light bulb only turns on when you open the door. How do you determine which light bulb is on all the time?"

Go inside the room. Close the door. Observe which one turns off. ;)

"volts to power an offshore rig?"

Any amount would do, it only determines how large current will be going through your wires for the power used by the equipment (power (watts) = voltage (volts) * current (amperes)). So, the answer depends on what the equipment you have is designed for, and balancing safety with cost of wire gauge required for wiring. Higher voltage means smaller wires, but high voltage is more dangerous to persons and has tendency to spark which is bad when there's volatile hydrocarbons around. I wouldn't be surprised if the majority of the equipment (especially consumer amenities) on a real rig would run from 12/24 volts since it almost certainly will not spark when switched with inexpensive ordinary switches. 110/230 volts does spark.

I don't really have any idea what the industrial equipment is designed to run on. There are high power 12V motors, so low voltage is not an obstacle. But I don't know if they're generally low voltage, high voltage, DC, AC or even if it's 2 or 3 phase AC...

Addendum, practical example of the die roll algorithm and how generating more than just 1 roll improves efficiency:

Pretty simple algorithm that simply throws away the unsuitable bits of entropy when generating rolls in batches of 10.

On long term average, this uses 2.857 bits of entropy (ie. flips a coin 2.857 times :P) per die roll (instead of the optimal 2.585). Pretty good!

1. Generate 26 bits of randomness. Treat it as binary number. (It will be between 0-67108863 when expressed in decimal)

2. If result(in decimal) > 60466175(decimal) (approx 10% of the time), then discard and generate another 26 bits, until the number passes the test.

3. Once the number passes, convert it to base-6.

4. Now each base-6 digit in the number (leading zeros are meaningful, eg 3 = 000000003) is a die result for d6 (in range 0-5; to get traditional die face number, add 1 to each digit after extraction). There are total of 10 digits, so 10 die roll results.

That sample number '0000000003' would mean we rolled 9 'ones' and 1 'four', pretty unlikely, but of course possible. A number like 3102452113 (note, base-6 so no digit is more than 5) would be 1*one, 3*two, 2*three, 2*four, 1*five and 1*six.


Compare it with the most naïve algorithm which does the same, but one die roll at a time:

Generate 3 bits (in decimal it will give you number between 0-7), throw away and regenerate if the result > 5 (happens 25% of time). Now the result is directly your die roll.

Long term average is 3.75 bits of entropy used per die roll. Pretty bad compared to the above algorithm that works in batches of 10.


The batch size doesn't directly correspond to improved efficiency though (for example 11 rolls at a time is worse than 10), but going higher we can eventually find a batch size that will get as close to the optimal as we want to. But there is practical consideration that working with numbers with more and more bits takes longer and longer so there is a practical maximum beyond which the

Beyond which the improvement isn't worth the effort.

"coin flips to simulate a d6? that is a fallacy really, but the closest you can come is to flip it five times and assume one result is 1 and the other is 0... start at 1... so if you flip 5 times and heads is 1, and you get 3 heads then you have 4... why 5 flips instead of 6? because if you didn't have a solid starting point then you could POTENTIALLY get 0, which is not a result on a d6... "

Incidentally, that algorithm is biased and generates a bell curve instead of even uniform distribution.

Eg, to get a 6 there is only one possible sequence of throws, all heads. (1+)1+1+1+1+1=6
But to get 3, there are several. (1+)1+1+0+0+0=3, or 1+0+1+0+0=3, or (1+)1+0+0+1+0=3, etc...

Here's a quick simulation with 1 000 000 throws:

1: 31 471 times
2: 156 874 times
3: 312 328 times
4: 312 243 times
5: 155 851 times
6: 31 233 times