>> I suspect these people are falling into the trap of seeing the
>> simplicity of the option 1 invariant over the option 3 invariant,
>> without noticing that it really leads to more complicated code.
>
> I am clearly one of those nutheads. From their perspective it's a reasonable
> assumption to make. You > see the type, you see .args, there's clearly a
> pattern, then you run into Rational and get stuck.
>
and
> Long term though I think that the number of functions that traverse the tree
> can be decreased dramatically, resulting in a smaller codebase. @smichr has
> used bottom_up in simplify/simplify.py a number of times to good effect.
I share Matthew's opinion on these two issues ("what and why is more
complex"). The code might be marginally more complex (not so if we
actually abstract tree traversal in one single place), but the data
structure will definitely be simpler if we choose option 1 (nonBasic
args). Especially so given that option 3 (empty args) requires the
creation of Dict (instead of frozendict), Tuple (instead of tuple),
Symbol/String (instead of basestring). Just consider that for
generalization of matrices we will need nested Tuple objects (probably
slow and voluminous) instead of nested build-in tuples.
I can see myself enjoying work with option 3 (in any case it is many times
better than the current lack of standard), but for the above reasons I
slightly prefer 1, __mostly because of aesthetics__.
Maybe at some point we would need a BDFL type of decision from Aaron
or Ondřej :)
--
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?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
