Boost logo

Boost :

Subject: Re: [boost] [challenge!] find a common domain
From: Jeremiah Willcock (jewillco_at_[hidden])
Date: 2010-05-19 18:17:08


On Wed, 19 May 2010, Eric Niebler wrote:

> On 5/19/2010 3:07 PM, Jeremiah Willcock wrote:
>>>> In that case, when do two domains that
>>>> both derive from default_domain conflict? They have a common ancestor,
>>>> namely default_domain. Or should default_domain be special in that
>>>> regard, with a rule such as "if the merger of two domains is
>>>> default_domain but one of them isn't default_domain, replace the result
>>>> with not_a_domain"?
>>>
>>> Close. Yes, default_domain is special. If the merger of two domains is
>>> default_domain and /neither of them/ is default_domain, the result is
>>> not_a_domain. Otherwise, the one that's not default_domain dominates.
>>> So, if lambda_domain is a sub-domain of default_domain, it is stronger
>>> than default_domain and should dominate. I.e., "_1 + 42" should be a
>>> lambda expression.
>>>
>>> default_domain should *never* be the answer when any domain is not
>>> default_domain.
>>
>> What about in the case of two different domains that both derive from
>> default_domain but have no other ancestors in common?
>
> Ambiguous. not_a_domain.
>
>> I see
>> not_a_domain in your test cases. What about two different domains that
>> each derive from DD0 (in your test case)? What should the result of
>> combining them be?
>
> DD0.
>
>> For non-default_domain domains I use the least
>> common ancestor (which is what it seemed like you wanted).
>
> That works. Something like it should also work for the family of domains
> rooted at default_domain, with a special case for when the result would
> be default_domain itself.

What about DD2 and DD3 from your tests, though? You have that combination
returning DD2, which is the opposite of what I would expect from your
description (if X derives from default_domain, always pick X as the
result). Or am I misunderstanding something?

-- Jeremiah Willcock


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk