Talk:Lookup Table

Improve further

Hi @GHXX and hi all, I made a change to the article to make it simpler and clearer. However, I suspect it needs some improvements. How it can be improved in terms of phrasing and/or additional information ? DjSapsan (talk) 17:36, 7 September 2025 (UTC)

@DjSapsan,

Imo we should add that the AND-inputs may also be negated.

And that a lut can only output a single bit, in the general case, and not a batch of outputs (instead of 'The output may be a single bit or a pattern of bits.')

The "we can avoid delays by not using buffers" paragraph should imo be replaced with one that states that the not-inputs are generally fed through a fastbuffer first, so that no backpropagation happens.

Lmk what you think, please GHXX (talk) 20:31, 7 September 2025 (UTC)

@GHXX, yes to all, except one thing. Why LUTs should output only a single bit? I thought using it to produce a pattern of bits is a common application. DjSapsan (talk) 20:45, 7 September 2025 (UTC)

@DjSapsan, No, usually it only produces one output bit ($Output1$), because all those chains get OR ed together, and unless the other output ($Output2$)) can be computed by $Output2=Output1OR(otherchains)$, there is no way of computing that other output, as far as i am aware.

I suppose you could maybe re-use the intermediate NOT outputs, but that is far from the general case from my experience. GHXX (talk) 20:55, 7 September 2025 (UTC)

@GHXX I'm so sorry, I keep merging this "optimized" LUT with a "full" LUT in mind.

By "full" LUT, I mean essentially a decoder.

We need to sort this out.

The article talks about building a LUT only for true outputs. Thanks for reminding me, that the logic for non-true outputs is absent.

But the "full" LUT has a logic for every single input combination (even if the corresponding output is off).

So... should we make two versions? DjSapsan (talk) 22:02, 7 September 2025 (UTC)

@DjSapsan i think making a separate decoder page, if that name is appropriate ,would make sense; but, wouldnt that in a way be a multiplexer with fixed inputs (possibly using switches) that you are choosing from using address lines?

From my experience a lookup table is always simply used to compute one bit from a set of input bits, encoding an arbitrary logical formula by just listing all inputs that lead to a true output.

I think the architecture of a "full" LUT as you are describing it would be fundamentally different as changing outputs in a normal LUT tends to be really annoying, as you would need to physically add/remove chains and couldnt simply flip a switch. GHXX (talk) 22:09, 7 September 2025 (UTC)

@GHXX Maybe we misunderstand each other a little bit.

The "full" LUT is 100% equivalent to the "1-bit" LUT. It only adds a possibility to output a pattern of bits (as well as the same 1 bit).

In my experience, LUTs are used in programming, for example in Lua:

t = {}
t[1] = "logic"
t[2] = "world"

And in LW, I store characters for multi-segmented displays in LUTs.

Changing it should be simpler, because it doesn't require adding/removing parts, only changing the output bits. DjSapsan (talk) 22:19, 7 September 2025 (UTC)

hmmmmmmmmmmm i see, in a sense the LUT i am /have-been describing is a special case of that then, as 0 outputs are unnecessary, and that then also avoids needing a circuit after the chains that actually selects the output values (i.e relays or something like that), and thus you get away with just ORing the chains.

Do you think it might work out to present a more general LUT further down that extends the circuit? (To my experience this specific case is the most common one, because usually a single bit is enough where speed is this necessary (if you can allow for 2 ticks instead of one you can replace the chains with a set of xors and a nand for example, which is a lot more configurable) GHXX (talk) 22:28, 7 September 2025 (UTC)

I suggest to present a general LUT at first and then show the optimized variant and maybe other variants.

The article needs to be more direct at showing possible applications, including fast computation of the formula, storing data (effectively ROM) etc.

I can write it tomorrow. DjSapsan (talk) 22:50, 7 September 2025 (UTC)

kk, yeah im curious to see/read what the general approach for constructing a general LUT will look like GHXX (talk) 22:52, 7 September 2025 (UTC)