Non-numerical ordering of values wellmap.show()

[NRHowell]

I'm cant figure out why the order of numerical values is put out of numerical order in the key that is generated by wellmap.show().
The values in the .toml are in numerical order, and the resulting values for each well are correct. It creates a rather confusing map of the plate layout as the logical progression of colours is incorrect.

Am I doing something wrong here?

[kalekundert]

Thanks for bringing this up, and you're not doing anything wrong. This is a problem I've tried to deal with on several occasions, but it's proven difficult to come up with a rule that produces intuitive results all the time.

Currently, the rule is that labels are sorted first by their topmost row coordinate, then by their leftmost column coordinate. Here, that doesn't produce great results because the wells are organized in columns rather than in rows. In the first versions of wellmap, labels were sorted by order of appearance in the TOML file, but this unavoidably produced weird results when including/concatenating files. After that, I tried sorting by value (for data types that have natural orderings, i.e. everything but strings). I ended up not liking that either, because the ordering in the label bar often ended up opposite of the ordering on the plate (e.g. imagine the labels went 0.01-100, while on the plate they go 100-0.01), which I thought made the plot hard to read. The idea behind the current rule is to fix this problem and get the order of the label bar to roughly mirror the plate itself.

Now that I'm talking about it, it occurs to me that I would get better correspondence between the plate and the labels if I sorted by columns and then rows. But I should also do something to eliminate the possibility of non-numeric orderings, because it's always confusing if the colors jump around in a different order than the values. Another difficulty with this example is that not all of the labels are numeric, so the code also needs to be smart enough to ignore the strings when doing the sort. Overall, I think the algorithm needs to be something like this:

• Group values with the same data type.
• Sort non-string labels in ascending and descending order and keep whichever best agrees with the plate layout coordinates.
• Sort string labels by their top-leftmost (or left-topmost) coordinates, similar to the current approach.
• Put all the groups back together, again in the order that best agrees with the plate layout coordinates.

I don't expect this to be a huge change, so hopefully I can get to it pretty soon. For future reference, here's a link to the relevant code.