value ascending / value descending

I’m making categorical histograms (with and without z and histfunc: sum). I’d like to be able to sort these histograms in descending by value order without using transforms.

Maybe this would fit under categoryorder: 'value ascending' and categoryorder: 'value descending'? https://github.com/plotly/plotly.js/pull/419/files#diff-0e41c2e162564438ff091d0ed6b5b455R472

[nicolaskruchten]

wanted to braindump part of a conversation I had with @antoinerg here. It’s not critical to resolve this for 1.48 but I want to make sure we don’t lock ourselves out of a more complete API.

It seems that in categoryorder = "value (a|de)scending" mode there are at least 3 extra pieces of information we need to specify the flavours of ordering I can imagine:

1. Which traces’ values should be included in computing the ordering at all?
2. How/should we aggregate the per-trace values if there are 2 or more values per trace in a given category?
3. How/should we aggregate the among-trace values if there are two or more traces with values in a given category?

The motivation for 1 is that I might want to sort the axis by a single trace, and we’d likely want to specify a way of breaking ties, so in extremis we’d want to allow an exhaustive ordered list, and we’d also want to specify “no among-trace order preference”.

The motivation for 2 is that in the case of grouped bars at least, I might want to sort by the height of the maximum stack, rather than the maximum single element.

The motivation for 3 is pretty clear: we need to aggregate somehow.

Taking just the case of 3 and 2 together, we might imagine an attr that takes two functions that interact such that my max-stack idea would be “max sum”. In that case, the options that @antoinerg already implemented already work nicely as “max max”, “min min” and “sum sum”. It would also allow us to do something like “mean median” to order grouped box-plots in a particular way. Not all options make sense, clearly, such as “min max” or “mean mean” or “median median” so we could imagine a world where we enumerate the options perhaps.

So in terms of a half-baked attempt at an API, we could accept two attrs: a composite aggregation function that accepts "sum", "max sum" and friends (default=sum?), and a trace-scope array that defaults to [] meaning “no preference” but accepts an ordered list of … trace.uids? trace indices?

[alexcjohnson]

should we have the biggest value at the top or the bottom?

You could say the same about category (ascending|descending) - ascending will put a at the bottom and e at the top so they’re actually in reverse alphabetical order. In fact you could even make that argument about the order based on data in the trace.

I guess with a categorical Y axis you generally do read the graph from top to bottom, as opposed to numerical axes that you almost always read bottom to top. But making that the default behavior I think has much more extensive consequences than just choosing it for the new feature. So unless we’re prepared to alter the rest of that behavior, I think ascending has to put the biggest at the top.