should rasdaman have sdom intersection?

[bbell]

given two arbitrary arrays, c & d, c+d is defined cell-wise, and hence, the operation on a pair of arrays is well-defined on the intersection of their domains, sdom© and sdom(d). Currently, we can, in some special cases, query:

select c[sdom(d)] + d

in case sdom(d) is a subset of sdom©.

A priori, we do not know what the intersecting sdom of c & d happens to be, or whether c[sdom(d)] even makes sense. As such, the following query makes no sense:

select c + d

which is why, in most cases except when we are deliberately correct or else very lucky, we would return an error; however, it would always make sense to say something like:

select c[intersect(c,d)] + d[intersect(c,d)]

Many binary operations require the criterion of matching sdoms to be satisfied, even when these operations are somewhere-well-defined (presently, this means always on the intersection, as our binary operations are extended diagonally)

Should we extend rasql to include an intersection operation in the interest of enabling the application of binary op queries to somewhat-arbitrary domain pairs (I mean, the dimensions would need to match, still!)?

Should intersection be implicit for ops like +, or only user-specified?

I think it is still, at the very least, interesting to query:

select c[intersect(c,d)]

and such an implementation would be fairly straightforward:

select intersect(c,d)

This could be introduced as a binary (or even n-ary) operator, and it would be well-defined in the query tree.

[Dimitar Misev]

I think it would be better to support some trivial operations on mintervals: intersect, union, difference? So that instead of intersect(c,d) in your examples, we would have intersect(sdom(c), sdom(d).

With that, we could overload some operators: * for intersection (not sure if * fits well here though), + for union, - for difference?

[bbell]

Replying to dmisev:

I think it would be better to support some trivial operations on mintervals: intersect, union, difference? So that instead of intersect(c,d) in your examples, we would have intersect(sdom(c), sdom(d).

With that, we could overload some operators: * for intersection (not sure if * fits well here though), + for union, - for difference?

if we are to overload operations like + and - (does relative complement make much sense when we are limiting our discussion to binary functions on sets of hypercubes?), then while at first glance notationally-cumbersome to reference sdom© directly instead of c, I think it is still clearer to the user.

Else I expect one might accidentally do something like intersect(c+d, e) when they might in fact be thinking intersect(union(sdom©,sdom(d)), sdom(e)).

Since we might want to do [*:*,50:99]*sdom©, I would really suggest not using * for intersection; if anything, I would use & for intersection (the propositional "and" is used for intersection of sets, since x is in the intersection of U and V iff x is in U & x is in V), but + for union is probably fine, though I would also be comfortable with sdom(c) || sdom(d) for union and sdom(c) && sdom(d) for intersection.