(Feb-24-2021, 09:52 AM)Serafim Wrote: I have made an implementation that needs some explanation.
- I convert the input to a string as I want to simply move the decimal point out of the way. Stepwise floating point multiplication gives raise to round-off errors that severely affects the result.
- Two methods are not shown as they are tedious in their details but simple to implement.
- "prepare" takes two parameters, "n" is the number to be "square rooted" an "d" is the number of desired decimals. The return value is a list with double figure integers (shortened if there is an intial zero) and the calculated number of decimals. E.g. prepare(123.456, 10) returns a=[1,23,45,60,0,0,0,0,0,0,0,0], d=10, while prepare(1.234, 0) returns a=[1,23,40] and d=2
- "normalize" takes a string representation of a result and removes initial and trailing zeroes as well as the decimal point if there are no decimals
- The implementation has a flaw due to the nature of the long division method that I didn't bother to correct. There might be a round-off error in the last digit of a result with decimals so all such results ought to be rounded with omission of the last digit. The long division method is devised for integer arithmetics and is accurate when dealing with integers but as the method collects one digit at the time there is no telling if the first omitted digit in a potentially infinite number of decimals would be less than 5 or not.
1. Though simple, request the two modules: 'prepare', 'normalize' for the sake of consistency.
2. It seems the parameter 'd' to prepare is user defined. The only way to custom (input based) definition seems to convert input to string, and check for decimal. Say, '.' in string (if correct). Then, based on number of digits after decimal, can decide value of 'd'. Cannot though think of a criteria.
3. The possible flaw referred by you should be due to limited number of decimal digits? If yes, then the accuracy is affected. If so, then rounding is to be done by a seperate module?