search

MakieOrg / Makie.jl

Interactive data visualizations and plotting in Julia
https://docs.makie.org/stable
MIT License
2.42k stars 313 forks source link

Some recipes fail when plotting empty vectors #3567

Open BambOoxX opened 9 months ago

BambOoxX commented 9 months ago

When plotting empty objects, some recipes fail on convert_arguments, but not all of them do, making it difficult to know if it should be an expected behavior or not. I run into this problem mostly with arrows because sometimes I have missing objects in some model. The problem is that I do not know what is better. Not plotting at all (handling the lack of data at my level), or attempting plotting regardless of the underlying data, to preserve the plot structure.

I there any recommendation regarding this ? This is somewhat related to #3228

As an example, scatter works, but arrows do not.

I've tested this for multiple recipes (listed below) mostly in 3D. 

ablines([],[]) # works
arrows(Point3f[], Vec3f[]) # fails - works now
scatter(Point3f[]) # works
band(Point3f[],Point3f[]) # fails
barplot(Float64[],Float64[]) # works 
boxplot(Float64[],Float64[]) # works
lines(Point3f[]) # works
linesegments(Point3f[]) # works
meshscatter(Point3f[]) # works
pie(Float64[]) # works
scatterlines(Point3f[]) # fails - works now
triplot(Point3f[]) # fails
jkrumbiegel commented 9 months ago

Most plotting functions should handle empty vectors. I can't formulate a perfect rule but usually if you can draw zero or more of something, then this should work for zero. But if there's some data transformation inherent to a recipe which just doesn't make sense for zero elements, then this should fail. Like sum(Float64[]) returns 0 but mean(Float64[]) returns NaN because you can't divide by zero.

Often, problems with zero elements will stem from type instabilities breaking subsequent dispatches. For example, a vector will be assembled given the input data and this ends up Any[] for the zero-element case because it couldn't be inferred what element type it should be. Then any following dispatch will probably fail if it expected Point2f or so. These are often reasonably easy to fix by type-constraining the relevant containers.

BambOoxX commented 9 months ago

@jkrumbiegel Yes, that is why I explicitely called concretely typed empty vectors, that avoids the dispatch problem I guess, at least partially.

jkrumbiegel commented 9 months ago

Right but this is not just about the input types, the recipes themselves will sometimes do type-unstable transformations. But those can be fixed one by one. We should definitely increase the test coverage for empty recipes. If you want to tackle that, it would already be very helpful to assess which empty cases are already tested, and which aren't, and then adding tests (that are failing) for the missing cases. Then somebody else can go in and fix those.

BambOoxX commented 8 months ago

@jkrumbiegel i hope I will have a bit of time for that but so far I've never contributed to make. I have to say I do not know how to dev it properly without breaking the rest of my environment. I know there is a section about contributions but I had surprises with previous attempts. Any suggestions?

jkrumbiegel commented 8 months ago

Right, it's a little more complex than with other packages but not terribly so. I have a shared @makie environment that I activate when developing, because if you just activate the main Makie env directly, you'll not get MakieCore, and any of the backends dev'ed.

image

So ]activate @makie and then dev Makie should clone the whole Makie repo into your dev folder. Then you can dev MakieCore etc and it should find those in the Makie folder because they are subfolders of that.

ffreyer commented 2 months ago

updated the opening post for what's not erroring. 2 to go