I've created a "smaller" reproducible problem regarding these floating
point discrepancies here:
https://github.com/sympy/sympy/issues/20340
Maybe some people have some insight on that particular framing of the
problem?
Thanks for your time.
Jason
moorepants.info
+01 530-601-9791
On Fri, Oct
David,
I'm not sure I understand what algebraic manipulations you are referring
to. In the example, the algebraic manipulation is done with sympy
variables. Only the final expressions are evaluated with floating point
numbers substituted in. The substitutions of floating point numbers do have
to
On 23/10/2020 11:59, Oscar Benjamin wrote:
Hi Jason,
I'm approaching this from the perspective that this is a bug in
cse/lambdify and that you want to identify which part of a large
expression tree triggers the bug. Since evaluating the whole
expression is slow I would start by testing smaller
Also, if anyone is curious what prompted this question, I do now have a
nice example running in the pydy docs for this problem:
https://pydy.readthedocs.io/en/latest/examples/carvallo-whipple.html
There are still some things that are incorrect in the derivation (the
warning boxes) but the
Oscar,
Yes, this is what I want to check. Thanks for taking the time to write this
code. I'll give it a try.
In the meantime I did get my code to run. I think Python was actually being
"Killed" by trying to lambdify an expression with thousands of operations.
I then switched to expr.evalf(subs=)
Hi Jason,
I'm approaching this from the perspective that this is a bug in
cse/lambdify and that you want to identify which part of a large
expression tree triggers the bug. Since evaluating the whole
expression is slow I would start by testing smaller subexpressions and
work up from there. You
Oscar,
Yes I can try evaluating in different orders. That's an interesting idea.
I also may be breaking lambdify with too many arguments. I can store the
numerical results of each subexpression in a dictionary, then identify the
minimal set of variables in each subsequent subexpression, and only
Yes, you are right that the email is about a different topic. However, it
can be worth noting that evaluating floating-point expressions in different
order, which is basically what you do using cse:s, can give different
results due to the floating-point quantization/rounding happening at
different
As far as I understand the results should match to machine precision.
We are able to match these kinds of models executed on different platforms
using different formulation techniques to machine precision (e-14 or more).
In fact, we use this to be able to verify that two independent modelers
have
How much do they differ? I checked the issue and the latest result wasn't
that bad, although probably too much to blame floating-point errors.
However, if you push the numerical range into e.g. denormalized numbers I
guess it can simply be that. Not very likely though. Is it still that type
of
Howdy,
I'm trying to track down a bug in this PR:
https://github.com/pydy/pydy/pull/122
I have quite large SymPy expressions which I evaluate with floating point
numbers. I also cse those expressions and evaluate those with the same
floating point numbers. I'm getting discrepancies in the
11 matches
Mail list logo
