You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
The standard symbol for the metric prefix kilo- is k not K (so kB for kilobyte, not KB) #5
Thanks Andrea, I appreciate you creating the issue, however it would be helpful if you linked a source that verifies this claim so I don't have to Google it myself 😉
It is a weird issue. Microsoft use upper K for base-2. GNU use upper K for both base-2 and base-10, though they make a distinction between stand-alone K and KB (1K is 1024 bytes, 1KB is 1000 bytes). Some other command-line tools like rsync make the same distinction. The JEDEC standard uses upper K for base-2. Mozilla use lower k for base-2. Apple have used upper K for both base-2 and base-10.
I don't think there's a clean answer to how they should be used. If you wanted to be thorough i guess you'd need to provide five different sets of prefixes:
IEC style, base-2 (Ki == 1024)
SI style, base-10 (k == 1000)
SI style, base-2 (k == 1024)
Computing style, base-10 (K == 1000)
Computing style, base-2 (K == 1024)
That gets pretty messy though. If you really wanted to make everyone happy i guess what you'd do is provide a mechanism for users to define their own units. In addition to addressing this question you would also eliminate one of the two things that make this library English-specific — French users could specify o instead of B for example. (The other thing that makes it English-specific is the fixed decimal separator.)
idk if you want it to be that fancy though. If you don't, i would suggest just picking one. kB makes the most sense to me, personally
The consumer already has the ability to define their own decorator, so we're really just talking about making sure the bundled decorators are correct according to their respective sets. The metric/SI prefix for kilo- is k, and so kilobyte is kB. Using KB for kilobyte is perfectly reasonable (it's very common informally), but it shouldn't be presented as part of the metric/SI set, because it isn't.
Personally, I would like to see each base/set pulled into its own decorator. That would give you something like MetricSymbolDecorator (base 10; kB, MB, GB, ...), IECSymbolDecorator (base 2; KiB, MiB, GiB, ...), and InformalSymbolDecorator (base 10; KB, MB, GB, ... with the option to omit the B for just K, M, G, ...).
Sorry, i hadn't looked far enough into the decorators to see that you could extend them easily. That does address that. I agree with your second paragraph, having separate pre-defined decorators would be neat.
For my part, it seems like it'd be simplest for the end user if they didn't have to pass in a bunch of constants all over the place.
On balance, though, it might not work. The decorators are designed to accept the base from the formatter (which certainly seems reasonable — otherwise they'd have to know about the mathematics, right? which would make them... not decorators), so it doesn't really make sense to have ones that're inherently tied to a particular base. What if someone did like
(new ByteFormatter(new IECSymbolDecorator())
->setBase(10)
->format(16384)
;
for example? It wouldn't make any sense. I guess you could have your IECSymbolDecorator throw an exception in that case, and vice versa for your SISymbolDecorator, but that just seems weird, doesn't it?
Activity
Bilge commentedon Dec 30, 2015
Thanks Andrea, I appreciate you creating the issue, however it would be helpful if you linked a source that verifies this claim so I don't have to Google it myself 😉
hikari-no-yume commentedon Dec 30, 2015
It turns out both
kBandKBare used. k- is the SI prefix, but K is often used in computing: https://en.wikipedia.org/wiki/KilobyteBilge commentedon Dec 31, 2015
Can you recommended an action for resolution?
hikari-no-yume commentedon Dec 31, 2015
Since both are valid, offer the choice of a set with lowercase 'k' and the choice of a set with uppercase 'k'.
okdana commentedon Dec 31, 2015
It is a weird issue. Microsoft use upper
Kfor base-2. GNU use upperKfor both base-2 and base-10, though they make a distinction between stand-aloneKandKB(1Kis 1024 bytes,1KBis 1000 bytes). Some other command-line tools likersyncmake the same distinction. The JEDEC standard uses upperKfor base-2. Mozilla use lowerkfor base-2. Apple have used upperKfor both base-2 and base-10.I don't think there's a clean answer to how they should be used. If you wanted to be thorough i guess you'd need to provide five different sets of prefixes:
Ki== 1024)k== 1000)k== 1024)K== 1000)K== 1024)That gets pretty messy though. If you really wanted to make everyone happy i guess what you'd do is provide a mechanism for users to define their own units. In addition to addressing this question you would also eliminate one of the two things that make this library English-specific — French users could specify
oinstead ofBfor example. (The other thing that makes it English-specific is the fixed decimal separator.)idk if you want it to be that fancy though. If you don't, i would suggest just picking one.
kBmakes the most sense to me, personallydrrcknlsn commentedon Dec 31, 2015
The consumer already has the ability to define their own decorator, so we're really just talking about making sure the bundled decorators are correct according to their respective sets. The metric/SI prefix for kilo- is
k, and so kilobyte iskB. UsingKBfor kilobyte is perfectly reasonable (it's very common informally), but it shouldn't be presented as part of the metric/SI set, because it isn't.Personally, I would like to see each base/set pulled into its own decorator. That would give you something like
MetricSymbolDecorator(base 10; kB, MB, GB, ...),IECSymbolDecorator(base 2; KiB, MiB, GiB, ...), andInformalSymbolDecorator(base 10; KB, MB, GB, ... with the option to omit the B for just K, M, G, ...).okdana commentedon Dec 31, 2015
Sorry, i hadn't looked far enough into the decorators to see that you could extend them easily. That does address that. I agree with your second paragraph, having separate pre-defined decorators would be neat.
Bilge commentedon Dec 31, 2015
Why are separate classes better?
okdana commentedon Jan 1, 2016
For my part, it seems like it'd be simplest for the end user if they didn't have to pass in a bunch of constants all over the place.
On balance, though, it might not work. The decorators are designed to accept the base from the formatter (which certainly seems reasonable — otherwise they'd have to know about the mathematics, right? which would make them... not decorators), so it doesn't really make sense to have ones that're inherently tied to a particular base. What if someone did like
for example? It wouldn't make any sense. I guess you could have your
IECSymbolDecoratorthrow an exception in that case, and vice versa for yourSISymbolDecorator, but that just seems weird, doesn't it?I don't know