branch probabilities don't equal to 1

[wangjiawen2013]

Hi, Thanks for the update and I have tried the latest palantir, which is more convenient to interact with scanpy! However, I found some little flaws. Specifically, the branch probabilites don't equal to 1 when there is only one terminal, though it's very close to 1. When checking the value in Jupyter notebook, they are all 1, but they are not 1 when exporting to a csv file:

And, in this case, the branch probability plot cannot be shown correctly, some negative value appeared and some text are covered by the title !

[wangjiawen2013]

Besides, in my case, the colorbar of the heatmap is longer than the heatmap, which makes it not so becautiful as the one in palantir tutorial:

[katosh]

Hello @wangjiawen2013,

Thank you for your detailed report!

In palantir.plot.plot_gene_trend_heatmaps, the color bar is indeed the standard matplotlib color bar, added with plt.colorbar. Our function is designed to offer users control over its appearance by accepting a cbkwargs parameter. This allows for setting any arguments of plt.colorbar, except for mappable and ax. To adjust the size of the color bar, you can use the shrink argument, as follows:

palantir.plot.plot_gene_trend_heatmaps(ad, genes, cbkwargs=dict(shrink=0.5))

We did consider synchronizing the color bar size with the heatmap. However, this approach proved too rigid and less practical for heatmaps with a large number of genes. Therefore, we rely on matplotlib's default logic for scaling the color bar.

The observed deviations from a probability of 1 are due to the limitations of machine precision in floating-point calculations. These minute discrepancies are inherent in computational processes, where exact representation of very small or very large numbers is challenging. We are considering normalizing these minor deviations in the post-processing stage, which would involve adjusting the values based on the total sum of each row. I will come back to this issue if we decide to write a patch.

The plot you see, despite these nuances, is accurate. The color bar legend being obscured indicates that the numerical values are only minutely different from 1, with a factor of 1e-14 (it reads 1e-14+1). This minor deviation means they are very close to 1. Addressing text overlap in such specific cases would require extensive changes to the plotting function. Given that the plot’s informative value is minimal in scenarios involving only a single fate, such a rework doesn't seem warranted.

Please let me know if this resolved the raised issue or if you have any further questions.

[katosh]

Feel free to reopen the issue if it has not been resolved or you have additional questions.