"Occupied Space" size in decimal GB ?

[comshak]

Shouldn't the "Occupied Space" dialog report size in decimal GB?

The KB and MB are whole numbers, and that seems pretty user friendly, but when it comes to GB, it gets rounded and I believe it loses a lot of information by reporting, for example 2G instead of the real 1.5G -- see attached image...

Image: https://i.postimg.cc/h46b5GhH/occupied-space.png

I often need to see if I already have a file, so I need to look for a 1.5G file (for example), but when I check the directory space I see 2G, so I now need to convert from MB to GB. It's a small task, but multiplied over many times makes the job much slower.

[ghisler(Author)]

Well, you could say the same about MBytes and kBytes, e.g. when you have selected 1.5MB of files, it would be better to show 1.5M instead of 2M. Maybe I should show digits behind the decimal point when there are few digits in front of the decimal point?

[tuska]

In case it is of interest:
There was a discussion in the 'Everything' forum here recently:
Request: Number value exactness tolerance and approximation

[comshak]

Yes, I agree the same can be applied to MB and KB. I was just finding the "error" to be huge when it comes to GB
Probably the simplest format would be '%.1f' for K, M and G?

[ghisler(Author)]

That would be the easiest way, but the precision would still be off, e.g.
921.1 GB would have an accuracy of 921+-0.05GB or 0.1/921.1 = approx. 0.1 permille
92.1 GB would have an accuracy of 92.1+-0.05GB or 0.1/92.1 = approx. 1 permille
9.2 GB would have an accuracy of 9.1+-0.05GB or 0.1/9.2 = approx. 1 percent
1.5 GB would have an accuracy of 1.5+-0.05GB or 0.1/1.5 = approx. 6.7 percent

[Hacker]

921
92.1
9.21
?

Roman

[comshak]

I think losing some precision due to rounding/truncation is ok (it is like that currently anyway), because the exact size in bytes is already listed above the KB / MB / GB.