Clean up lookup table code

Forum 2005-2010 (read only) Software Syntax & Programs
1

Hi all,

This code feels really messy to me - any suggestions?

int sensorPin = 0;    // select the input pin for the potentiometer
float sensorValue = 0;  // variable to store the value coming from the sensor

long lookupR[] = {
  45313, 26114, 15462, 9397, 5896, 3792, 2500, 1707, 1175, 834, 596, 436, 323, 243, 187, 144, 113, 89};
long lookupT[] = {
  -40, -30, -20, -10, 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130};

float findV(float analogIn) {
  return analogIn / 1024 * 5.0;
}

long findR(float analogIn) {
  float voltage = findV(analogIn);
  return 5000 / voltage - 1000;
}

long lookup(long R) {
  int x = 0;
  for (int i=0; i <= 17; i++){
  if (R < lookupR[i]) {
    x = i;
  }
  }
  return x;
}


void setup() {
  Serial.begin(9600);
}

void loop() {
  delay(1000);
  sensorValue = analogRead(sensorPin);
  Serial.println(sensorValue);
  Serial.println(findR(sensorValue));
  Serial.println(map(findR(sensorValue),lookupR[lookup(findR(sensorValue))],lookupR[lookup(findR(sensorValue))+1],lookupT[lookup(findR(sensorValue))],lookupT[lookup(findR(sensorValue))+1]));
}
2

This:

long lookupT[] = {
  -40, -30, -20, -10, 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130};

Could be:

int lookupT(byte index) {
  return ( -40 + (index*10) );
}

Then you would free up some RAM.

[edit]Note that I do not think you code was too 'dirty'. It was easy to understand the purpose of it all.
But this:

Serial.println(map(findR(sensorValue),lookupR[lookup(findR(sensorValue))],lookupR[lookup(findR(sensorValue))+1],lookupT[lookup(findR(sensorValue))],lookupT[lookup(findR(sensorValue))+1]));

Might look cleaner as:

long r0 = lookup( findR(sensorValue) );
long r1 = lookup( findR(sensorValue) + 1 );

Serial.println( map( findR(sensorValue), lookupR[r0], lookupR[r1], lookupT[r0], lookupT[r1] ) );

:slight_smile:
[/edit]

3

Thanks for that - very useful :slight_smile:

I think I'm going to stick it in to one function to make it cleaner all together.

4

Pat - thanks for the link, I read the entirety of it, man the OP got flogged there. I am not saying he didn't deserve a lot of it

blindman - by no means did I think this was a unique idea, I have seen it at old jobs and at my current job, to undo it would be quite the undertaking. Not so much the creating of 87 distinct lookup tables so much in having to refactor all of the procs, ASP and .Net code that currently utilize this table. I also read your post regarding there not being any true lookup tables anymore and I totally agree in a well designed database. One thing my company is shifting towards is removing a lot of business logic from the DB so these additional attributes (like "in progress" that you mention) will be encapsulated in the business component code. I am not so sure I agree with that line of thinking, but I am outnumbered at this point.

Without opening up a whole new can of worms, I do have one question:

Couldn't a poor man's RI be accomplished by creating a UDF to check against the range of values for the given "type" and then include a call to the UDF in a check constraint? I don't believe this would work if that column allowed nulls but otherwise it seems pretty solid in maintaining RI.

One more quick thing to add, at the current firm I am at for every new project we work on there are probably about 5-10 requests for new lookup tables so part of the allure of using the OTLT is consolidating this static data in 1 table since this will likely get replicated to two other DB's (as compared to creating/maintaining 15-30 new tables per project (5-10 times 3)).