Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bytes? #17

Open
mauris opened this issue Jun 14, 2013 · 7 comments
Open

Bytes? #17

mauris opened this issue Jun 14, 2013 · 7 comments
Assignees

Comments

@mauris
Copy link
Contributor

mauris commented Jun 14, 2013

What about bytes? It would be very helpful if we can quickly change units in terms of bytes.

bits as well.

@triplepoint
Copy link
Member

Yea, this idea seems legit.

I'm not sure where I stand on the 1000 vs 1024 conversion factor debate, once you get to megabyte and above. I know there's the Mebibyte vs Megabyte convention (http://en.wikipedia.org/wiki/Mebibyte) but I feel like that's not very well used. Still, lacking a better way to distinguish, maybe that's the way to go? Either that or we just stick to the 1024 multiples and ignore the base-10 system altogether.

@mauris
Copy link
Contributor Author

mauris commented Jul 9, 2013

I think a 1024 multiples implementation would be better as calculations over thousands.

@MarkMaldaba
Copy link

I think this would be a great addition.

You could use "MiB" for mebibyte and "Mbyte" for megabyte (and so on for other magnitudes) and deliberately omit "MB" as a recognised unit, as it is inherently ambiguous. That way you avoid the confusion and allow both representations to be possible (as both will definitely be required, in different contexts).

You could maybe provide a way to specify that "mb" should be either base 10 or base 2 (with the default still being 'unrecognised') to save everyone having to manually add the aliases themselves, but that would be helpful, rather than essential.

@pierpaolocira
Copy link
Contributor

Hi all,
in my honest opinion 1024 multiples can be more comfortable, but they are not formally correct.

In the International System of Units (SI) the "kilo" multiplier refers to 1000 and not to 1024... so, in my mind, to continue to be "accurated", to comply with the SI, and in order to keep the code coherence (HasSIUnitsTrait::addMissingSIPrefixedUnits()) we should use the standard "k" prefix for "kilo" and "ki" for "kibi" (etc...).

But, I repeat, this is just what I think a library user expects...

@MarkMaldaba
Copy link

@triplepoint Any chance of an explanation as to why this was closed? Has it been implemented, or is it a wontfix? Or something else?

@triplepoint
Copy link
Member

Ah, I was cleaning up old tickets and mistakenly assumed this one was abandoned. If there's interest in it being implemented, I'll reopen. Thanks for the attention.

@triplepoint triplepoint reopened this Jul 26, 2017
@triplepoint triplepoint self-assigned this Jul 26, 2017
@timkelty
Copy link

Would love to see this as well!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants