Re: Strange problem
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
|
Not Categorized, Please Help
|
|
