Using the right notation for the right exponent base. #7829

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants

jarl-dk commented Oct 3, 2012

Currently if a Rails application uses the ActiveSupport::NumberHelper#number_to_human_size to provide a user with information like "2000.34 TB" the information is ambiguous (hence not very usefull). It is unknown whether that information means 2000.34_1000⁴ or whether that information means 2000.34_1024⁴. Not even if a user tries to download rails and figure out what it means, is it possible to tell. Because the Rails application (with undisclosed source code) may either call ActiveSupport::NumberHelper#number_to_human_size with or without the :prefix => :si option. The :prefix => :si option changes the exponent base but without changing the notation.

I am suggesting to change the ActiveSupport::NumberHelper#number_to_human_size so that notation goes hand in hand with the exponent base. Using binary (IEC) prefix for exponent base 1024 and SI prefix for exponent base 1000. My proposal can be seen as this pull request: rails/rails#7829

I don't have a strong opinion on whether or not the default is IEC or SI, as long as the notatation goes hand in hand with the exponent base, so information like "2000.34 TB" and "2000.34 TiB" is unambiguous.

Even a bit worse is that the current default behaviour (i.e. without the :prefix => :si option )is to incorrectly use SI notation for exponent base 1024, which is against international accepted standards[1].

Before you argue that IEC notation is not (yet) widespread: Remember that HTML5 is not (yet) widespread either, it is not even expected to finalise until 2014 (which probably will be delayed), but that doesn't imply that Rails should stay away from it.

Footnotes:
[1] http://en.wikipedia.org/wiki/Binary_prefix

Using the right notation for the right exponent base.
When base is 1024 the notation should be IEC prefixes (KiB, MiB, GiB, etc.)
When base is 1000 the notation should be SI prefixes  (KB,  MB,  GB, etc.)

    See
    http://en.wikipedia.org/wiki/Mebi-#IEC_standard_prefixes
    http://en.wikipedia.org/wiki/Binary_prefix

jarl-dk commented Oct 3, 2012

I don't have a strong opinion on whether or not the default is IEC or SI, as long as the notatation goes hand in hand with the exponent base, so information like "2000.34 TB" and "2000.34 TiB" is unambiguous.

This pull requests is having IEC units (exponent base 1024), so therefore the default text is changed to IEC notation (KiB, MiB, GiB, TiB). If the Rails community prefers SI units (KB, MB, GB, TB) this additional commit (found on this branch ) can be applied.

@jarl-dk jarl-dk referenced this pull request Oct 3, 2012

Closed

IEC prefixes #7819

Owner

fxn commented Oct 3, 2012

I am lost with so many discussions going on, can some be closed?

I like the idea of adding new systems of units. But I don't like the idea of replacing the one system of units we already use with two new ones that we usually do not use. Most of the time, our applications should speak the languages of the people who use our applications, rather than trying to teach them new languages (such as new systems of units).

The way of counting bytes that most of us use most of the time is a perfectly sensible, well-established system. It is not broken and does not need to be eliminated or fixed. But it can be expanded to.

The default system of units ought to remain KB, MB, GB, and TB referring to powers of two, not of ten (i.e., where 2.3 MB is defined to mean 2.3 * 1024 * 1024 B). This is what most people have used for a long time, and it works just fine, which is why it should remain the default. Let's call this system of units :binary (wikipedia).

We can then have named alternatives, namely :iec and :si, in addition to :binary. There would be three available systems of units, not two, and each system of units would have a name.

The number-presentation functions should take, as an option, the name of the system of units to use. For example, number_to_human_size(123456789, units: :si). The option symbol should be :units rather than :prefix. The default system of units ought to remain :binary.

As a bonus, you could offer an ActiveSupport configuration option default_storage_units which changes the default system of units, so that if an application configures ActiveSupport.default_storage_units = k, then every call to #number_to_human_size should use k by default if nothing is passed for the :units option. The default value for ActiveSupport.default_storage_units should start off as :binary, but may be changed in any given application.

Owner

jeremy commented Oct 3, 2012

+1 to @yfeldblum's suggestion. Keep the current default, binary units using the ambiguous KB/MB/GB, but allow other units if that's what you want for your app: ActiveSupport.storage_units = :si. And don't change localization keys, which breaks all i18n apps unexpectedly.

Owner

jeremy commented Oct 3, 2012

(Another option is to use IEC units, but not the ridiculous MiB, GiB suffixes. Gack!)

jarl-dk commented Oct 3, 2012

@jeremy : if you by IEC units mean powers of 1024, then that is the default case right now.

jarl-dk commented Oct 3, 2012

Thanks for all the feedback, I appreciate your time.

@jeremy: You got a point regarding localisation keys. Chaning those is actually an API change... back to work :-)

@yfeldblum : I like the idea of adding an :iec option to achive what I am interested in. I will work along the lines of that, but since that will extend functionality rather than change I would like make that as a clean commit to master (not as commit on top of this one), so what is the way to do it (github wise). Should a create a new branch (and a new pull request) with a clean commit. Or should I use git push -f to overwrite the branch that this Pull Request is associated with?

If you want to go based on my suggestion, then you can:

  • Make a new pull-request;
  • Reference this one (like: "supersedes #7829") in the new one; and
  • Close this one.

jarl-dk commented Oct 3, 2012

Superseeded by #7835

@jarl-dk jarl-dk closed this Oct 3, 2012

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