gg
gg copied to clipboard
dbuenzli
Box2 with negative sizes
I have a usecase where I use Box2.t to represent arrows pointing in 2d-space. This means that they can have sizes that are negative in the x or y dimension. This has worked well until I found that maxx and friends don't support this.
The documentation of Box2 doesn't state that negative sizes are not allowed, and I like my current usecase. Should all Box2 functions be made to support negative sizes?
This would mean that BoxN and SizeN modules would also need to support negative sizes
This means that they can have sizes that are negative in the x or y dimension.
Operations on boxes with negative size are undefined. This is indicated in the first paragraph here.
I see - would have expected to see this at Box2.v as well, but also makes sense to keep the common documentation for boxes together
Indeed I can repeat that in the module somewhere.
As far as this question is concerned.
Should all Box2 functions be made to support negative sizes?
I suspect it makes all sorts of operations much less efficient or confusing.
One idea though could be to normalize them on construction, but of course that's also a few more comparisons (and possibly confusing for the end user).
In fact defining what a good box type should be is suprisingly tricky.
One idea though could be to normalize them on construction, but of course that's also a few more comparisons (and possibly confusing for the end user).
This would also make my usecase confusing - and in that case I'd choose a different representation than Box2. You also loose information on normalization, as one doesn't know what dimensions was negative before normalization.
In fact defining what a good box type should be is https://github.com/dbuenzli/gg/issues/20#issuecomment-1039627148.
Interesting, though inset seems to have a more complex semantics than the other functions.
In an alternative interface for Box2, one could maybe have had a smaller module supporting negative sizes - and then other modules that extend Box2 with more features for less general usecases. These would then demand a normalized Box2, e.g. expressed through types. Though feels too complex of an interface for your style of libraries.