GLMakie doesn’t seem to adjust axis limits automatically if the data contains an
lines(1:6,[-1, -2, 3, -Inf, -10, -11])
You have to use
to see all the data. It seems ok with NaN:
lines(1:6,[-1, -2, 3, NaN, -10, -11])
I’m using Julia 1.7.3, GLMakie v0.6.13 on Windows 10.
They will probably appreciate it if you have the chance to report this as a bug on their issue tracker on github. They would appreciate it even more if you provide a pull request with a fix
Not sure what exactly happens there but I always wonder if Inf should be allowed at all in a plot. Rendering a NaN in with a gap seems reasonable to me, but shouldn’t a point to Inf be a vertical line instead of nothing if we show it at all? Because it’s visually ill defined I would probably rather error than silently do weird behavior like this
I’m not really sure what it ought to do. I often plot things like
10*log10.(x) and it’s easier not to have to check for zeros first but maybe that’s just being lazy. I used to use Matlab quite a lot for that sort of thing but I can’t remember how it behaves.
yeah it’s difficult, you cannot really visualize infinities so if you want to show something then it has to be “hacky” to some degree I think
. Yes. I think this would be correct thing to do. Simply draw a line to the edge (or beyond) the plot clipping region. Hopefully the extra “if” statements won’t slow down the plotting algorithm in a significant way.
(x,y) = (inf, FINITEVAL) should also be drawn as a horizontal line to the edge of the plot.
Comment on @tt1234567’s example
NaN substitution appears to hilight a 2nd, more trivial issue:
inf values should be ignored when computing the x/y limits of the plot.
- It appears that Makie gives up as soon as an infinite value is detected (keeping with its default extents of:
I disagree: I don’t think it is ill defined (at least not visually).
But I would agree there are practical issues with such an implementation (ex: more complexity; vertical lines should be re-drawn as the user pans/zooms on the plot).
Agreed. Computing gain in dB (much as you describe) occurs quite often when processing data from circuit simulators at zero gain points. It is unpleasant to constantly add sanity checks/validation functions before plotting.
I also encounter similar issues when plotting results obtained from calculations of incomplete datasets (or when there are bugs with the calculations themselves )
I find that having a way of “showing” infinite tendencies on a plot is often useful (even if you can’t show infinity itself).