comparing three values

could anyone please help me with a code i want the arduino to be able to compare values of three sensors well this is the thing whati want to do

three sensors --> threepins
let them be 1,2,3
now compare 1,2,3
if 1>2,3 --> action a
if 2>1,3 --> action b
if 3>1,2 --> action c
if 1=2=3 --> action d

any one please help me :-[

You haven't covered all possibilities.
For example:
What if value1 == value2 and that value is > value3

I respectfully suggest that you make sure you know what you want the program to do before you start writing code.

Regards,

Dave

Footnote:
After you know what you want to do, then you can write if that connect logical expressions with the "&&" operator like this:

    if ((value1 > value2) && (value1 > value3)) {
        //Do your "action a" thing
    }
    else if ((value2 > value1 && (value2 > value3)) {
        //Do your "action b" thing
    else if (......) {
        .
        .
        .

There are other ways, of course...

There are other ways, of course...

.. and that makes programming so exciting.

E.g.

X = 0;

X += (v1<v2);
X += (v1>v2)<<1;
X += (v1<v3)<<2;
X += (v1>v3)<<3;
X += (v2<v3)<<4;
X += (v2>v3)<<5;

switch(x) {

// there are 27 combination to be checked 

}
[glow]X[/glow] += (v2>v3)<<5;

switch([glow]x[/glow]) {

// there are 27 combination to be checked

There may be more, or less, than 27...

thanks people ill try and let you people know
i wanetd to make a line following robot so had to compare the values and deside assordingly :slight_smile:
only those three cases wer enough for me :wink:

i dont know what to do but i tried to make something will you people help me out with this that is modify id where ever necessaary and make it workable

#define m1p1 2
#define m1p2 3
#define m2p1 4
#define m2p2 5
#define sensorright 0
#define sensormiddle 1
#define sensorleft 2
#define led 13
int val1 = 0
int val2 = 0
int val3 = 0
void setup()
{
  pinMode (m1p1,OUTPUT);
  pinMode (m1p2,OUTPUT);
  pinMode (m2p1,OUTPUT);
  pinMode (m2p2,OUTPUT);
  pinMode (sensorright,INPUT);
  pinMode (sensormiddle,INPUT);
  pinMode (sensorleft,INPUT);
  pinMode (led,OUTPUT);
}
void loop()
{
  val1 = analogRead(sensorright);
  val2 = analogRead(sensormiddle);
  val3 = analogRead(sensorleft);
  if ((val1 > val2) && (val1 > val3))
  {
    digitalWrite(m1p1,LOW);
    digitalWrite(m1p2,LOW);
    digitalWrite(m2p1,HIGH);
    digitalWrite(m1p2,LOW);
    delay(1000)
  }
  else if ((val2 > val1) && (val2 > val3))
  
  {digitalWrite(m1p1,HIGH);
  digitalWrite(m1p2,LOW);
  digitalWrite(m2p1,HIGH);
  digitalWrite(m1p2,LOW);
  delay(1000)
  }
  else if ((val3 > val1) && (val3 > val2))
  {
    digitalWrite(m1p1,HIGH);
    digitalWrite(m1p2,LOW);
    digitalWrite(m2p1,LOW);
    digitalWrite(m1p2,LOW);
    delay(1000)
  }
  else if ((val1 == val2) && (val2 == val3))
  {
    digitalWrite(led,HIGH);
}

NOTE: this code "DOSENT WORK"
modify it ot make it work i just tried what i know :-[

@deSilva

exciting

Can't you make things more obfuscatory? Then it would be even more exciting, right?

there are 27 combination to be checked

Hmmm...

Well, you can check as many as you want, but, by my reckoning, there are exactly ten possibilities. I will enumerate them with examples:

One possibility with all equal.


Examples:

 1 : 1 1 1

Three possibilities with two equal and one different


Examples:

 2 : 1 1 2
 3 : 1 2 1
 4 : 2 1 1

Six possibilities with all different


Examples:

 5 : 1 2 3
 6 : 1 3 2
 7 : 2 1 3
 8 : 2 3 1
 9 : 3 1 2
10: 3 2 1

The question to the original poster: What, exactly do you need to do for each of these situations? Copy them onto a piece of paper (gasp) and write out what action you want to take for each.

That's called a Program Specification, and in my opinion, it is worth getting into the habit of writing down what it is that you require the program to do before you start writing code. Yes! Really! Write it down!

Maybe then you can express the requirements in words. Maybe then you can try to write a program that takes all cases into account. You could simply use ten if-else-if... clauses based on the ten situations that I enumerated above, but, since some of the cases may have a common outcome, I'm guessing that you might be able to do it with fewer. Also, if some of the cases don't require any action, then you don't have to have an "if" clause for that case.

After you have defined the action that the program is supposed to take for each case, then, write the logical expression that describes the case in a way that you can incorporate it into a program.

Here: I'll start with some logic expressions that are defined by some of the examples and, therefore, can be used in the if statements:


Example:

 1 : 1 1 1  (val1 == val2) && (val2 == val3)
 2 : 1 1 2  (val1 == val2) && (val1 > val3)
 3 : 1 2 1  (val1 == val3) && (val2 > val1)
.
.  etc.
.

Now, your program requirements may use different logic descriptions for the cases, but I think you should be aware of (and specify) actions for each possibility, even if the action is a "no op."

Give it a shot!

Regards,

Dave

Dave, you like to be unfair, don't you?

(1) I just showed another of possible solutions. I thought it might help to improve people's level of software awareness a little bit :wink:

(2)It always helps in programming to do things systematically :slight_smile: In that respect my example is simple and easy to understand!

(3) I did not say that there were 27 different situations - how could I?? There are 27 possible bit setting; however - I agree! - not all of them can occur for mathematical reasons.

This will become obvious when you think about what you want to do in which case: a<b and b<c and a==c? -> impossible.

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:

  1. Write down the problem.

  2. Think real hard.

  3. Write down the solution.

hi,
i solved the problem myself :slight_smile:
just used the if else and instead of using switches or some thing i just decided to stick to the cases i wanted and wrote the programme in that manner " the code i posted was working" :-[
thanks every one :wink:
and thanks davekw7x
that first peice of info u gave me that was all i needed i just played around it with and using that i finally desigened the code i wanted :sunglasses:

@newbie

solved the problem myself

Congratulations!

@davekw7x

different people have different ways of trying to help

davekw7x's way of trying to help:

1. Try to give a little nudge in what Dave considers to be the "right direction." If the questioner seems totally lost, maybe give more than a nudge. (Or not.) If the Original Poster asks ridiculous questions with no information, castigate him/her in a mocking manner. (Just kidding...but see Footnote.)

2. Fiddle-fart around a while. Tell people things they don't want to hear. May be directly related to original question or may be an amplification or rebuttal concerning other helpers' posts. Or may be generic advice like "Specify the program before starting the design," or, "Design the program before starting to code." Stuff like that.

3. Wait for the Original Poster to fix it. Then offer congratulations.

Regards,

Dave

Footnote:
I may not agree with everything you say,
but I will fight, to the death, for my right to mock you.
---davekw7x

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.

As the programs posted here are extremely short and simple, the need for a systematic approach can rarely be seen. However when it comes to maintenance and debugging, any kind of tables are helpful. In fact when you see logical combinations of AND and OR the first thing to do - if debugging e.g. - is draw the underlying decision table. It would be helpful and less error prone to have this table already in the code - as code.

The next step can be optimization: Reducing the cases. This is the same as hardware designers optimized their layout in old times (and they still learn it in the first classes even today, although things are nowadays handled most efficiently by the HDLV compilers....)

What I want to say: Even in memory limited devices as the 328 (or mega8) understandibility of the code should not be underestimated. I clearly see that most posters here are happy when their code works at all, but for the improvement of your software skills two things have proved of overwhelming importance:

  • Try out variations!
  • Read (and understand) other peple's code!