deSilva
another of possible solutions
Well, if there were only one way to "do" things (any things), life would be simpler, right?
Step1:
Find the way.
Step2:
Do it.
Step3:
Take the rest of the day off.
Problem solved. (See Footnote.)
My reduction to the ten situations from your 27 possibilities involved some simplifications that aren't really justified without having an actual Program Specification.
For example, I don't distinguish between {1, 1, 1} and {2, 2, 2} and {3, 3, 3}. I gave one example that is representative of any of these three. For your scheme, these all give a result value of zero, so that's probably pretty safe.
However, I don't distinguish between {1, 1, 2} and {1, 1, 3} and {3, 3, 1} and {3, 3, 2} and the other cases for which the first two are the same and the third is different. For your scheme, {1, 1, 2} and {1, 1, 3} give the same value of x (namely decimal 20) but {3, 3, 1} and {3, 3, 2} both give a value of decimal 40. Maybe that's a problem???
Well...
Since the Original Poster apparently doesn't want to do anything for these cases, I assumed that they are all "don't cares," and I lumped them together in my specification. This may or may not be significant in actual performance of the machine; maybe your exhaustive and systematic approach is more appropriate.
And so it goes. (Your scheme ends up with 13 unique outcomes compared with ten for mine.)
Bottom line (stop me if you have heard this before):
I think it is a Good Idea to write a complete program specification before starting to design the code (let alone beginning to implement it).
The specification can be expressed in some (human-language) narrative or as some kind of "truth table" or other tabular display that shows exactly what input conditions are to be considered and what the program is supposed to do all cases.
As far as implementation details: Use of boolean expressions to set bits in an output variable can be a real winner in terms of program run time predictability (takes the same amount of time for all cases). In a commercial setting, they can also give you a chance to learn some new swear words (and combinations thereof) from people who will be given the task of maintaining the program.
To the Original Poster (with some apologies):
Maybe this rambling about program design seems unhelpful, but I think it's important to consider how to translate human needs to a description that can be translated to machine code that has a chance of meeting the needs.
Maybe someone will write or rewrite your code into a form that meets your needs. If you don't want to "write down" the actual requirements and share them with us, well I can't see much of a way to help you learn.
However...
Different people have different ways of learning, and different people have different ways of trying to help, so it's still possible to get help.
So...
Instead of shouting that it "DOSENT WORK," I respectfully suggest that the chances for help might be improved if you:
1. Tell us exactly what the program was working on (what were the inputs) when you observed that it didn't work as expected.
2. Tell us exactly what you expected the program to do with these inputs.
(Oh, wait: That's almost the same as writing a Program Specification.)
3. Tell us exactly what the program did.
4. Tell us what you don't understand about the difference between steps 2 and 3.
Regards,
Dave
Footnote:
Richard Feynman's approach to problem solving:
-
Write down the problem.
-
Think real hard.
-
Write down the solution.