Unexpected GiB in unit calculation

[zcohan]

I'm seeing GiB in some unit calculations, when I expect GB.

There seems to be a threshold point. Here's an example:

5 minutes * 54.74 MB/second = 16.422 GB
5 minutes * 54.75 MB/second = 15.296973288059 GiB

[josdejong]

That's an interesting one, thanks for reporting @zcohan .

Reason is both prefixes G and Gi are defined in the same list, and there is currently no distinction at to prevent switching from one to the other, see code:

mathjs/src/type/unit/Unit.js

Lines 1338 to 1356 in a514b8c

	BINARY_SHORT: {
	'': { name: '', value: 1, scientific: true },
	'k': { name: 'k', value: 1e3, scientific: true },
	'M': { name: 'M', value: 1e6, scientific: true },
	'G': { name: 'G', value: 1e9, scientific: true },
	'T': { name: 'T', value: 1e12, scientific: true },
	'P': { name: 'P', value: 1e15, scientific: true },
	'E': { name: 'E', value: 1e18, scientific: true },
	'Z': { name: 'Z', value: 1e21, scientific: true },
	'Y': { name: 'Y', value: 1e24, scientific: true },
	'Ki': { name: 'Ki', value: 1024, scientific: true },
	'Mi': { name: 'Mi', value: Math.pow(1024, 2), scientific: true },
	'Gi': { name: 'Gi', value: Math.pow(1024, 3), scientific: true },
	'Ti': { name: 'Ti', value: Math.pow(1024, 4), scientific: true },
	'Pi': { name: 'Pi', value: Math.pow(1024, 5), scientific: true },
	'Ei': { name: 'Ei', value: Math.pow(1024, 6), scientific: true },
	'Zi': { name: 'Zi', value: Math.pow(1024, 7), scientific: true },
	'Yi': { name: 'Yi', value: Math.pow(1024, 8), scientific: true }

We somehow need to distinguish the two types of prefixes. I don't have an idea right away what would be a handy approach though, @ericman314 do you have any ideas?

[ericman314]

Right, the prefix is chosen to keep the rendered value "not too big" and "not too small". I don't know of a quick fix for this, it'll take a little more thought.

[josdejong]

If anyone is interested in picking this issue up please let me know.

[jackcmason]

I would be interested in fixing this issue

[harrysarson]

Is what we need to do is similar to choosing between feet and meters for distances?

[josdejong]

Thanks for your offer @jackcmason, some help would be great. I think we first need to come up with an idea on how to solve this issue. Do you have any suggestion?

[josdejong]

@harrysarson I think it's a similar to not wanting to mix short prefixes (like cm) with long prefixes (like centimeter)

[harrysarson]

However, 1 cm and 1 centimeter are exactly the same length - this is not true for 1 Gb and 1 GiB

[josdejong]

:) yes true, I just mean they are somehow similar but should not get mixed together.

[ericman314]

The problem is, how do we decide what the user wants to see? It is a combination of choosing a prefix to keep the magnitude of the value reasonable, choosing the correct format of the prefix (long or short), and the correct unit system, SI or something else. All we have to go on is options the user configures, and what the user has used in the past.

Here's one possible approach. We could make several highly customizable options which explicitly define what units and prefixes the user will see. Things like GB or GiB. Then, to achieve the "automagic" behavior that math.js currently tries to do, the options would be selected automatically as the user is interacting with a math.js instance. That would go a long way to eliminating the mystery of what's going on behind the scenes in the unit formatter, since the user could just query the current config to see why a unit was formatted the way it was. For most users that are happy with the way things work now, it would still work the same, but for the few that need to control how units get formatted they could do so.

[jackcmason]

I think that bits should be restricted to SI or IEC prefixes when parsed or by the _bestPrefix method based on whether the input value is an SI or IEC unit. The user should convert between the two prefixes with a conversion method between the SI or IEC units to be called by the user explicitly.

[josdejong]

@ericman314 I like your idea, I think we should en up with putting all current magic in configurable options which have a good as possible default settings. That will empower users that want total control.

@jackcmason would be nice as a start, in many (or some?) cases we can know the typeof prefix from the input (like KiB or KB). Where we don't know it from the inputs, we should use for example EIC by default but (on long term) make this configurable by passing options to the format function.

Would be nice if we could make a first small step in the right direction splitting these prefixes, and as a second step work towards a configurable solution.