value ascending / value descending

[chriddyp]

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

[chriddyp]

I suppose similarly with stacked bar charts. in this case, it'd be nice to keep the groups (grouping the bars by color) but sort within each group. the sort could be the sum of all bars or the bars within that trace.

[etpinard]

Maybe this would fit under categoryorder: 'value ascending' and categoryorder: 'value descending'

It could, but maybe we want this sorting-by-value feature for non-category axes also?

[alexcjohnson]

What would it mean to sort a non-category (ie continuous) axis?

[chriddyp]

maybe we want this sorting-by-value feature for non-category axes also

I can't think of any use case for this off the top of my head

[antoinerg]

In the presence of multiple traces, one should be able to specify how to aggregate the values (sum, mean, max, median, etc...). This will require a new attribute. @nicolaskruchten can you remind me the name you suggested for this attribute.

[nicolaskruchten]

I don't think I had a good name for it :) categoryorderfunc ?

Please note that this will need to apply not only across traces but across all values of the same category (i.e. you can have multiple data rows at the same category within a trace too!)

[antoinerg]

In branch sort-by-value (compare to master), I use the values obtained from calc to create new sorted categorical axes that are then used to perform a second calc operation.

Unfortunately, running calc again is not optimal, but it is necessary at the moment since the calc routine is sometimes coupled to the axis object (for example in histogram, it is used for the autobinning logic). Note that this second calc call will only happen if categoryorder is "value (de|a)scending".

cc @plotly/plotly_js, @alexcjohnson

[etpinard]

Very nicely done @antoinerg

I don't think we can implement this w/o calling _module.calc twice, so 👌 . We should make sure though that we only call _module.calc twice on subplots with categoryorder: value (de|a)scending" axes (hint: try using gd._fullLayout.xaxis._traceIndices).

Looks like the trickiest part of this PR now becomes this block:

                for(var k = 0; k < cd.length; k++) {
                    if(type === 'scatter') {
                        categoriesValue[cd[k].x][1] += cd[k].y;
                    } else if(type === 'histogram') {
                        categoriesValue[cd[k].p][1] += cd[k].s;
                    }
                }

which will be hard to generalize. Note that categoryorder works also on polar, carpet and gl3d (which doesn't use gd.calcdata) axes. Note also that "key" in questions depends not only on the trace type but also on the axis letter. For example,

                    if(type === 'scatter') {
                        categoriesValue[cd[k].x][1] += cd[k].y;
                    }

works when the x-axis has a set categoryorder, but we should have:

                    if(type === 'scatter') {
                        categoriesValue[cd[k].y][1] += cd[k].x;
                    }

for y-axes with categoryorder.

[antoinerg]

Quick question: for horizontal bars, when ordering categories by ascending value, should we have the biggest value at the top or the bottom? In the figure below, the biggest value is at the top. I think I prefer the opposite but I'm not completely sure either. What do you think?

[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.

[antoinerg]

Looks like the trickiest part of this PR now becomes this block:

                for(var k = 0; k < cd.length; k++) {
                    if(type === 'scatter') {
                        categoriesValue[cd[k].x][1] += cd[k].y;
                    } else if(type === 'histogram') {
                        categoriesValue[cd[k].p][1] += cd[k].s;
                    }
                }

which will be hard to generalize.

Yes, indeed. What trace types should initially be supported?

@nicolaskruchten What aggregation do we want to support initially? Would sum, min and max be sufficient?

[nicolaskruchten]

Sum/min/max is a fine start for this release, yes!