-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
plot: plots fails to render with oversized glyphs #773
Comments
it's coming from func padY(p *Plot, c draw.Canvas) draw.Canvas {
glyphs := p.GlyphBoxes(p)
b := bottomMost(&c, glyphs)
yAxis := verticalAxis{p.Y}
glyphs = append(glyphs, yAxis.GlyphBoxes(p)...)
t := topMost(&c, glyphs)
miny := c.Min.Y - b.Min.Y
maxy := c.Max.Y - (t.Min.Y + t.Size().Y)
by := vg.Length(b.Y)
ty := vg.Length(t.Y)
n := (by*maxy - ty*miny) / (by - ty)
m := ((by-1)*maxy - ty*miny + miny) / (by - ty)
return draw.Canvas{
Canvas: vg.Canvas(c),
Rectangle: vg.Rectangle{
Min: vg.Point{Y: n, X: c.Min.X},
Max: vg.Point{Y: m, X: c.Max.X},
},
}
} for the dimensions you chose, (the same issue may also happen in @kortschak what would be the regularization for this singularity ? |
I don't see how we can regularise this; we are being asked to fit an elephant into a matchbox, which is not something we can do. We probably should return a meaningful error here though. There could be a check in |
One possibility would be to add an |
Or:
All options (except the exploding matchbox one) suffer from the fact that the error/panic will be hard to link back to the problematic plotter. |
Another would be to draw only the glyph boxes in the case that there is an overflow (filled so that if it is completely overflowed it shows up). This at least gives an indication that something is wrong to look for. |
I am not sure I understand what you mean |
If we render obviously wrong red blocks on the plot instead of what the user is expecting, the positions of the red blocks will help them figure out which part caused the failure. |
I'd be OK adding an error return, but I'd like to also do a visual panic on the plot as described above. This way if you ignore the error, you will see it in the output. |
Note that I recall Ethan being opposed to |
Maybe this is a silly question and I'm missing something obvious, but wouldn't it be possible to simply squish the box part in the vertical direction? As I understand it, the vertical size is always fixed, no? (of course this is all transposed for a vertical box plot). |
Is there reason to not just make the sizes correct in the first place? |
What are you trying to do?
Generate a box plot visualization on a canvas of a specified width and height.
What did you do?
https://go.dev/play/p/EzwxtwaRRnA
Unfortunately, this times out while fetching gonum, so I cannot verify that it builds and runs correctly in the Go playground. However I have tested it locally with go 1.21.1 darwin/arm64. It reproduces for me against both the 0.13.0 and 0.14.0 tags.
What did you expect to happen?
I expected both
p1.svg
andp2.svg
to contain the generated box plots. If for some reason gonum/plot was unable to render the plot correctly with the specified dimensions, I would have expected some kind of error, rather than a nil error and an empty output.What actually happened?
p1.svg
contains the expected plot, butp2.svg
is blank, with only the axes being rendered. I will attach copies ofp1.svg
andp2.svg
as generated on my local machine.p1:
p2:
I also tried using PNG outputs rather than SVG, but the results were the same, so I do not believe this issue is SVG-specific.
What version of Go and Gonum/plot are you using?
(it is also broken on 0.14.0)
Does this issue reproduce with the current master?
I tried testing against 342a5ce, which shows up in go.mod as
require gonum.org/v1/plot v0.14.1-0.20230902105700-342a5cee2153
for me. The behavior was the same as what I described.I believe this reproduces against the current master branch at time of writing.
The text was updated successfully, but these errors were encountered: