Talk:Lookup table

message: From the article: In image processing, lookup tables are often called LUTs, and they link index numbers to output values. One common LUT, called the colormap, is used to determine the colors and intensity values with which a particular image will be displayed.
Does the image processing LUT definition have anything to do with traditional lookup tables in computer science? --Abdull 23:07, 3 October 2005 (UTC)
thread_title:  Image processing? 

message: I removed this:
:The other restriction, may be more important, is the time, required for the preliminary evaluation of the function`s values. For example: if the argument has 64 bits then one should preliminary evaluate 264 = 1,8 * 1019 values of the function. If one value evaluation requires, for example, 1 mcsec (10 − 6sec), then the evaluation of the 1,8 * 1019 values requires appr. 580 000 years!!
The reason is quite simple: any lookup table that takes an extremely long time to compute also takes up an extremely large amount of space. Space is the fundamental limitation. Say you have a 10 terabyte drive filled with a lookup table and each element takes a microsecond to compute. Then the total time is only 16 weeks, which isn't that bad.
That's not to say there aren't applications where the precomputation time is prohibitive, either because the time per element is large or because the table is very large and disk-based. I removed the example and de-emphasized this part. Deco 22:04, 13 February 2006 (UTC)
replies: text: No, it's not. That's exactly what I explained above. Unless each table element is extremely expensive to compute, or there is little time available for precomputation, space will almost always be the limiting factor. Deco 08:45, 15 February 2006 (UTC)

text: It is true that, given infinite memory in which to store the table, time may become a limiting factor, but this is a purely hypothetical situation. I get your point though - just not sure whether or not it actually belongs in the article or not. Deco 22:42, 15 February 2006 (UTC)
thread_title:  Table computation time 

message: I think that should be noted that the LUT operation can be reversed via hashing, e.g.:
Given:
f(x) = (r,g,b)
Where f(x) is a LUT, and the 'x' argument is a color index, and the result is a RGB555/RGB888 color vector.
Then, a f^-1(r,g,b) = x can be built using a hash table, depending on the color accuracy you need:
RLUT hash table = 2^(bits_of(R)+bits_of(G)+bits_of(B))
And the formula for f^-1(r,g,b), that retrieves the index could be written as (example):
x = HashTable[R<<(bits_of(G)+bits_of(B)) | G<<bits_of(B) | B]
Do you think that would be interesting to add an RLUT article and a reference from this one? --faragon 10:46, 8 May 2007 (UTC)
thread_title:  Reverse Lookup table? 

message: The plot of the sampled sine curve is unnecessarily large, and overlaps the text in the paragraphs below (at least on my system, which has a resolution of 1024 x 768, and has the browser maximised). I'd fix this if I knew how to. — Paul G 09:31, 12 October 2007 (UTC)
thread_title:  Sine plot too large 

message: I think the article has been writen by someone with quite limited knowldge of lookup tables.
I believe the examples given are unrepresentative of most real-world lookup tables that are frequently simply associative arrays, either unsorted or sorted. 
The article should cover these simple cases first and then cover trivial hash function lookups on one-dimensional tables (these being very beneficial in many situations - and very much under-utilized by programmers) and then go on to cover binary search of sorted tables, then last, but not least, hash functions.
It should also touch on memoization techniques and give examples for several ways that lookup tables can save both significant code repetition, and aid clarity.
As the article stands, a casual or inexperienced user might be put off by the view expressed that "modern processors are better off without lookup tables because tables don't fit in cache". Many lookup tables can actually be shorter than the code required to calculate values afresh, especially if the range is short and the table can be statically defined close to its use to improve locality of reference.ken (talk) 11:14, 14 December 2009 (UTC)
replies: text: Done (1st draft)ken (talk) 12:33, 14 December 2009 (UTC)
thread_title:  Suggest complete re-write of the article 

message: Hello fellow Wikipedians,
I have just added archive links to  on Lookup table. Please take a moment to review my edit. If necessary, add  after the link to keep me from modifying it. Alternatively, you can add  to keep me off the page altogether. I made the following changes:
*Added archive http://web.archive.org/web/20150912031501/http://webster.cs.ucr.edu/AoA/Windows/HTML/TableLookups.html to http://webster.cs.ucr.edu/AoA/Windows/HTML/TableLookups.html
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—cyberbot IITalk to my owner:Online 07:45, 28 February 2016 (UTC)
thread_title:  External links modified 

message: "symmetry rules. In this case, the lookup table is calculated by using the sine function for the first quadrant (i.e. sin(0..pi/2)). When we need a value, we assign a variable to be the angle wrapped to the first quadrant. We then wrap the angle to the four quadrants (not needed if values are always between 0 and 2*pi) and return the correct value (i.e. first quadrant is a straight return, second quadrant is read from pi/2-x, third and fourth are negatives of the first and second respectively). For cosine, we only have to return the angle shifted by pi/2"
Using the cumulative sum or differences between values is enough to reconstruct all values from just 1/8-th. Due to the differential or integral relation between sine and cosine one might just store 0 to pi/4 and generate the rest from those values. Example:
10*(\sin(15/32\cdot\pi)-\sin(13/32\cdot\pi))/2 \approx \sin(2/32\cdot\pi)
--Moritzgedig (talk) 19:34, 3 April 2021 (UTC)
thread_title:  Sine: 1/8 th of a period is enough 

message: Please can someone adjust the start (at least) of the introduction to explain the topic in non-technical terms? Onanoff (talk) 08:48, 27 July 2022 (UTC)
thread_title:  Layman intro please