Uniform printed decimals

[vigna]

I'm having a slight aesthetics problem—when the second decimal is zero it is not printed, as in

355.8MB/37.41GB/6.95GB/68.72GB

Would it be possible to fix the number of decimal digits so that they are the same no matter what they are? That would help with alignment, tables, etc.

[rsalmei]

Humm, it is actually by design, the less visual clutter the better I thought.
So, 355MB is nicer than 355.0MB, which is way nicer than 355.00MB.
I actually put code to detect zeros in decimal places, and actively avoid generating them...

But yeah, I do understand the need to maybe align things up.
Unfortunately, even if I do support this, they would still not align because of the mantissa value: 3.0MB will always be smaller than 355.0MB.
So, if you'd still have to insert some padding and either right or left-align it, this would also work now:

   35MB 37.41GB
355.8MB     6GB

or

35MB    37.41GB
355.8MB 6GB

Wouldn't it work for you?

[vigna]

I agree with you in absolute terms. The problem is that I'm displaying 5 of these in a row, and the variation makes it difficult to parse—you literally have to chase the decimal point in each number.

Alignment (see any scientific paper) happens on the decimal point, so 3.0MB and 355.0MB are aligned, as well as 3.00MB and 355.67GB, but 35MB and 255.8MB are not. I understand these are very personal decisions. I'm porting some Java software and there I was just using the standard APIs, in which you can specify the exact number of decimals (and a thousands separator).

[rsalmei]

I don't think any standard API would be able to generate human representations, including SI prefixes and rounding adequately. Rust has a standard API capable of printing fixed decimal points, pretty much like the Java one.

Anyway, I'll think about it, even though I think it is kinda out of this crate's scope.
The very reason I created this crate was to get "human-friendly" representations, and I firmly believe "3MB" is more human-friendly than "3.00MB".
But I might be exaggerating, I'll give it some thought and will let you know. Thank you.

[vigna]

What I meant is that I was choosing the correct SI or binary unit (it's completely trivial, as you know) and then let the Java API print exactly 2 decimals and handling the commas.

[rsalmei]

I see, you were finding the SI prefix by yourself, as, sure, it is trivial.
Well, you did not need to close this, I said I was going to think about it, but it seems you decided to do the same now, ok then.

In fact, in addition to thinking if it does fit the crate concept, fixed precision is not that simple here because of the engine that avoids generating .0 and .00 in the first place.
Also, in addition to making it for counts, I'd also have to make it work for both durations and throughputs to maintain the consistency between all entity kinds, so it is a lot of work and not an easy decision.

I'm still going to think about it, even if it does not interest you anymore.

[vigna]

What I mean is that saving five additional lines of code is not worth the trouble of changing your design. You are trying to solve a different problem than I am.

[rsalmei]

It is done. The 2.0 version will include a new Representation system, so users can customize the output however they like, including fixed precision.