Range padding possibly discards the log axis properties

[ilayn]

This similar to #2431 but in the log-log axis context. If I plot the following

x = np.arange(80,2500)
s = ColumnDataSource(data=dict(x=x,y=y))
dd = figure(x_axis_type='log',y_axis_type='log')
dd.line(x,x)
show(dd)

I get

which is a bit strange for the auto padding. But if I plot the following

x = np.arange(1,20)
s = ColumnDataSource(data=dict(x=x,y=y))
dd = figure(x_axis_type='log',y_axis_type='log')
dd.line(x,x**2)
show(dd)

In general, I'm trying to understand the reference guide properly. For example, if I read the DataRange1d part, I understand that it has a range-padding but then is it the default range object for the plots ?

If I want to explicitly supply an auto range with a different padding value should I go about it as
x_r = DataRange1d(range_padding=0.2) and then supply this to the figure x_range attribute? It would be really nice if this can be supplied directly to x_range.

Finally, I think in the DataRange1d docs, it should be called the fraction but not the percentage as A percentage of the total range size to add as padding to the range start and end. sounds like I should enter 20 instead of 0.2 but that makes the range huge.

[bryevdv]

@ilayn using figure, plots get DataRange1d by default, unless you explicitly provide bounds with e.g., x_range=(0,10) or similar. So if you want to change the padding you could do:

dd = figure(x_axis_type='log',y_axis_type='log')
dd.x_range.range_padding = 0.2

I agree the wording is better with fraction. Would you be interested in submitting a PR to change the wording in the docstring?

In general I don't think much thought has been given to the integration of range_padding with log axes. I can imagine is it not currently ideal, and might need some development to make it behave better.

[ilayn]

Ah, thanks. I tried a few things as such but never occured to me that depending on the existence of fixed range the underlying range options change.

Because I've received the error message

AttributeError: unexpected attribute 'range_padding' to Range1d, possible attributes are callback, end, name, session, start or tags

That should have given me the hint. If you would kindly point me to the part where the range padding is handled (I'm still confused about where to find what) I might give it a try to modify the log axis handling together with the docstring part.

I'm sure that would give me a nice exercise to get more acquainted with the inner workings of bokeh. I think I am going to rely on bokeh more than what I have anticipated in my small library so probably I should get used to using bokeh as a backend. Hence I would really appreciate some pointers on how the team structures bokeh code.

One particular difficulty I am having is to find a particular feature in the code. Currently, I'm using the import directive (for example, I see that I use bokeh.models.widgets.layouts to import the deprecated VBox then I go to the docs to see if it is really there then I go to the code etc.). If I can be of use, I would like to research on indexing options in the docs. That would fix the searching hassle.

[bryevdv]

Hi @ilayn the handling of range_padding is actually handled on the BokehJS side, here is the code:

https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/range/data_range1d.coffee

I would love ideas (and help!) about improving and indexing the docs, it's been on our list for a while... but there's a long list of things. :)

[ilayn]

Perfect, thank you. I will work on this and if I can, I will submit the PR together with the docstring. A quick question though: is the axis type declared to the BokehJS side or can I pull it out? A better and more general question would be:

Is there a gateway that from the CoffeeScript I can request Python details about a figure() instance?

[bryevdv]

There is a LogAxis model:

https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/renderer/guide/log_axis.coffee

but note that all this really is is a simple subclass of Axis that happens to default initialize the ticker to be a log scale ticker, and the tick formatter to be a "log formatter", for convenience.

In principle, someone could just declare a base Axis and mix and match tickers and formatters however they please. So I would say the most robust solution would be to look at the axis renderer (whatever type it may be), and then inspect its ticker class. If it has a log ticker, then it is a "log axis" regardless of anything else.

[bryevdv]

Edit: Another (possibly better option) would be to delegate the padding value calculation to the tickers altogether. So the data range would always give the the data min/max and the padding fraction to the ticker, and the ticker would give back the appropriately adjusted min/max to use for the padded range. That way data ranges wouldn't have to do alot of gorpy type checking and switching, and the logic for "ticker-appropriate" padding is associated sensibly with the ticker.

Edit: for more context I think that would require finding a way to pass a ticker to the update method here:

https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/range/data_range1d.coffee#L47

I'm not sure offhand if the plumbing for that would be easy/sensible but it might be worth investigating. The data range updates are coordinated by the plot view here:

https://github.com/bokeh/bokeh/blob/master/bokehjs/src/coffee/common/plot.coffee#L112

It seems reasonable enough if there is just one axis per dimension, you could just pass in the axis or its ticker right there. The question (as always) is: what do you do when there are multiple axes? Which ticker do you pick to use to compute the padding value. I'm not sure what a "right" answer there is.

[ilayn]

Hmm. I don't think I can create an innocent PR if I cover any distance with this since it will instantly break many things simultaneously. Should I make a standalone version for this so that it can be investigated? Or could you let me know if you have a way-of-working for such situations?

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.