On Fri, Jun 22, 2012 at 4:07 PM, [email protected] <[email protected]> wrote: > I see both problems as somewhat artificial: > > - We are forcing some kind of sorting on a mathematical concept that > does not depend on sorting only for the sake of doctests. The problem > is the way the doctest is written, not that FiniteSet orders its > elements (sorting for the sake of equality tests is different, and > being machine dependence is not a problem there).
Agreed. However, since there is no easy way to assure that non-Basic (i.e., any) object get sorted in the same way on all machines, there's the solution to only include one non-Basic object in the doctest (currently, the failing doctest creates a FiniteSet which contains Interval and Float, the classes, at the same time). I'd ask a slightly off-topic element_sort_fn design function. It now uses the sort key return by the Float class, which means that, in a FiniteSet, for example, all non-basic objects will be located among Float objects. This can be corrected by producing a sort key by hand, which I tried to avoid. Do you think I should do that? > - Permitting only Basic instances in args causes much pain: Symbol, > for instance, does not contain its name in its args. Every time that > we want to have a named object we jump trough hoops. This breaks > obj.func(*obj.args)==obj. There is no clear notion of atomic object in > sympy: some of the tree traversal algorithms check for empty args, > other for subclasses of Atom, etc. Well, Symbol does derive from Basic. Further, x.func(*x.args) != x, where x is a Symbol, exactly because Symbol doesn't store its name in Basic.args. Therefore, I fail to see how allowing or not allowing FiniteSet to store arbitrary objects is related, sorry. > The only argument that I have seen in favor of demanding only Basic in > args is for ease tree traversal. But if we set up sane rules and we > stick to them this would be completely unnecessary. Well, yes, you're right. I can't think of any other argument. However, this very tree traversal requirement is apparently sufficiently important to condition the necessity that everything in .args be Basic. I have made the suggestion to only allow Basic's in FiniteSet having that in mind. In general, from what I understand, Basic should serve as the base class for all those objects which represent mathematical entities. To me, the majority of mathematical entities are inherently immutable and therefore rather easy to implement as subclasses of Basic. I may be grossly wrong, though. > Or even better with a try except block as this will permit rebuilding > objects that do not subclass Basic but that have args interface: I wonder why would one need to both have .args and not subclass Basic. This seems a little bit artificial to me. 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.
