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.
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)
For cpu sine is in code. X87 has a FSIN, but nobody uses it. Afaik it’s just worse. Idk about gpus or if there’s a standard like there is for floats in general (ieee754).
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
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)
Because he hadn’t thought of what I suggested and it was much easier than what he was trying to program. I wasn’t suggesting he write the program, solve it and table it; it was more like empirical knowledge/common sense stuff to narrow options, then fill the rest in based on what made sense.
Then its just a horizontal or vertical intersection to find the outputs required instead of a complex calculation every time
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.
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.
Humans can invent lies. Machines can repeat lies faster.
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)
For cpu sine is in code. X87 has a FSIN, but nobody uses it. Afaik it’s just worse. Idk about gpus or if there’s a standard like there is for floats in general (ieee754).
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
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)
why is this upvoted
Because there are plenty of scenarios where this would work.
Because he hadn’t thought of what I suggested and it was much easier than what he was trying to program. I wasn’t suggesting he write the program, solve it and table it; it was more like empirical knowledge/common sense stuff to narrow options, then fill the rest in based on what made sense. Then its just a horizontal or vertical intersection to find the outputs required instead of a complex calculation every time