Smalltalk › Instantiations

Lookup table, one or two?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Louis LaBrunda

Lookup table, one or two?

Hi All,

As a side project to our LibUSB project I'm working on some classes that will talk to an X10 CM19a USB transceiver. You send commands to the CM19a and it passes them on to X10 devices and they turn on/off. I have a lookup table of command objects keyed by a string like 'A-1-On'. The command objects contain the same string and the hex codes (a ByteArray) to send to the CM19a. So, given a command string, I can find the codes to send.

The CM19a can also tell that some other device (like a hand held remote) has sent the codes and I can read these codes. I would like to look up the codes to know which command was sent. I'm thinking of having a second lookup table keyed by the codes with the same command objects as values.

My question is, is it better (for what ever reason) to have two lookup tables or just one as the keys (strings and byte arrays) won't clash and it can all be in one table.

One table seems slightly easier but two seems cleaner. So, what does everybody think?

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

Richard Sargent

Re: Lookup table, one or two?

Administrator

On Wednesday, April 13, 2016 at 2:12:09 PM UTC-7, Louis LaBrunda wrote:

Hi All,

As a side project to our LibUSB project I'm working on some classes that will talk to an X10 CM19a USB transceiver. You send commands to the CM19a and it passes them on to X10 devices and they turn on/off. I have a lookup table of command objects keyed by a string like 'A-1-On'. The command objects contain the same string and the hex codes (a ByteArray) to send to the CM19a. So, given a command string, I can find the codes to send.

The CM19a can also tell that some other device (like a hand held remote) has sent the codes and I can read these codes. I would like to look up the codes to know which command was sent. I'm thinking of having a second lookup table keyed by the codes with the same command objects as values.

My question is, is it better (for what ever reason) to have two lookup tables or just one as the keys (strings and byte arrays) won't clash and it can all be in one table.

One table seems slightly easier but two seems cleaner. So, what does everybody think?

I think the overhead to have a second table is insignificant. Unless there is a compelling argument to mix the two, go for clarity. That's always the rule for optimizations.

Lou

John O'Keefe-3

Re: Lookup table, one or two?

On Wednesday, April 13, 2016 at 8:12:32 PM UTC-4, Richard Sargent wrote:

On Wednesday, April 13, 2016 at 2:12:09 PM UTC-7, Louis LaBrunda wrote:
Hi All,

As a side project to our LibUSB project I'm working on some classes that will talk to an X10 CM19a USB transceiver. You send commands to the CM19a and it passes them on to X10 devices and they turn on/off. I have a lookup table of command objects keyed by a string like 'A-1-On'. The command objects contain the same string and the hex codes (a ByteArray) to send to the CM19a. So, given a command string, I can find the codes to send.

The CM19a can also tell that some other device (like a hand held remote) has sent the codes and I can read these codes. I would like to look up the codes to know which command was sent. I'm thinking of having a second lookup table keyed by the codes with the same command objects as values.

My question is, is it better (for what ever reason) to have two lookup tables or just one as the keys (strings and byte arrays) won't clash and it can all be in one table.

One table seems slightly easier but two seems cleaner. So, what does everybody think?

I think the overhead to have a second table is insignificant. Unless there is a compelling argument to mix the two, go for clarity. That's always the rule for optimizations.

If you are thinking of making one LookupTable with both commands and codes as keys, then I agree with Richard. However, having one LookupTable and using #at: and #keyAtValue: means you won't have to deal with out-of-sync tables. The reverse lookup (#keyAtValue:) will be slower, but I'm going to guess the LookupTable will have a relatively small number of entries and this little inefficiency will be lost in a dusty corner of your app.

Lou

Richard Sargent

Re: Lookup table, one or two?

Administrator

On Thursday, April 14, 2016 at 12:41:32 PM UTC-7, John O'Keefe wrote:

On Wednesday, April 13, 2016 at 8:12:32 PM UTC-4, Richard Sargent wrote:
On Wednesday, April 13, 2016 at 2:12:09 PM UTC-7, Louis LaBrunda wrote:
Hi All,

As a side project to our LibUSB project I'm working on some classes that will talk to an X10 CM19a USB transceiver. You send commands to the CM19a and it passes them on to X10 devices and they turn on/off. I have a lookup table of command objects keyed by a string like 'A-1-On'. The command objects contain the same string and the hex codes (a ByteArray) to send to the CM19a. So, given a command string, I can find the codes to send.

The CM19a can also tell that some other device (like a hand held remote) has sent the codes and I can read these codes. I would like to look up the codes to know which command was sent. I'm thinking of having a second lookup table keyed by the codes with the same command objects as values.

My question is, is it better (for what ever reason) to have two lookup tables or just one as the keys (strings and byte arrays) won't clash and it can all be in one table.

One table seems slightly easier but two seems cleaner. So, what does everybody think?

