Re: Strange problem
- Posted by Everett Williams <rett at GVTC.COM> Mar 21, 2000
- 441 views
On Tue, 21 Mar 2000 16:04:46 GMT, Lewis Townsend <keroltarr at HOTMAIL.COM> wrote: >Rett, you wrote: > >>That is why most systems choose to truncate rather than round. >>Truncation produces a printout much closer to the truth than >>rounding. Rounding, as in this case, can conceal the fact that >>a calculation will not work because of the actual underlying number. >>I would suggest that the rounding be removed and truncation be >>used in the next release...at all levels. It should be faster, and it >>would solve the other noted problems. Same should apply for >>prints of float32 or float64. They should trunc(to zeros if necessary) >>at the last possible significant digit, even if more digits are requested >>than are significant. > >Now I agree that truncation might be better than floor()ing in >some cases but I don't see how it is ever better than rounding >except in the speed department. In this case, truncation prints what is actually there. Rounding prints a piece of meta-data that is fine as a final output, but useless as information about the state of the mathematical object that is in a variable for further use. Actually, for accurate math, truncation happens first, then rounding if the number is longer than can be used or is significant in the particular calculation. The only time that rounding would come before truncation is in the case where the number self-truncates...that is to say, the calculation comes out to a finite resolution or a resolution within the representational limits of the particular system. Rounding should never happen by default. The actual rule is that truncation should happen at one digit past the point to which you wish to round as long as that last digit is significant. By the way, floor() is a truncation function. Everett L.(Rett) Williams rett at gvtc.com