If a calculator is designed according to what you have proposed then it would have to check through a wide list and then decide to calculate or not, which will make calculator noticeably slower.
So, You are proposing the calculator to do a long check and decide if it should do it.
eg. Sin and Cos are more 'expensive' trigonometric functions many games or programs that make heavy use of the two functions but don't need perfect accuracy create a lookup table. and fill it with the results of a full circle of angles; eg 360 values from 0 to 2*PI. Then the function overload simply converts the input angle to a array index and returns the value.
That only works for functions that can only accept a specific range of values (or can be converted into a specific range of values. sqrt doesn't work because you can sqrt anything.
A HashMap lookup is more expensive than the sqrt function Once you start using larger buckets. And you've still got the problem that you have to somehow store the age of the value so that you can throw out old values when you store a new one- so now you've got this more expensive remove operation when a new calculation is made.
You can't just let it accumulate forever. It would be a cache but it wouldn't have a policy for discarding information. a Cache with a bad policy is just another name for a memory leak.
Yes this is a concept that already exists believe it or not! It is called dynamic programming (which is commonly used in algorithms that have overlap in calculations, as you stated). However like putting things in arrays etc., they are are all kept on memory, and will disappear once you close the application.
However, once again, if you mean long term storage of calculations, then you will have to retrieve it--and check it--from a database, which may be much slower then actually doing the calculation (unless it is huge).
Yes this is a concept that already exists believe it or not! It is called dynamic programming (which is commonly used in algorithms that have overlap in calculations, as you stated). However like putting things in arrays etc., they are are all kept on memory, and will disappear once you close the application.
However, once again, if you mean long term storage of calculations, then you will have to retrieve it--and check it--from a database, which may be much slower then actually doing the calculation (unless it is huge).
Nothing they allude to is dynamic programming. The real word for what they are describing is Micro-optimization, I would think. And it's worse than that, because the 'optimization' would often be slower than the operation itself.
That only works for functions that can only accept a specific range of values (or can be converted into a specific range of values. sqrt doesn't work because you can sqrt anything.
Well, if you're trying to square root a floating point number, you could be clever and store a look-up table for values in the range 0-2. Then, to take the square root, you separate the exponent and mantissa. If the exponent is odd, multiply the mantissa by 2. You then compute the new exponent and mantissa by dividing the exponent by 2 and feeding your mantissa through the look-up table.
Of course that's still probably slower than just calling sqrt, but that particular function is actually amenable to a lookup (for floating points, at least).
Also, depending on the nature of the function, it could be possible to remap an infinite domain into a finite one. For example, if the function takes any value in the range [0, infinity), you could instead run that input through 1/(x + 1) and map that onto (0, 1] and built your look-up table there. However, this will really only work well for functions that don't change much as they tend towards infinity.
-
If a calculator is designed according to what you have proposed then it would have to check through a wide list and then decide to calculate or not, which will make calculator noticeably slower.
So, You are proposing the calculator to do a long check and decide if it should do it.
Check out my games pls.
eg. Sin and Cos are more 'expensive' trigonometric functions many games or programs that make heavy use of the two functions but don't need perfect accuracy create a lookup table. and fill it with the results of a full circle of angles; eg 360 values from 0 to 2*PI. Then the function overload simply converts the input angle to a array index and returns the value.
That only works for functions that can only accept a specific range of values (or can be converted into a specific range of values. sqrt doesn't work because you can sqrt anything.
A HashMap lookup is more expensive than the sqrt function Once you start using larger buckets. And you've still got the problem that you have to somehow store the age of the value so that you can throw out old values when you store a new one- so now you've got this more expensive remove operation when a new calculation is made.
You can't just let it accumulate forever. It would be a cache but it wouldn't have a policy for discarding information. a Cache with a bad policy is just another name for a memory leak.
However, once again, if you mean long term storage of calculations, then you will have to retrieve it--and check it--from a database, which may be much slower then actually doing the calculation (unless it is huge).
Nothing they allude to is dynamic programming. The real word for what they are describing is Micro-optimization, I would think. And it's worse than that, because the 'optimization' would often be slower than the operation itself.
Well, if you're trying to square root a floating point number, you could be clever and store a look-up table for values in the range 0-2. Then, to take the square root, you separate the exponent and mantissa. If the exponent is odd, multiply the mantissa by 2. You then compute the new exponent and mantissa by dividing the exponent by 2 and feeding your mantissa through the look-up table.
Of course that's still probably slower than just calling sqrt, but that particular function is actually amenable to a lookup (for floating points, at least).
Also, depending on the nature of the function, it could be possible to remap an infinite domain into a finite one. For example, if the function takes any value in the range [0, infinity), you could instead run that input through 1/(x + 1) and map that onto (0, 1] and built your look-up table there. However, this will really only work well for functions that don't change much as they tend towards infinity.