rafaqz
commented
1 year ago Yeah we should just make them equivalent. The problem is converting to Symbol loses the distinction.
Closed sethaxen closed 6 months ago
rafaqz
commented
1 year ago Yeah we should just make them equivalent. The problem is converting to Symbol loses the distinction.
sethaxen
commented
1 year ago Yeah we should just make them equivalent
Make what equivalent?
rafaqz
commented
1 year ago E.g. X and Dim{:X} could be compared as equivalent.
Because of key2dims and conversion to table etc they are in effect, but they are not compared as equalent in e.g. sortdims.
sethaxen
commented
1 year ago If we end up making them equivalent, what's the benefit of X being something different from const X = Dim{:X} instead of its own type? My assumption was one of the purposes of X is to have a reserved name that is differentiated from Dim{:X}.
rafaqz
commented
1 year ago There are a few things.
Plotting uses the types to decide plot axes here and in Rasters.jl. So both Ti and X are IndependentDim and go on the x axis. We could switch that to using traits defined on Dim{:X} and Dim{:Ti}. But plotting things the right way is a big part of what Rasters.jl does so this has to work somehow or other.
You can also manually define a dimension with @dim MyXDim XDim and it will also plot on the x axis. Currently you can do this and e.g. load a netcdf with weird dimension names in Rasters.jl and they will get your dims behaviour if they match. But we could do this with a trait as well, or some other mechanism.
isxdim(::Dim{:X}) = true
isxdim(::Dim{:x}) = true
isydim(::Dim{:Y}) = true
isydim(::Dim{:y}) = true
const X = Dim{:X}
const Y = Dim{:Y}Users could just do:
DimensionalData.isydim(::Dim{:MyYDim}) = trueFor package devs I'm not sure who gets to define behaviors for these dims, e.g. in a package you may want do define plotting. In Rasters.jl that happens for Band, with the illusion of there being no type piracy - but because Band is essentially the same as Dim{:Band} it's still kind of piracy for some applications.
rafaqz
commented
1 year ago I wrote dimension behavior before I realized table keys are all symbols and dims should be columns, and that a[customdim=4] syntax is often preferable to a[Dim{:customdim}(4)], and that these dims would be widely used. I still basically never use Dim.
Probably would have done things differently if those were in place from the start.
If we use a
Dim{k}wherekis a Symbol that matches the name of one of the special dimensions created with@dim(e.g.XorTi), then an error is raised when we use the Tables interface: