On Fri, Jun 22, 2012 at 7:02 PM, [email protected] <[email protected]> wrote: > On 22 June 2012 17:25, Sergiu Ivanov <[email protected]> wrote: >> >> 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:
Yes, the common-sense argument you are invoking makes very much sense, I can't disagree. Still, almost all basic types are included in SymPy. Furthermore, the logic module has a class Boolean which may be a bit on-topic, although it does serve a different purpose, from what I have seen. I can see that Ronan has posted a link to an issue which may clarify me, though. I hope the discussion there will clarify my doubts. >> 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? Well, my statement was about a slightly different thing. I don't preach the abolition of the usage of None; it's a very useful value which plays a great role everywhere. However, I can't see why one would need to store None in FiniteSet. Really, it's very hard for me to imagine a scenario where this would make much sense. If one stores a FiniteSet of objects one is interested in, and one needs to also store None, then, perhaps, something like EmptySomething class is required in the class hierarchy. It's not that much about enforcing a strong type system, as it is about respecting the relative strictness which is already imposed throughout SymPy by the nearly ubiquitous usage of Basic. >> 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. Yes, that's totally right, and this only makes my question even more vivid: why mix the two? Why store frozensets in FiniteSets? That I don't like :-) Here, I guess, it's appropriate to re-state that I am not attempting at formulating global redesign ideas. I'm rather trying to wrap my mind around the fine points. Sergiu -- 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.
