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)