Subject: [ggl] Point/Box in Box Test (Border Cases - 3D)
From: Barend Gehrels (barend)
Date: 2011-07-01 15:55:09
>> Another possibility is to use strategies, we might expose a strategy
>> returning true if inside or on border (strategies are already an
>> optional runtime parameter)
> I thought of strategies as a way to allow different algorithms to be specified, for example a smooth() function that accepts different strategies that implement various kinds of smooth operation and defaults to one of the most common/simpler smooth algorithms. It might be overkill to use strategies for specifying an option. I don't foresee the need to make within() extensible in the way that strategies would allow, but I could be missing something in the bigger picture.
Right. It is indeed probably not the best way, in this case.
This is what I thought. Strategies modify behaviour. For example, for
the distance strategy, you can specify the radius of the Earth or a sphere.
If you specify an extra argument, you would need to make two new
overloads, one with and one without a strategy.
Some strategies do not really care about on border. If there was a new
overload, with "on_border=true", it would give confusing results because
those strategies cannot really determine that (in their current
Therefore, I thought, being on the border is related to the specific
strategy and it might be part of those specific strategies.
But: these arguments does not really hold because the strategies do
already return -1, 0 or 1 if outside, on border or inside. So if we
would give this property to the winding strategy (which really knows
about on-border), it would change the meaning of its results, which is
probably not a good idea...
Geometry list run by mateusz at loskot.net