Re: Implementing set theory operations similar to SQL's select and update

Barry Kelly wrote:
> I'm writing an engine designed to implement behaviour which may be
> customized along multiple dimensions.
>
> This might seem a bit off-topic, but in my defense I say:


I don't think that it's off topic.


> The Problem
> -----------
> (For those interested in why this is the problem, the background
> overview below has more information).
>
> I have a sequential list of multiple (1000+), overlapping set
> definitions. I want to know, quickly enough to be usable for a
> developer using a GUI front end, does the set they are defining
> completely encompass a previously defined set? Is it only a partial
> subset? What is that subset? Can that subset be converted easily into
> its own representation rather than as the product of set difference
> and/or intersection?


This high level description of the problem makes perfect sense. It looks
like an interesting problem.


Unfortunately, I can't make heads or tails of your detailed description.


It seems to me that one possible approach would be to think of each set
as a group of contiguous regions in the n-dimensional space. It should
be pretty easy to pick out obvious disjoints.


The tricky part is comparing two regions that are in roughly the same
place. I think that one possible approach would be to stick to the
surfaces of the objects being compared. If you have a surface that
defines the outside of region A and another surface that defines the
outside of region B, find the places where the surfaces interesect. It's
pretty easy, then, to determine the parts of A that are not in B and the
parts of B that are not in A.


I'm not sure if I'm making any sense or not. Hopefully it will at least
generate a useable idea.


> Object-oriented techniques have been rejected because they constrain
> me to using a fixed order of dimensions for reuse and overriding.


There are many ways to implement flexible multi-dimensional processing -
ESPECIALLY in an object oriented language.


On the other hand, not using an object oriented language because you're
not familiar enough with the paradigm to comfortably implement mission
critical software is a perfectly valid rational.


There's no shame in sticking to what works for you, but please don't
make unsupportable claims about the shortcommings of OO.


Donald McLean

Return to the comp.compilers page.
Search the comp.compilers archives again.