Closed mdickinson closed 1 year ago
Note that we have data_low > data_high
for the inputs to auto_ticks
above. While this may be indicative of an error in the calling code, I think it would make sense to also make auto_ticks
robust for this kind of input.
Not a fix, but a work-around: if you can create a replacement without the error, it is straightforward to create a new tick generator around the replacement and use that in the downstream app.
Also, separately, this feels like it is a symptom, not the root cause: the axis bounds being inverted smells like there a problem with the values being passed to the ticking system. In particular, are we in a situation where the width (or height, depending on orientation) of the axis component is negative? If so, then all sorts of things may be messed up beyond ticking.
FWIW - This same traceback was seen a while back: https://github.com/enthought/chaco/issues/529 and that issue was closed by https://github.com/enthought/chaco/pull/636 but 636 was just checking for NaN inputs, not non-NaN inputs that could lead to NaNs inside the method
In this case, tick_interval
on this line ends up as NaN
https://github.com/enthought/chaco/blob/0907d1dedd07a499202efbaf2fe2a4e51b4c8e5f/chaco/ticks.py#L272
and that is because log10
is getting negative inputs here
https://github.com/enthought/chaco/blob/0907d1dedd07a499202efbaf2fe2a4e51b4c8e5f/chaco/ticks.py#L392
Tentatively closing as this should be resolved (at least in the sense of treating the symptoms) by #848
We're running into the following problem with
auto_ticks
on a downstream project, leading to a blank plot window.Expected behaviour: a list of tick locations is returned (possibly the empty list).