On Mon, Jul 16, 2012 at 7:16 AM, Chris Smith <[email protected]> wrote:
>> I tried to find a thread on this topic, failed, and decided it would
>> be good to have one.
>
> see issue 1725 and my branch mentioned there for what I tried, but
> there isn't discussion about the ordering as I recall
Thank you, I'll take a look at your branch whenever I have some time.
I've seen the issue 1725 some time ago, but have forgotten about it
lately, thanks for pointing out, there seem to be a number of
interesting ideas.
>> Chris, I couldn't find any mention about the order of these hints in
>> the docstring.
>
>
> See the paragraph just before the examples in function.py ("Note:
> because hints are applied in arbitrary order, some hints may...")
Well, yes. I was too focused on thinking about problems to remark
that your question was not so much about problems as it was about the
possibility of getting different results.
On Mon, Jul 16, 2012 at 8:29 AM, Joachim Durchholz <[email protected]> wrote:
> Am 16.07.2012 06:21, schrieb Chris Smith:
>
>> It seemed to me that things were excessively repetitive, but I think
>> part of the reason is that it's hard to anticipate how one expansion
>> may make another need to be reapplied. So as I recall, if hint foo is
>> being applied, along with 5 other hints, foo is applied and then all 5
>> others are applied; then the next of the 5 hints is applied and the
>> remaining 4 that haven't been applied (or is it the other 5?) are
>> applied again, etc... until all hints have been applied.
>
>
> Hurk. That's an antipattern if I ever saw one.
> For example, how can you be sure that if A leads to a reapplication of B,
> that B doesn't lead to a reapplication of A?
> Nevermind the quadratic blowup.
That's what I thought as well.
> A hint should know about which other hints may influence it. Something like
> "this hint must be run after that hint".
> And if the runs-after relationship turns out to be cyclic, I think the two
> hints should have their implementations merged. Sometimes it's enough to
> merge just the tree walker or whatever is tangling the two, and have the
> remaining code still separate.
I have also just caught a glimpse of an idea of a hint dependency
graph. However, I wonder how feasible it would be to create one which
would be sufficiently general to always work. I haven't thought too
much on that matter, but I'm afraid that the cost of eliminating loops
may sometimes be too dramatic, in the sense that it would disable
expand to do something which it currently can do.
On the other hand, I'm not sure whether merging two expansions is
always the proper way out.
The disclaimer here is that I know rather little about the general
principles along which the expansion routines work, so I'm just
conjecturing.
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.
