The “pie” generator isn’t really about pies.

[mbostock]

It’s just dividing a range proportionally by value. It happens that the default range is [0, τ], but you could also use the pie generator to compute normalized stacked bars, for example. Related #7.

[jasondavies]

It is tantalisingly similar to pv.normalize, though I suppose we would also need an optional padding specifier.

Currently, I think padAngle is a bit specific to donuts/pies because internally it isn’t allowed to be larger than (endAngle - startAngle) / n, and I don’t think that is necessarily desirable in the general case.

[mbostock]

I don’t think that restriction on padding makes it specific to pies. If you were to apportion the range [0, 1] up into n pieces by value, wouldn’t you still restrict the maximum padding per piece to 1 / n? Otherwise you’d exceed the given range.

But, that still leaves two characteristics that are pie-specific:

• The generated objects have startAngle, endAngle and padAngle properties.
• The range defaults to [0, τ].

I’d be willing to forgive the second, but the first is strongly useful and specific. I suppose you could drop the “angle” suffix and use the generic names “start”, “end” and “pad”, and make the corresponding change to the arc generator. But that seems… undesirable. So I’m going to close this issue.

[jasondavies]

If you were to apportion the range [0, 1] up into n pieces by value, wouldn’t you still restrict the maximum padding per piece to 1 / n? Otherwise you’d exceed the given range.

For a non-circular range, you would restrict the padding to 1 / (n - 1), so it’s a bit different.

[mbostock]

That assumes you don’t want padding at the start and end of the range. You might still want that? For that matter, the pie generator can be used with a range that does not form a complete circle, such as [0, π]. It still pads the start of the first arc and the end of the last arc in this case, in part because there’s no way to tell the arc generator that the padding is asymmetric.

For example:

[jasondavies]

Ah, good point. I agree this is probably not important enough to pursue though; the only other place it might be used would be for ordinal.rangeBands, where the outer padding can be different from the internal padding.

[mbostock]

Related d3/d3#2237, which proposes asymmetric padding for arcs.

[mbostock]

I took a quick pass at asymmetric padding in #42. For example: