Add :percent

[eemeli]

Fixes #956

A separate :percent function is added, and the style option dropped from :number and :integer.

As proposed in #987, selection is not enabled for :percent.

I've also left out the notation and compactDisplay options, as I'm not aware of any actual use cases combining them with percent formatting.

[aphillips]

Since we have a separate function, purpose built for it, should we offer a pre-computed mode?

[eemeli]

You mean an option toggling if the input is multiplied or not?

[aphillips]

Yes, exactly.

[sffc]

ICU4C calls it "scale" or "multiplier"

ICU4X calls it "multiply_pow10"

I don't think we've had a proper bikeshedding session on this before. I've sort-of named it what I felt like naming it and no one ever pushed back with better names.

[eemeli]

Given that we'll be defaulting to a value 1 getting formatted as something like "100%", I think scale makes the most sense, with a default value of 1 and supporting 100 as an alternative. With this approach,

{42 :percent scale=100}

would then be formatted as "42%".

Or is the ICU4C meaning of this option the exact opposite?

[sffc]

Another thought: an enumeration might be appropriate here. Something like:

1. scalingMode: "scale" scales the number: 0.5 => 50%
2. scalingMode: "passThrough" passes through the number: 50 => 50%

(sorry for the quad-post)

[eemeli]

In that case, scale is a rather sub-optimal choice, as it demonstrably can be understood as either "scale the number by this much" or "the scale extends to this value as the maximum".

[sffc]

More suggestions, with some help from an LLM

enum PercentageScale { Fraction, Percentage }
enum InputMode { Decimal, Scaled }
enum ValueType { Normalized, Preformatted }
enum PercentMode { Ratio, Percent }
enum ScaleType { UnitInterval, WholePercent }
enum InputScale { PartsPerHundred, FinalPercent }
enum Scale { Raw, Scaled }

[eemeli]

Maybe style=raw, as an alternative to a default style=scaled?

[sffc]

I would like to avoid any option with the unqualified style name.

[aphillips]

For clarity, and since "resolved value" and "options" are the terms, perhaps:

Suggested change

	together with the resolved options' values.
	together with the _resolved values_ of the _options_.

[eemeli]

Variants of this same snippet are used in nearly all the functions. This change would be better made separately, affecting all of them at once.

But yes, referring to the options' resolved values would be appropriate, but note that this isn't the same as options, given that the resolved options are determined by the function handler. In practice they can include ones coming from the operand as well, and don't necessarily contain all of the options.

[aphillips]

Perhaps "resolved values of the resolved list of options"? Oh the pedantry...

[sffc]

Just say that all options not named in the :percent function's list above are discarded?

[eemeli]

That would be different from what we do with other functions, such as :integer, and it would make extensibility difficult.

An implementation could support additional options that are set in the calling code on the value being formatted, and are understood by the formatter. For a somewhat silly example, an implementation could support colour as a property of numbers, and format a "green 0.42" so that the % sign was also green in the output. If we here said that all options not explicitly listed are discarded, this kind of extensibility would not be possible.

[sffc]

ICU4C calls it "scale" or "multiplier"

ICU4X calls it "multiply_pow10"

I don't think we've had a proper bikeshedding session on this before. I've sort-of named it what I felt like naming it and no one ever pushed back with better names.

[eemeli]

During today's discussion, we noted that percent formatting is already available via :unit unit=percent.

This means that introducing :percent or retaining support for :number style=percent would be duplicating nearly the same functionality by two different means, and I don't think we should do that.

To still support the multiplicative behaviour (which :unit doesn't have), it might be best to add a :math multiply operator. @sffc raised some performance concerns about allowing multiplication by any number, and the digit-size option range (used by :math add and :math subtract) caps out at 99 for literals. Therefore, I'm considering refactoring this PR to:

• Drop :number style and :integer style.
• Add :math multiply with supported values 10, 100, 1000.

[aphillips]

Add :math multiply with supported values 10, 100, 1000.

I'm dubious that this is a good idea. The :math function has a suggestive name. It's reasonable to assume that it will, over time, be extended to other purposes, similar to math functionality in programming languages (such as java.lang.Math in Java). It's convenient to solve specific short term problems using this function now, but we should avoid binding our hands too much.

Note that this would mean that unit=percent would become unscaled ({50 :unit unit=percent} formats as 50%). If we want to provide a :math modifier, perhaps scale or exp.

Also, there are other formats that we're ignoring (because they are much less common) which are supported by CLDR data, which is per-mille and per-myriad formatting. We should just solve the problem. The existence of these suggests a convenience function or maybe a convenience unit.

Consider:

.local $val = {|50|}
.local $pct = {$val :unit unit=percent-scaled}
{{I print {$pct} as 5000% but {$val :unit unit=percent} as 50%}}

[sffc]

I still have the weakly held position that :percent carries its own weight, and we should just add it and move on.

It doesn't completely duplicate functionality: you use :percent if you want scaling, and :unit unit=percent if not.