It really depends on what you're building. In an embedded shop, lookup tables are first class solutions to most problems. Computer scientists though, 100%!

[–] mushroommunk@lemmy.today 40 points 1 day ago (1 children)

Depends on the available memory and size of the tables. I've worked on cases where time to compute didn't matter as much as shaving off three more bytes did. Large lookup tables would have absolutely killed us compared to running some math.

[–] henfredemars@infosec.pub 15 points 1 day ago (1 children)

Good point! Good point.

I've seen bubble sort implemented because we had data that said it was faster and was slightly smaller for the exact type data we were sorting and its expected distribution.

[–] disorderly@lemmy.world 21 points 1 day ago

I fondly remember the time I hired a QT expert onto an embedded app team and on his first project he imported a sort algorithm from std. He found the system got weird and glitchy, and often crashed.

Yeahhh turns out the algorithm he chose needed to make a copy in memory and the thread he was working in only had 2048 bytes of stack, so larger inputs would corrupt the stack allocated to the next thread. I had to explain to him that we had a full second to complete the math before we had to give back our semaphore, so saving a couple milliseconds on the sort was not a priority. Fun times.

[–] rtxn@lemmy.world 16 points 1 day ago* (last edited 1 day ago)

IIRC, Elite used lookup tables for trigonometric functions on certain target platforms (maybe the NES) because memory wasn't as much of a constraint as computing performance. It's a barrel of game compressed into a pint of code.