On Sunday, February 9, 2014 11:31:50 PM UTC+4, Harsh Gupta wrote:
>
> I think we need to have formal policy about including the code which can
> potentially give wrong results.
>
The only sane policy is: we shouldn't include code, that produces wrong
results. Or, at least,
clearly separate this code from the rest.
> There can be two cases.
>
> 1. We don't know what use case leads to wrong to the wrong result but we
> are
> not sure that there won't be any.
>
That's exactly the case you have not a real algorithm to solve the
problem (for some input). And that's not a good idea to replace this
algorithm with some heuristics which may work.
The problem is, that it's not easy to check results, returned by CAS. Is
the output
of the solve() - a complete set of solutions for given
equations/inequalities? Is this expression a correct
limiting value for that limit? If you have wrong answers - you can't trust
your CAS at all.
> First we can might make it necessary to give a formal proof of the
> algorithm used.
>
Or you can just point people to the right references for this algorithm.
> But the cons are that it can be hard to turn
> up with a formal proof especially if the developer has come up with the
> algorithm by himself.
>
Then it's really bad idea to include such a code. In Sympy, there are other
tasks for coders, not just maths.
> Second we can ask for a formal description and justification of the
> algorithm. This way it will be easier to figure out logical fallacies
> and as
> a bonus we can add the formal description in the documentation.
>
Python's code is a good formal description. But you should be able to
prove one or point to the right source, where it's already proven.
> 2. This is the case where we know of certain use cases which give the
> wrong
> result but allowing them helps us solve a larger set of usecases.
>
Very dangerous idea, as explained above.
> For example while working on evaluating imageset we had an algorithm
> that worked
> well given that the input function is continuous
>
Are you sure to be able to say that given expression is a continuous
function?
But we don't have any easy method to check for the continuity.
>
Then you should explore non-easy methods...
> But there can be cases where the safe set of inputs
>
Can you tell me, that given input is "safe"?
> But isolating the cases where it will give wrong
> result might turn to be harder problem than computing the limit itself.
>
But gruntz.py does this!
> And by
> not allowing trigonometric functions or not allowing limit computation
> at
> infinity will reduce the usefulness of limit to a great extent.
>
Well, I think that our gruntz implementation has good limit computation
capabilities. Just try to remove remaining heuristics in the limit()
function and run ./bin/test sympy/series/ (e.g. there is no failures for
test_gruntz.py at all).
The hard part, as Aaron said, is zero-decision. But you can also change
calculate_series to
something like this:
for t in e.lseries(x, logx=logx):
t = cancel(t)
is_zero = t.equals(0)
if is_zero is True:
continue
elif is_zero is False:
break
else:
raise NotImplementedError("Zero-decision problem for %s" % t)
return t
Here is my statistics:
tests finished: 224 passed, 2 skipped, 9 expected to fail, 9 exceptions,
in 339.63 seconds
Because I don't think we can avoid wrong results we should:
>
> - Document and tell users that this is what sympy cannot do and where can
> silently go wrong.
>
Yes, this is a good workaround for existing state. And we should create
related bugs, of course.
--
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.
