On 22 June 2012 17:25, Sergiu Ivanov <[email protected]> wrote: > On Fri, Jun 22, 2012 at 5:43 PM, Matthew Rocklin <[email protected]> wrote: >> >> Some non-Basic element types are important. True, False and None are notable >> examples. Frozenset is another. SymPy.stats uses frozensets pretty heavily >> because they're substantially faster than FiniteSet. I'm in favor of >> avoiding this problem if possible. > > All right, that sounds plausible. > > I do have some questions, though. > > I am still a little bit surprised that there is no type in SymPy to > store True and False. However, if there is a reason for such a class > not to exist, I wonder whether allowing True and False in FiniteSet > would be totally consistent.
Why would one create a type that mimics True and False but works only in sympy. This will force anybody using the library to write if somethings is SympyTrue: instead of if something: > Further, I can't really grasp the point of having None in a FiniteSet. > I'd be happy to see an example where None couldn't be substituted for > an EmptySet or a special value belonging to the type we are interested > in. `is a is None:` seems like a sufficient reason to leave None being None. Why reimplement stuff that is already in python? Just to emulate strong type system in a language that does not have one? > Yet further, if some code depends on frozenset's for speed, where and > why does it use FiniteSet? I really really don't like the idea of > having frozenset's in FiniteSet's; it sounds very inconsistent to me. Even more important than performance is simplicity. FiniteSet is for symbolical work. frozenset is for internal algorithms that need the data structure but do not need the cruft. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
