I just tried using the openjdk-6-jre instead of the 7 one and the ide wouldn't even fire up.

any other ideas?

Thank you AWOL, that is what I was guessing,

Then this is definitely what im trying to do (but what I though what I posted was doing)

Code:

var1=var1-var2+var3

That short hand would have introduced a fun bug to chase if I wasn't paying attention

I thought this would be an easy look up but the search terms are kinda ambiguous

What are the order of operations in this expression?

Code:

var1-=var2+var3

I know.. simple, thank you in advance

I store them as bytes..

In the tuts the explaining data types is cumbersome right off the bat, so they just use ints.
That way noobs don't get confused by overflow errors when they start repeating the process.

There might be a better reason though.

The suggestion the encoding blows is something I agree with. However it does add a degree of complexity having the chords be represented by 32 bits vs 16 because these values are actively be drawn from and assigned in eeprom. I guess I'm just not sure how chop a long into bytes and reassemble them again.

I did show a preset layout in progmem here, but that is just to get by and doing testing on things other then the currently buggy learning algorithm. Like for instance this noise filter. In the ultimate designed working state of the device the layout is somewhat fluid, 'learning the user' initially and reassigning itself given common error making eeprom essential. 

I will do some research on bit mask and bit fields though, thank you for the reference, Peter. 

I got things working  
sorry if abbreviating the variables bothers anyone. I always figure if its a problem I can just use the find & replace to fix.

Code:

#include<avr/pgmspace.h>

prog_uint16_t preDefLayout[28] PROGMEM=
//A to Z then yes then no.
{
  1100,23000,2300,21000,1000,30000,3100,20001,32000,1500,3002,3000,6600,53000,
  60000,11000,15000,6000,3200,10,600,45000,20003,33000,62000,1001,1,10000
};

unsigned int noise[5]= {3,6006,606,101,1010};
unsigned int chord;


void setup()
{
  Serial.begin(9600);
  for (int i=0;i<5;i++)
  {
    chord=filter(noise[i]);
    Serial.println(chord);
  }
}

void loop()
{
}

unsigned int filter(unsigned int noise)
{
  unsigned int correctToValue=9;
  //cant be nine so if it prints this something is wrong
  int lowPoint=15;
  for(int i=0;i<28;i++)
  {
    unsigned int largerNum;
    unsigned int compare = pgm_read_word_near(preDefLayout +i);
    unsigned int sComp=compare; //temporary second comparison
    unsigned int fComp=noise; //temp first comparison
    int pointCompare=0;
    if(fComp>sComp)
    {
      largerNum=fComp;
    }
    else
    {
      largerNum=sComp;
    };
    unsigned long mag= 1;
    while (mag*10<=largerNum)
    {
      mag*=10;
    }
    while(mag>0)
    {
      if(fComp>sComp)
        //overflow prevention
      {
        pointCompare+= fComp/mag - sComp/mag;
        Serial.print(fComp/mag - sComp/mag);
      }
      else
      {
        pointCompare+= sComp/mag-fComp/mag;
        Serial.print(sComp/mag-fComp/mag);
      }
      fComp%=mag;
      sComp%=mag;
      mag/=10;
      Serial.print(" ");
    }
    Serial.print(" total-");
    Serial.println(pointCompare);
    if(pointCompare<lowPoint)
      //filters to the path of least resistence
    {
      lowPoint=pointCompare;
      //set a new lowpoint
      correctToValue=compare;
      //remember the lowpoint value
    }
  }
  return correctToValue;
}

Thanks guys!

I have a couple thoughts about less iteration but I wonder If there are any inefficiencies that are obvious in what I wrote?

here is the main body of code w/ out what I'm testing add for those that are curious

https://github.com/PaulBeaudet/JesterType/blob/master/JesterType.ino

Hmmm, a bit rusty on basic math?

Yes, I am!  but, I think spatula's intention was for me to think this out my self so I would get it

Basically 6106 or 5106 or 4106%= 1000 would be 106 thus the left most digit is being removed , and now I get it.
Thank you for bearing with me on that one, now I'll try to make a test program a report back.

So what is the overall thing that you're trying to achieve?

I'm correcting for noisy input, each of the 5 digits represents a independent button values combined into one unsigned int earlier in the program. 1 for a press, 3 for a hold and so on. In that way 300 would represent a hold on the 3rd button and 10000 would represent a press of the first. To correct for noise I need to calculate the level of difference by input.

