Ha. I had a convo with a programmer in the 90s. He was explaining a complex problem and the steps to solve in the code, to adjust things based on user choices and parameters.
And I said why wouldn’t you presolve all of them and then provide a lookup to go get the solution from a list. And he just looked stunned and walked away.
Ah my prior manager suggested something similar… Dynamic views that would adjust based on user set parameters… We set up canned views and called it a day.
He was let go, but always pushed for the art of the possible (even if it would take a few extra sprints to wrap)
Reminds me of the first time I saw Sin and Cos lookup tables being used in early 3D gaming. The computers could calculate those just fine, especially with a math co-processor. But for 3D gaming it would be too slow to get a good framerate. So lookup tables were used to greatly improve the speed.
Back on those days all sort of neat tricks like that would be used. Often done as little demo programs that were very impressive. Before the internet it was hard to look up something like that and the latest and greatest tricks weren’t written in books yet. So often little code snippets and demo programs would be shared amongst programmers using the sneakernet, so we could all learn and get better.
Trigonometry functions are still just a hardware lookup table in most scenarios I believe. One example I’ve noticed is that you’ll get slightly different sin/cos results on AMD vs Nvidia GPUs due to either different lookup table values, or different interpolation functions being applied on top (I’m not sure it’s possible to know for sure exactly which without internal knowledge)
It’s possible that the dynamic generation might be more maintainable than a lookup list, though.
With a lookup list, you may need to recalculate the whole thing every time you make a small change. And a significant change, like giving the user a new choice/parameter to adjust, may not only require recalculating the lookup table, but also exponentially increasing the size of the lookup table.
Whereas with a dynamically generated result, small adjustments to the values likely wouldn’t require any modification of the actual code at all, and adding a new choice/parameter would be fairly straightforward – it just needs to be plugged into the formula, maybe add an extra step or two in the algorithm.
It was finite, and early 90s. Calculation time is something you wanted to avoid. To put it to an analogy: you could calculate if a 3d X can be manipulated through a hole, or you can just prr evaluate and say Yes or no based on size, rather than running permutations on 6 axis of movement
Ha. I had a convo with a programmer in the 90s. He was explaining a complex problem and the steps to solve in the code, to adjust things based on user choices and parameters.
And I said why wouldn’t you presolve all of them and then provide a lookup to go get the solution from a list. And he just looked stunned and walked away.
Ah my prior manager suggested something similar… Dynamic views that would adjust based on user set parameters… We set up canned views and called it a day.
He was let go, but always pushed for the art of the possible (even if it would take a few extra sprints to wrap)
Reminds me of the first time I saw Sin and Cos lookup tables being used in early 3D gaming. The computers could calculate those just fine, especially with a math co-processor. But for 3D gaming it would be too slow to get a good framerate. So lookup tables were used to greatly improve the speed.
Back on those days all sort of neat tricks like that would be used. Often done as little demo programs that were very impressive. Before the internet it was hard to look up something like that and the latest and greatest tricks weren’t written in books yet. So often little code snippets and demo programs would be shared amongst programmers using the sneakernet, so we could all learn and get better.
Trigonometry functions are still just a hardware lookup table in most scenarios I believe. One example I’ve noticed is that you’ll get slightly different sin/cos results on AMD vs Nvidia GPUs due to either different lookup table values, or different interpolation functions being applied on top (I’m not sure it’s possible to know for sure exactly which without internal knowledge)
On 8 bit CPUs we just “refactor” the circle to have 256 degrees so you can easily use 8 bit math.
It’s possible that the dynamic generation might be more maintainable than a lookup list, though.
With a lookup list, you may need to recalculate the whole thing every time you make a small change. And a significant change, like giving the user a new choice/parameter to adjust, may not only require recalculating the lookup table, but also exponentially increasing the size of the lookup table.
Whereas with a dynamically generated result, small adjustments to the values likely wouldn’t require any modification of the actual code at all, and adding a new choice/parameter would be fairly straightforward – it just needs to be plugged into the formula, maybe add an extra step or two in the algorithm.
It was finite, and early 90s. Calculation time is something you wanted to avoid. To put it to an analogy: you could calculate if a 3d X can be manipulated through a hole, or you can just prr evaluate and say Yes or no based on size, rather than running permutations on 6 axis of movement