|
Boost : |
From: spamjunk_at_[hidden]
Date: 2002-08-27 13:28:43
There is no order requirement to discrete_set, ie Set(e1, e2, e3, e4) == Set(e3,
e4, e2, e1) is true. The discrete set is just as versatile as the Pascal Set.
Pascal's set is only allowed for ordinal (integral) types. As with the Pascal
Set, mine will work correctly with int, char, enums. You can define a set of
{'A'..'Z'} if you want to. Neither std::set<>, no Pascal's set of, implement a
"universal set." I cannot make a std::set<int> and ask about membership of a
float or some class X. As with discrete_set, std::set and the Pascal set are
restricted to elements in the domain it was defined for.
> Rich,
>
> Mathematically it is obviously a set (although ordered), I was more
> worried about programmer's conception of a set, such as the STL set
> (which is not an unstructured set..), Pascal's set etc. All those
> concepts are open, in that any element of the correct type (where type
> is different from a simple, often short, enumeration) can be added.
> Thus, there is no "universal set" embedding all possible sets.
>
> Your construct does have a universal superset, and is in that case
> bounded (more than discrete, which holds for most (or all if you are
> bit-inclined) computer set concepts).
>
> Thus, your "discrete_set" type is more aligned with the "domain" and
> "constraint" concepts found in (Finite Domain) Constraint Programming.
>
> I do not want people to expect the common set properties from your type,
> since your set is more of a "selection" (or constraint, if one prefers
> that nomenclature) of/on a finite "domain". If programmers get the right
> mindset, your type is an extremely valuable addition to Bosst.
>
> /David
>
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of spamjunk_at_[hidden]
> Sent: Tuesday, August 27, 2002 1:07 PM
> To: boost_at_[hidden]
> Subject: RE: [boost] discrete_set class
>
>
> David:
>
> Pardon my ignorance, as my degrees are not in math. Other than a
> restriction on the element type, in what ways is this not a set.
>
>
> Regards,
>
> Rich Herrick
>
>
> > People are thinking about your construct as a set, which is "open" in
> > its nature.
> >
> > I suggested to borrow some terms and ideas from the area of Finite
> > Domain Constraint-solving. That proposal was apparently ignored, due
> > to the introduction of unknowns and overall whimsical appearance ;-)
> >
> > I think that using terms like "domain" or "finite_domain" with the
> > semantics from Constraint solving would clarify that this construct,
> > although being extremely useful, is not a regular "set".
> >
> > /David
> >
> > -----Original Message-----
> > From: boost-bounces_at_[hidden]
> > [mailto:boost-bounces_at_[hidden]] On Behalf Of
> > spamjunk_at_[hidden]
> > Sent: Tuesday, August 27, 2002 8:47 AM
> > To: boost_at_[hidden]
> > Subject: RE: [boost] discrete_set class
> >
> >
> > Ok, this is my fault. As Joel has pointed out, I neglected to provide
>
> > documentation. I apologize and will upload some as soon as I can.
> > For now, the problem with your examples is the class expects the
> > values of the elements to be in the range [LO, HI]. You are trying to
>
> > use values outside the range. My understanding of C++ is that it is
> > undefined behavior to convert an int to an enum when it is outside the
>
> > enum's range.
> >
> > pop-server.stny.rr.com
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
>
> pop-server.stny.rr.com
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
pop-server.stny.rr.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk