Here are some comments on sets in CAS

http://www.cs.berkeley.edu/~fateman/papers/sets.pdf

I think that if you want to deal with subsets of the real numbers you 
should look
at the literature from interval arithmetic to see how you can get your
underwear in knots, even with such a simple domain when you add infinity
and NaN.   And then beyond reals (etc) there are sets that include 
enumerated
types, indexed infinite sets, etc.
RJF


On Sunday, June 1, 2014 10:11:09 PM UTC-7, Kalevi Suominen wrote:
>
> The correspondence between assumptions and sets may not be
> quite straightforward to implement. In the original set theory of
> Cantor and Frege any condition (or statement) would define a set.
> After Russell remarked that "the set of all sets that do not belong
> to themselves" (if it exists) has contradictory properties, all later
> axiomatic set theories have restricted the correspondence
> between sets and statements in one way or another.
>
> Kalevi Suominen
>
> On Monday, May 12, 2014 10:31:53 PM UTC+3, Aaron Meurer wrote:
>>
>> Another argument for keeping it is that it works nicely with the 
>> assumptions system. In the assumptions system, ~Q.positive means "not 
>> positive", whereas Q.nonpositive means "real and not positive". The 
>> former item means *anything* that is not a positive real number. It 
>> could be a negative number, a complex number, a matrix, a set, etc. In 
>> other words, negation in the assumptions implicitly means universal 
>> complement. Therefore if we want there to be a one-to-one mapping 
>> between assumptions and sets (and I think we do), we need to allow the 
>> universal set, because that is the corresponding set to Q.is_true (or 
>> more simply, S.true). 
>>
>> Aaron Meurer 
>>
>>
>> On Sun, May 11, 2014 at 11:35 PM, Aaron Meurer <asme...@gmail.com> 
>> wrote: 
>> > I am -1 to remove it. As I explained in the issue, universal set is 
>> > analogous to infinity for regular numerical arithmetic. Not all 
>> > mathematical operations make sense for it, but there are some that do, 
>> > and they are useful to have.  Of course, sometimes you do want to 
>> > specify your domain. It is similar with numbers: sometimes you want to 
>> > specify explicitly that you are working with the reals or the 
>> > rationals or whatever. But it is annoying to have to do this all the 
>> > time. 
>> > 
>> > We should just fix code that assumes that the reals are the universal 
>> set. 
>> > 
>> > Aaron Meurer 
>> > 
>> > On Sat, May 10, 2014 at 12:35 PM, Sergey B Kirpichev 
>> > <skirp...@gmail.com> wrote: 
>> >> On Sat, May 10, 2014 at 11:03:12AM -0700, Harsh Gupta wrote: 
>> >>>    This comes from the discussions on this PR 
>> >>>    https://github.com/sympy/sympy/pull/7462#issuecomment-42111992 
>> >>>    We have a class called UniversalSet which is supposed to be *set* 
>> which 
>> >>>    contains all the sets which we can define in Sympy. The problem is 
>> that we 
>> >>>    really don't "know" what our defined Universal Set is. It has been 
>> >>>    proposed by Sergey that we wipe out the Universal Set class. We 
>> can 
>> >>>    explicitly provide the the known defined universal set when 
>> situation asks 
>> >>>    for it, that set can be complex, real or real*real or anything. 
>> I'm +1 to 
>> >>>    the proposal. I guess this goes with "Explicit is better than 
>> Implicit" 
>> >>>    from the Zen of Python.  At places we are implicitly assuming 
>> UniversalSet 
>> >>>    to Interval(-oo, oo) which is clearly wrong. Then we cannot define 
>> >>>    operations like PowerSet and cardinality on such sets. We can 
>> avoid the 
>> >>>    problem by leaving PowerSet or cardinality undefined for 
>> UniversalSet, but 
>> >>>    not having an UniversalSet will be a better way to avoid unknown 
>> >>>    inconsistencies. 
>> >> 
>> >> btw, some statistics: 
>> >> $ fgrep -R UniversalSet sympy/|wc -l 
>> >> 22 
>> >> $ fgrep -R UniversalSet sympy/ 2>/dev/null|grep -v 'core/sets.py'|grep 
>> -v 'core/tests/test_sets.py'|wc -l 
>> >> 8 
>> >> 
>> >> -- 
>> >> You received this message because you are subscribed to the Google 
>> Groups "sympy" group. 
>> >> To unsubscribe from this group and stop receiving emails from it, send 
>> an email to sympy+un...@googlegroups.com. 
>> >> To post to this group, send email to sy...@googlegroups.com. 
>> >> Visit this group at http://groups.google.com/group/sympy. 
>> >> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sympy/20140510183503.GB18695%40debian. 
>> >> For more options, visit https://groups.google.com/d/optout. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/e6dbe3a7-cfff-469d-ace6-b4b063f3a500%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to