x axis ticks: wrong value and collision

[agilly]

For some inputs, the forest function adds erroneous/duplicate values. See the MRE below:

in2=data.frame(effect=-0.08, lci_effect=-0.15, uci_effect=-0.03)
input=data.frame(Exposure="analysis name", Outcome="outcome name", `Beta (95% CI), Clinical Units`="confidence interval", `custom field`="custom field", prop="prop", ` `="                                                               ", P=0.3455)
forestploter::forest(input, est = in2$effect, lower = in2$lci_effect, upper = in2$uci_effect, sizes = 1, ci_column = 6, ref_line = 0, xlab = "x axis title, quite long")

This produces an x axis with a duplicated -0.1 value. This becomes obvious if you uncomment the check.overlap=TRUE, line in make_xaxis, you just seee two -0.1 ticks. I think what is plotted above it is the correct "0" x coordinate of the ref_line.

This may be an entirely separate issue but I am also posting here for completeness: In some other cases (no MRE for this as I saw it only in passing), it seems the x axis is plotted twice, you can clearly see the characteristic thickened effect and slight offset of the two lines being drawn over each other.

[adayim]

Hi, I think the problem is caused by auto calculation of x-axis ticks and ticks digits. You can solve this by providing the ticks as following:

forestploter::forest(input, 
                     est = in2$effect, 
                     lower = in2$lci_effect,
                     upper = in2$uci_effect, 
                     sizes = 1,
                     ci_column = 6, 
                     xlim = c(-0.2, 0),
                     ticks_at = c(-0.15, -0.1, -0.05, 0),
                     ticks_digits = 2L, # remove trailing zeros, use 2 if you want to keep it
                     ref_line = 0,
                     xlab = "x axis title, quite long")

Hope this solves your problem.

[agilly]

Thanks, I know I can specify the axis ticks, but this is part of a shiny app that calculates forest plots on demand for arbitrary data. I have no way of pre-determining the ticks.

…

On Sat, May 6, 2023, 05:07 Alim Dayim ***@***.***> wrote: Hi, I think the problem is caused by auto calculation of x-axis ticks and ticks digits. You can solve this by providing the ticks as following: forestploter::forest(input, est = in2$effect, lower = in2$lci_effect, upper = in2$uci_effect, sizes = 1, ci_column = 6, xlim = c(-0.2, 0), ticks_at = c(-0.15, -0.1, -0.05, 0), ticks_digits = 2, ref_line = 0, xlab = "x axis title, quite long") Hope this solves your problem. — Reply to this email directly, view it on GitHub <#42 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEWAUQ7TNSD2GCQEPRRTXDXEYIDZANCNFSM6AAAAAAXXJUW7Y> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[adayim]

You can try to calculate the ticks_at and ticks_digits in your Shiny app, and pass these to the forest function.
This is not an issue related to this package, I don't think I can help you with this.

[agilly]

I think the fact that forestploter generates an axis containing two identical 0.1 values at two different ticks indicates there is a bug in the underlying make_ticks and/or make_xaxis. Similarly, collision between x axis ticks and ref_line label also falls within the realm of "an issue with the package".

However, the documentation does state:

Although many efforts have been made to automatically get a pretty ticks break, it will not give a perfect solution, especially if 'log2' and 'log10' defined for x_trans. Please provide this value if possible.

Which indicates the authors of the package are not prioritizing these particular issues at the moment. Closing as this corresponds to a "will-not-fix" situation.

[adayim]

Hi, I think your point makes sense. It is related to auto calculation of ticks_digits. I have pushed an improvement regarding this. Can you try the development version from Github? Thank you very much.

[agilly]

Nice! This works using the github version, both on the MRE and on the real world example this was derived from. Thanks for the fix!

[agilly]

Reopening this, as it may not be ideal to publish commit d389e56 to release as is. In some cases I now get a very crowded x axis:

It may be due to a rounding issue, as shown if I just plot 1 interval:

If I open the first plot in a vector image editor and look at the axis label, it is actually trying to print 77.40000000000000 120.10000000000000 554.599999999999994. Maybe this could be fixed with a format or a round?

However, I cannot provide a MRE since I am unable to exactly reproduce the steps that lead to this new behavior. It seems to happen on some machines but not others, which is consistent with precision/rounding issues. If I figure it out, I'll let you know.

[adayim]

Yes, it is the rounding issue. The difficult part is to determine how many digits to keep. One may don't want to keep the decimals if all values are integer. I see your reference line is 1, so I assume this is caused by log transformation. I will look into this. Thank you for reporting this.