Implicitly I can tell that if 300 hasn't been assigned to a letter my user probably doesn't wan't the letter assigned to 10000 but If there is a letter assigned to 600 which is just a longer hold of button 3 maybe they are trying to go for the letter assigned to 600. Its just more likely that is what they were trying to do, considering the input they used had not been assigned.

Applying an explicit probability algorithm that acts in a similar manner is the next step, but first I have to get those digits alone to compare the individual place cases. The way I figure it I can build up differance counter(s) and pick the assignment the generates the least difference.   

There is likely a way to do this before the int is compiled, but it would conflict with another part of my program.
I'll post the link to the main body once I push the current commit, so that you folks have a better idea of the purpose of the project.

thanks for for the explanation marco, I got that far, I was just not sure about
value=1106
value%=10
its this compound operator im not sure of, what is value equal to now?

I just tried a method comparing the ints a strings using itoa()...
that didn't go well  ... not even worth posting
itoa() seems to overflow when given an unsigned int with an unsigned'esk' value
and when blank spots in the buffer are compared they are random.

it seems to me like a very strange algorithm and I can't imagine any problem that this approach is a sensible solution to

Peter,
honestly it looked like gibberish to me too, I just trusted the person knew what they were doing, but I guess with my copy and paste methodology its a prime way to give a foolish example.

I found another example here http://www.cplusplus.com/forum/beginner/1326/ I'm just not sure how I can translate it to my problem.

spatula,
I'm still working out your solution in my head (l'm a bit of a dunce with math)  having a hard time visualizing how the modulus operation cuts off the leftmost digit.

I'm trying to efficiently isolate a digit. For example If have two values x=1106 and y = 1000, I'm looking the compare the differences in a granular way by place value like so

tens place x is what to y tens place
what == equal
ones place x is what to y ones place
what == grater by 6

This post will become ridiculous fast if I explain the why portion of the problem.
Needless to say the part I'm having a hard time with is isolating the digits to make the comparisons.
Paying more attention in high school math probably would have helped me here...
anyhow, here is what I looked at as a possible example http://www.daniweb.com/software-development/cpp/threads/151273/integer-place-values
and here is where i'm at with test code.

Code:

#include<avr/pgmspace.h>

prog_uint16_t preDefLayout[28] PROGMEM=
//just a bunch of unsigned ints
{
  1100,23000,2300,21000,1000,30000,3100,20001,32000,1500,3002,3000,6600,53000,
  60000,11000,15000,6000,3200,10,600,45000,20003,33000,62000,1001,1,10000
};

void setup()
{
  Serial.begin(9600);
  for(int i=0;i<28;i++)
  {
    unsigned int num = pgm_read_word_near(preDefLayout +i);
    for (int d=0; d<5; d++)
    {
      unsigned int num= compare%(10^d);
      unsigned int digit = a/(10^(d-1));
      Serial.print(" ");
      Serial.print(digit);
    }
    Serial.println();
  }
}

void loop()
{
}

just in case you haven't been here yet

http://arduino.cc/en/Reference/For

Before details my question is, Is there are a way to install or configure the IDE in mint linux 14 so that it will properly upload to a "usb lillypad" and get rid of the menu bugs?

Bugs that I am noticing- Bug0 After using the IDE for a period of time the menus will start to offset. i.e. a menu is selected and the drop-down occurs in on the wrong area of the screen. Bug1 any selected menu item will be whited out. Most importantly, Bug2 - the ide seems to reset the usb lillypad partway through an upload causing all uploads to fail.

more on Bug2- I did try with another disto and the ide worked fine. I don't really want to explore other distros just for the sake of the ide, so that is why I'm am interested in other ways to configure. Is it possible the version of java on mint doesn't play well with the ide?
Also- Arduino micro and uno take uploads fine, its just the lillypad that is having the issue

I'm bumping this because I'm interested too. You gave good info, but I think you need to simplify a bit for other folks to make suggestions. I doubt there are many doing exactly what your doing so there is quite a bit of guess work in helping here. 

I'm also using mint 14 and I'm curious about something that may or may not be related.
Bugs-- off-set menus and selected menu items (board, port) completely whited out. Is this happening to you?

I just uploaded the sketch from another linux machine I have... and everything worked...

Eliminating the defectiveness possibly in the lilypad and turning the focus on my main machine... Which I would like to use because I'm giving the other computer away today... ironically because I didn't have a use for it...key word being didn't

maybe a rare 64 bit bug?  This is one of the only differences between this and the other machine, I'm going to see if the jre needs to be updated next