Bug in Num2Bytes

← →
Dodfr (2005-07-08 01:09) [0]

I found a little bug in scale change value.

-> while (Value >= 1024) and (I < 4) do

is wrong, it should be 1000 and not 1024 as it can produce some 1020GB/MB/KB instead of 1.02GB/MB/KB

regards.

← →
ECM © (2005-07-08 13:16) [1]

1GB = 1024MB
1.02GB = 1045MB <> 1020MB
1020MB = 0.996GB <> 1.02GB

← →
Dodfr (2005-07-08 13:51) [2]

I don"t understand what you mean ?

I just say that if you keep Value >= 1024 it may display 4 integer digits whene the function should be nicer if you never see more than 3 integer digits.

I think that all what is over 999 of actual scale should be converted into 0.xx of upperscale instead of getting into 4 digits 10xx value.

Whenever is it true that 1020MB is still under 1GB, it is better to get 0.99 as human float vision is based on 1000 divisor not 1024 so all is over 1000 should be scaled down.

But may be it is just a wrong personnal idea.

← →
Thaddy (2005-07-08 16:23) [3]

ECM is right: remember all are based on binary calculations.
All are multiples of 2, not 10! it should be 1024 not 1000 (that's for idiots)

← →
Dodfr (2005-07-08 17:12) [4]

I dont" touch the 1024 divider in the function :

while (Value >= 1000) and (I < 4) do
begin
Inc( I );
Value := Value / 1024.0;
end;

but just the limit at which the display will change its scale so you never get >999 value in a scale to keep max 3 digits as if you were in a 1000 "human" based system.

I feel it more natural but of course anybody choose its prefered view.

Bug in Num2Bytes Найти похожие ветки