Conversation
|
I think we should drop the ties argument and only implement the “low” strategy for now. This should support a comparator as well as an accessor like d3.sort and d3.bisector do, probably using compareDefined to protect against non-comparable values. (I suppose this means that d3.rank should accept multiple accessors like d3.sort does, too… but we didn’t extend that to d3.bisector or for that matter d3.quickselect, so maybe let’s punt on that convenience for now and focus on the basics.) |
|
I've updated https://observablehq.com/@d3/rank-dev and I think it covers everything (rank, ties, comparator, multiple accessors). Just need to decide on the scope and I'll merge the relevant code and tests. |
|
Would you be okay only supporting the ties = low strategy to start? I would prefer to start there and not support the other strategies. |
* only implement “low” ties strategy * only test “low” ties strategy * only allow iterables * adopt Float64Array.of * documentation: remove ties; observablehq/@d3/rank Co-authored-by: Philippe Rivière <fil@rezo.net>
2 participants
Question: I'm not sure about the API; in particular if we have the idea that the accessor could at some point be specified as a string (like we do in Plot), this would be ambiguous when callingrank(array, "high").