I think the overhead to have a second table is insignificant. Unless there is a compelling argument to mix the two, go for clarity. That's always the rule for optimizations.

If you are thinking of making one LookupTable with both commands and codes as keys, then I agree with Richard. However, having one LookupTable and using #at: and #keyAtValue: means you won't have to deal with out-of-sync tables. The reverse lookup (#keyAtValue:) will be slower, but I'm going to guess the LookupTable will have a relatively small number of entries and this little inefficiency will be lost in a dusty corner of your app.

I don't think that will work. The values are the command objects. The two different access keys are the command "name" (a String) and the command "instructions" (a ByteArray).

Lou

John O'Keefe-3

Re: Lookup table, one or two?

OK, I read the problem description a little too fast. Two tables is the right answer.

On Thursday, April 14, 2016 at 4:24:28 PM UTC-4, Richard Sargent wrote:

On Thursday, April 14, 2016 at 12:41:32 PM UTC-7, John O'Keefe wrote:

On Wednesday, April 13, 2016 at 8:12:32 PM UTC-4, Richard Sargent wrote:
On Wednesday, April 13, 2016 at 2:12:09 PM UTC-7, Louis LaBrunda wrote:
Hi All,

As a side project to our LibUSB project I'm working on some classes that will talk to an X10 CM19a USB transceiver. You send commands to the CM19a and it passes them on to X10 devices and they turn on/off. I have a lookup table of command objects keyed by a string like 'A-1-On'. The command objects contain the same string and the hex codes (a ByteArray) to send to the CM19a. So, given a command string, I can find the codes to send.

The CM19a can also tell that some other device (like a hand held remote) has sent the codes and I can read these codes. I would like to look up the codes to know which command was sent. I'm thinking of having a second lookup table keyed by the codes with the same command objects as values.

My question is, is it better (for what ever reason) to have two lookup tables or just one as the keys (strings and byte arrays) won't clash and it can all be in one table.

One table seems slightly easier but two seems cleaner. So, what does everybody think?

I think the overhead to have a second table is insignificant. Unless there is a compelling argument to mix the two, go for clarity. That's always the rule for optimizations.

If you are thinking of making one LookupTable with both commands and codes as keys, then I agree with Richard. However, having one LookupTable and using #at: and #keyAtValue: means you won't have to deal with out-of-sync tables. The reverse lookup (#keyAtValue:) will be slower, but I'm going to guess the LookupTable will have a relatively small number of entries and this little inefficiency will be lost in a dusty corner of your app.

I don't think that will work. The values are the command objects. The two different access keys are the command "name" (a String) and the command "instructions" (a ByteArray).

Lou

Louis LaBrunda

Re: Lookup table, one or two?

Hi Guys,

Thanks for the replies. I went with two tables for the obvious reason that it is cleaner. I was just feeling a little lazy the other day. One table does make things "seem" simpler because you are always accessing just the one table but then it isn't obvious what's going on.

Lou

On Thursday, April 14, 2016 at 4:52:46 PM UTC-4, John O'Keefe wrote:

OK, I read the problem description a little too fast. Two tables is the right answer.

On Thursday, April 14, 2016 at 4:24:28 PM UTC-4, Richard Sargent wrote:
On Thursday, April 14, 2016 at 12:41:32 PM UTC-7, John O'Keefe wrote:

On Wednesday, April 13, 2016 at 8:12:32 PM UTC-4, Richard Sargent wrote:
On Wednesday, April 13, 2016 at 2:12:09 PM UTC-7, Louis LaBrunda wrote:
Hi All,

As a side project to our LibUSB project I'm working on some classes that will talk to an X10 CM19a USB transceiver. You send commands to the CM19a and it passes them on to X10 devices and they turn on/off. I have a lookup table of command objects keyed by a string like 'A-1-On'. The command objects contain the same string and the hex codes (a ByteArray) to send to the CM19a. So, given a command string, I can find the codes to send.

The CM19a can also tell that some other device (like a hand held remote) has sent the codes and I can read these codes. I would like to look up the codes to know which command was sent. I'm thinking of having a second lookup table keyed by the codes with the same command objects as values.

My question is, is it better (for what ever reason) to have two lookup tables or just one as the keys (strings and byte arrays) won't clash and it can all be in one table.

One table seems slightly easier but two seems cleaner. So, what does everybody think?

I think the overhead to have a second table is insignificant. Unless there is a compelling argument to mix the two, go for clarity. That's always the rule for optimizations.

If you are thinking of making one LookupTable with both commands and codes as keys, then I agree with Richard. However, having one LookupTable and using #at: and #keyAtValue: means you won't have to deal with out-of-sync tables. The reverse lookup (#keyAtValue:) will be slower, but I'm going to guess the LookupTable will have a relatively small number of entries and this little inefficiency will be lost in a dusty corner of your app.

I don't think that will work. The values are the command objects. The two different access keys are the command "name" (a String) and the command "instructions" (a ByteArray).

Lou