Am 09.11.2013 06:15, schrieb Aaron Meurer:
On Nov 8, 2013, at 2:26 AM, Joachim Durchholz <[email protected]> wrote:
That's a hyperrectangle of class combinations that needs to be filled with
associations to code to run.
If you deal with each combination on a case-by-case basis, this becomes
unmaintainable due to sheer numbers.
If you use rules to map many combinations at once, depending on the structure
of the rules you risk overlaps (creating surprising behaviour because you're
usually not aware of the conflict) and oversights (unmapped combinations).
Standard MD rulesets tend to exclude oversights; I'm somewhat sceptical that
that's a good idea, an oversight produces a clearly visible and easily fixable
error message while an overlap silently creates unexpected behaviour (which
might not be wrong but still using the wrong, too-slow algorithm or be
otherwise undesirable).
Actually, for SymPy, if there's no rule, then the behavior is to just
create the unevaluated object. This will actually be the common case.
Ah okay, so then we'll never have what I've been calling oversights.
That's helpful.
Hm. Well, on second thinking, there can still be oversights. Cases where
people find that case AxB works, case BxA doesn't but should because
it's symmetric. Or where Complex isn't covered but should be done by the
Real case.
But maybe it's good enough anyway. It's certainly what's already
happening, so we're not getting worse that way.
x + y will return Add(x, y) in almost every case. Only if x and y are
similar objects (like if they differ only by a number multiple) or
some special object like O(x**2) or oo will anything special happen.
So the hyperrectangle will be mostly sparse, and that's fine.
You do want some of the hyperrectangle entries to project.
E.g. you'll want to specify that oo * Number to return oo, and you don't
want to repeat yourself.
The issue to solve is two cases here:
1) Exceptional cases. One may be tempted to specify oo as the result of
oo*Number, but that's not the right one for oo*Complex, nor is it the
right one for oo*Zero. However, that's just "competence in math", I do
not think that any Python code can help with that (unless we rebuild
SymPy around a proof checker, which would be interesting but essentially
a full rewrite).
2) Conflicts. Somebody adds (say) Quaternions, somebody else adds a rule
for One, and suddenly we have both One*NumberLike and Number*Quaternion.
This can be diagnosed in unit tests if the association of type
combinations to functions to call is kept as a data structure (as
opposed to coding the decision tree into a piece of Python code).
> It's not
like with numeric libraries where x + y has to return some kind of
number and so you have to catch every possible combination. We have a
default behavior: leave it unevaluated.
We have, but we still have the situation where the default behaviour is
inappropriate because it results in missed simplification opportunities.
And that's a biggie, because missed simplification means many more
integrals and integral equations that can't be solved, and such stuff.
Fortunately, that's not an architectural error that would be unfixable
without a complete rewrite, we can fix missed opportunities over time.
I like where this is heading.
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.
